The server ate my homework

The server ate my homework! In a recent article, I learned that some schools are taking big steps and making wholesale changes to introduce technology in the classroom. Here I find out that students do work on laptops--provided by the school--and in real time teachers track progress and problems on a linked iPad. Now that's interesting integration!

On the other hand, that's a lot of change management, and a lot of change management for what is commonly thought of as a bastion of traditionalism: the K-12 teacher corps.

If successful, whatever is in the water should be bottled and given out to every ERP project. Lord knows that industry could profit by the examples given in the classroom transitions.

Perhaps this was never more true:

If you can't make the trains run on time, do away with the trains

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Value stream mapping

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the old days, we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

And, of course that begs the question: what is value-add? There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put: anything that is ultimately delivered to the customer or makes the customer deliverable a good thing in the customer's eyes.

A lot of governance would not fit this definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without them, so there's a certain non-value overhead that goes along with everything.

One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Messy information systems

Do you buy this idea?

... science-based, method-driven approaches can be misleading. Contrary to their promise, they are deceivingly abstract and removed from practice. Everyone can experience this when he or she moves from the models to the implementation phase. The words of caution and pleas for ‘change management’ interventions that usually accompany the sophisticated methods and polished models keep reminding us of such an implementation gap. However, they offer no valid clue on how to overcome it…

Does this mean you have to see it to believe it, or does it just validate the ideas of progressive elaboration (defined in the PMBOK as continuous improvement and refinement) or emergence (unpredicted--though perhaps predictable--interactions of system elements that become known)--or neither?

No matter how you go on this, you might like the book review of "The Labyrinths of Information: Challenging the Wisdom of Systems" by Claudio Ciborra as reviewed by EightToLate

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The project sentence

Richard Feynman is a renown theoretical physicist (deceased 1988).

He once said that if he had to summarize modern science in one sentence he would choose: "The world is made of atoms".

Brian Greene, also a theoretical physicist, has written of Feynman's choice: "When we recognize that so much of our understanding of the universe relies on the properties and interactions of atoms......we can well appreciate Feynman's choice for encapsulating our scientific legacy."

And, there are other sentences. Many have said: "The business of business is business", meaning customers are swell, but shareholder value is better!

So, what about a project sentence? It would be great it would unify the three great values of project management:

1. Customer value (value as experienced by the customer)
2. Business value (value returned to the business as a consequence of project activity), and
3. Earned value (a measure of the effective utilization of the business resources committed to the project)

And, it would be neutral on plan driven vs outcome driven (agile)

So, how about this?

The business of projects is to effectively invest business assets to return to stakeholders value from the affirmative vote of customers

Brian Greene: "The Fabric of the Cosmos"
Photo

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

About change

Change is the price of survival

Gary Player

Professional golfer

Bookmark this on Delicious

PMBOK Software projects practice standard

LeadingAnswers has a nice summary of the motivations behind the practice standard for software projects now being put together by PMI. It's barely an outline now, but it will soon be joining the other practice standards that are either unique to an industry or to a domain, like construction and US Defense Department.

Here's a look at some of the issues to be addressed in the words of LeadingAnswers:

• Specification problems – software projects are hard to define because they are intangible and hard to reference.
• Evaluation Problems – We really need to see and use software to say if it is suitable for us, reading a spec is a poor method for validating functionality. IWKIWISI – I Will Know It When I See It applies.
• Knowledge Worker domain – we are using subject matter experts to collaborate and share information rather than industrial works to repeat a defined process.
• Speed of business change – system requirements change frequently as businesses evolve and change. Change rates are higher than in many other project domains.
• Building with bits and not atoms – we are manipulating information and models not concrete and steel so our processes and controls need to be different.
• Non-Linear progression – progress is often non-linear. Some things go quickly some things take a long time. Approaches that assume a linear progression to completion are more problematic to apply on software projects.
• Uncertainty – We have more technology uncertainty and requirements uncertainty than many other industries and so need more tools to checkpoint and adjust if necessary.
• Extreme modifibility – unlike physical construction where is difficult to move a bridge upstream when it is 75% complete, there are some changes that can be done late in software projects that have few parallels in other domains.

Here's my take: Software projects are "idea" projects. They are almost without boundary, both internally and externally. Not entirely of course: where the software meets the hardware, there is a boundary to be sure, especially if you are developing for an embedded processor, like a guidance computer in the tip of a weapon.

About ideas: ideas have no natural limitations: we all know that; it's unreasonable to imagine all ideas are ever known; ideas are volatile; ideas emerge and evolve with experience; ultimately ideas drive vision; and vision is the source of business value.

So, software projects are always going inherit the basic properties of ideas. As such, we need methods and management paradigms like agile to deal with ideas.

At the same time, projects more often than not spend other people's money (OPM). When you are responsible--and, gasp!, accountable--for OPM, your whole perspective changes. Order and predictability become very important.

A marriage of enterprise management skills and agile management skills perhaps is the answer. Anyway, that's what I been saying for a few years now.

Bookmark this on Delicious

Gladwell on intuition

“A tremendous amount of expertise lies in the unconscious mind ….. Anyone juggling many different variables, dealing with incredibly new and complex issues, … has to, at some point, rely on this body of submerged knowledge to make sense of their tasks”

Malcolm Gladwell

Complexity

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them

Laurence J. Peter

I'll think I'll just let this one stand, but if you want to read more, browse through this explanation of the "wicked problem".

Bookmark this on Delicious

Option management

I often hesitate to import risk management ideas from the financial sector into the project management domain--afterall, the risk management results in the financial sector have not been swell of late, and projects are not casino's--but the idea of "options" does port well to projects.

And an option is:
An option is a "right" that you buy for a small fee; then, you have the option to exercise your right at a later time. You can buy the right to buy a security at a specific price not later than a specific date, or you can buy the right to sell a security at a specific time at a specific price.

If you don't exercise the right you paid for, you lose the money you paid for the option. Obviously, you would only exercise your option if the transaction is profitable for you.

Option risk management features:
There are a couple of interesting features embedded in the option transaction that are attractive from a risk management perspective:

• Time displacement (the distance between present and future) is usually a risk nemesis, but in options, time is on your side.  Lemons become lemonade, as it where.  In order for an option to become profitable, some time must pass during which the security changes value, hopefully in your favor. (Most securities trading works this way)
• Downside risk is protected.  The most you can lose (if you act rationally) is your fee for the right to the option, thus protecting you from the actual loss of the value of the security
• Upside opportunity is amplified. Options leverage the value of the fee you paid.  For your small fee, you may be able to participate in a very large gain, which on a percentage basis, is far greater than just trading the security.

Options in projects (and portfolios)
Let's say you anticipate a make/buy juncture in the project 2-4 months out (we never use single point estimates here at Musings).  Two chains of project activities radiate from this decision event: one chain supports a 'buy' decision (essentially, outsource to a supplier) and one chain supports a 'make' decision (do all the work in-house). 

An option scenario is that you do something now to protect your right to go either way at the decision event.  You make a small investment now in order that 'no options are off the table'.

Done right, you make a friend of time: time can be used to set up the conditions for a decision that might not otherwise be available.  By protecting both eventualities, you protect agains the downside of poor alternative, or an alternative foregone because of no preparation.  And, of course, your small investment may be highly leveraged: a great outcome made more likely by a small fee for preparation.

Investment possibilities
So, what are some things you might do? A few prototypes to test your in house capability; some training of staff in skills that might be needed; some due-diligence and benchmarking on the supply chain; and some research into the various vehicles for outsourcing, like incentive contracts, etc.

If you are portfolio manager, then options in the form of independent R&D (IR&D, or IRaD) is a good way to invest a small amount now in order to have project options in the future. And, of course, investing in your customer (things you know your customer wants to do is perhaps the best use of internal investment)

Oh, and how big is "small" in the investment we are talking about?  No right answer of course, but a few percent of the value of the opportunity you are protecting is not a bad figure.

To learn more
If you want to see some numerical examples worked through, go to the Khan Academy and search for the short videos on options.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Hold a meeting

How many "how to hold a meeting" guides are there? More than enough!

So it caught my eye that no less an eminence than Donald Rumsfeld is giving his ideas on how to hold a meeting. He's on slide 8 of Bloomberg Businessweek's How To issue for September 2011.

He has four points, and three of the four are mundane: start on time/end on time, speak without jargon, and be inclusive (more on this later).

But he has one point that seems less obvious: no matter the subject, start with assumptions.

Why? Well, according to Don (can I address him as Don?) assumptions let's everyone know if they are likely to be in agreement with the topic. If so, it shortcuts the discussion of the unncessary so that the presenter can move directly to the punch line. Perhaps so. I'll be giving it a try.

On the other thing, being inclusive: not in Rumsfeld's written missive, but attributed to him by those in the know (as heard on "Morning Joe" on MSNBC), Rumy would often 'dis-invite' those that he knew did not speak up, did not offer critical thinking, and thus were unlikely to add value. So, inclusive yes; but only if likely to add something to the discussion. At the risk of group-think, which is not necessarily implied, I like this one also.

So, two good points!

Photo

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Project balance sheet

If you follow this blog you've read several references to the project balance sheet. So, is this about accounting? Yes, and no: Yes, it's about a double entry tool to keep track of "mine" and "yours", but no, it's not the accountant's tool used in your father's accounting office.

Take a look at this figure:

What have we got here?

First, 'mine' and 'yours'.

On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized. It's the 'your's side of the balance sheet, somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners). 'Yours' simply means it's resources owned by others and provided to the project.

On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets owned by the business). The right side is the project side, and the right side shows the estimates and evaluations of the project manager.

And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective. And on the right side, it's all about facts (benchmarks) and estimates (benchmarks applied to project circumstances). It's bottom up.

Of course, there's the inevitable gap where utility collides with facts and fact-based estimates. The gap is the risk between expectations and capacity-capability. And how large is the gap (risk): only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward.

 In other words, the gap (risk), shown on the project side, is only as large as it needs to be to close the gap. Usually, it's a matter of negotiation, but once the PMB is set, the risk is the PM's responsibility to manage.

In other words, the PM is the ultimate risk manager.

In a real world example, I had this situation:

• We bid a job competitively in a firm fixed price environment. 
• We offered a price that was equal to our cost; in other words, no fee (profit).  We just wanted to keep the lights on and keep barriers to competition with our customer as high as possible. 
• We won! 
• And, in  the next moment, my general manager said: "Your bonus depends on making 4% net margin".  I had my gap!  (oh yes, I made the margin and the customer was satisfied)

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The human element

The one element that can change every element is the human element

Dow Chemical tag line

People are our most valuable resource--correct?  Well, that's always the line, but is it the reality? Lest we all forget,  the 'facts' are that on the financial balance sheet, the one executives look at, people are a liability (accrued benefits and compensation), and on the expense statement, they are a cost. 

But, fortunately on the project balance sheet, they're assets.   Recall: the project balance sheet and the financial balance sheet are not the same animal.  The former is a view of the top down/bottom up balance in the project, and the latter is a view of the distribution of monetary ownership between the business and it's benefactors.

Bottom line: there's a natural tension between business and projects, and the human resource is a part of that tension.

Bookmark this on Delicious

 Bookmark this on Delicious  

Risk waterfall, or not

Waterfall is a four letter word in the project management space.

Everyone will tell you they understand the hazards and seek a more effective paradigm. Actually, the synonym is sequential process (sounds better, and more sophisticated) and the better idea, practiced by most, is sequences with iteration and feedback.

Most understand the idea of feedback as a control device (for those that want to brush up, a good read is Donella Meadows' book "Thinking in Systems"). So, when you combine a control device with the opportunity to do over or correct, you've got a sequence under control, and a sequence that is responsive to outcome demand.

Nice.

Now, the agilists call an iterative sequence under control just common sense, or complex adaptive (perhaps so, in some cases) or emergent (closer to what actually happens). But, usually the discussion on this topic is all about the vision, the requirements backlog, and the intended product or process outcome. The risk register--indeed, the whole RM process--is often ignored, or just not in the discussion.

Where does the classic RM sequence fit in? Recall the sequence: set the context; identify risks; qualitatively and quantitatively assess the risks; plan responses; do, monitor, and control the response and its impact.

Now, how does the risk sequence fit into an agile emergent paradigm, or a iterative sequential baseline process?

I posit that the right strategy is to distribute the sequence: the first two steps, set the context and identify the risks, and be done as part of the project business case and the original envisioning.  The latter steps can be allocated to the execution teams.  As such, every time the backlog is reevaluated, so also is the risk register reevaluated (thus, iteration to the project charter) and the assessment, response planning, and monitor/control are incorporated into the team work of each time box or other scope segment.

So, in effect, the sequential process, with feedback, is made iterative by time box or scope segment as matter of methodology design and management policy.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Opportunity or risk?

Opportunity or risk?

Not to be too dry, let's nevertheless acknowledge that the 'official' definition of risk, as given by PMI PMBOK, is that a risk is an event or condition that could have either a negative or positive impact on project objectives. And, if you follow the thread in the PMBOK gloassary, 'opportunity' is the name given to the positive impact thread. Now, the ISO 31000 standard for risk management does not go quite as far, defining risk as an uncertainty that affects project objectives

So, what is opportunity? Risk, or just a postive effect? And, does it matter, really?

Well, yes, actually it does, for these reasons:

a. Risk has it's own register of possible and probable events and conditions, largely not in the performance management baseline (PMB).  Thus, most risks are 'off-baseline'.  And the reason is simple: risks are generally thought of as threats to project success, PMI's glossary not withstanding.  The point of risk management is to mitigate threats to the PMB.

b. Opportunities, equally off-baseline, usually mean a change in scope.  Thus, whereas an opportunity may thought of as scope creep, the general disposition is to accept worthwhile opportunities, not mitigate against them.

c. Incentives generally follow success, but risks are not about success.  Thus, risks are not about incentives.  Money tends to focus the mind, so focus is often not on the risk register.  On the other hand, an opportunity may bring with it not only success but reward for foresight

d. Opportunities naturally find their way into the change management system, and are usually dealt with in an entirely different workflow from the risk management system. 

The PMBOK, in Chapter 11, offers four response ideas for risks: avoid, accept, transfer, and mitigate. 

The PMBOK offers a different list for opportunities: exploit, share, enhance, and accept.

However, when discussing this recently with my risk management students, one came up with three others that I think are quite clever:

IGNORE because it was out of scope; INFORM the outside party that it impacted so they can run with it; or INCLUDE in the project because it was a better way to achieve the project objectives.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

All the risks up front

Last month I was having a discussion and the point was made that perhaps risk managers should use a governance paradigm something like the original requirements paradigm: define all the risks at the beginning, and then only review plans and progress thereafter, resisting--with governance--changes during the course of the project.

I said no.

You can't freeze risks any more so than you can freeze requirements. The world simply does not stand still, and perhaps that is more true for risks than requirements, though I'm really not sure. In any event, as the requirements governance paradigm has evolved, and means and methods developed to deal with change--and perhaps Agile is the most extreme but not exclusive means and method for doing so--so also a regimen for risk management should have a governance mindset to deal with volatility.

To my risk management students I have posited the "cone of uncertainty", something written about by many, to include Dr Barry Boehm.  The cone gives a temporal dimension to risk: the farther out in time, the more optimistic we are in evaluating risk.  There's simply more time to deal with it; we feel we can fix it.  Closer in time, some options are off the table, and we're more pessimistic.  The cone begins to close down.

Thus, if for no other reason, the risk register can not be static.  Even we don't discover any new risks, the risks so far identified will change character, or our assessment of them will change--we call this utility--and the risk response will change with accordingly.

So, bottom line: there can be no static up front identification and assessment.  Even the PMBOK agrees that the process is repeated throughout the project.

Got to keep it relevant and current.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.