More on the agile value question

If you are PMI member and interested in Agile, perhaps you caught Jim Highsmith's webinar presentation on agile in the PMI Agile Community of Practice [CoP]. Presented live in March, 2011, it's still available for viewing if you login and join the Agile CoP. [Search under 'webinars' tab for past webinars: "Beyond Scope, Schedule, and Cost: Rethinking Performance"]

One of the main points he makes is that whatever product feature or function is developed and delivered it should have two valuations:

• A top-down allocation from sponsors or those making the investment in the project
• A bottom up estimate of effort [read: cost] to develop

Highsmith was not clear on this point: is the value allocation from the intended investment to be made in the project, or is the value a proportion of the total benefit expected, adjusting for time with discounts?  Given the uneven nature of ROI, this distinction could be important.

Highsmith makes the oft described admonition: the top-down valuation should exceed the cost to develop.  Said another way: 'quality' is often defined as getting more for your money than you might have expected.

Of course, in my experience, it can go the other way: the cost to develop exceeds the value allocation.  In fact, it often goes the other way.  Sponsors, users, and product masters are--as a group--more optimistic than project managers.  Consequently, they  underestimate risks, overestimate benefit, and most often underestimate cost.  As a group they are afflicted with optimism bias.

What then? 

That's what I call the project balance sheet risk:  there's a gap between resources needed and resources expected to be provided.  To close the gap, the project manager takes a risk with an intent to find a way to deliver.

In the webinar, one listener asked the obvious question, which I paraphrase: Where does a credible dollar figure come from for the value side of the equation?

Highsmith seemed not to have an answer ready with which he was comfortable.  He said, in effect, value assignments are made by allocation, but he had no rules or protocols to offer about how to go about this.

What he should have said was:
Of course, there's no universal definition of value; rather, there're many definnitions of value, much like there're many definitions of quality, no one of which is 'the' definition.

That said, it's a matter of environment, experience, competition, history [reference projects] that all combine to provide a value judgment that is a few parts rational [that, is facts] and a few parts emotional or qualitative [that is, the art of the situation].

It should be obvious: there's no formula for getting a value judgment right.  The Nano failed and the iPod soared.  It happens.

But also: the farther down the WBS you get, the less valid is any value judgment.  What you get is more of an ordinal valuation: "this is worth more to me than that". 

And, you get anchor bias: "that's what it cost last time, so that's what it should cost this time".  The first one to throw down the anchor, whether the value figure or the cost figure, has the negotiating advantage.

However, the power of agile is that this judgment is frequently revisited, and in the revisit process there is opportunity to evaluate, calibrate, and test the value judgment.

And by the way: I'm talking about the business value of the investment, not the business value of the opportunity.  Highsmith didn't talk about it, but there's actually three parts to every project econometric:

• How much a sponsor wants to pay
• How much a project needs to succeed
• How much the business expects to earn from the investment

The value allocation is made from the investment at bullet 1; the cost estimate is made at bullet 2; the ROI is estimated from bullet 1 and 3. Usually, a NPV discounted cash flow analysis is done so that all econometrics are in the same timeframe.

Bottom line: There's an art [value] and science [cost estimating] to be reconciled by iterative reexamination as progress accumulates. Of course, this is not exclusive to agile; every methodology includes this idea. It's just that agilists accept it as a centerpiece of agile management.

 Bookmark this on Delicious  

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

Seven rules for risk and uncertainty

John Carlos Baez blogs at "Azimuth", a kind of 360 look at number of grand challenges, the current focus of which is climate change. Baez is a mathematical physicist, so a lot of his posts are steeped in formulas and technically oriented.

However, for those of us with a more ordinary grasp of mathematics, a guest post by Curtis Faith caught my attention--and it's readable by all.

Faith lists his "seven rules for risk and uncertainty" which are taken from his book "Inside the mind of Turtles", a treatise on financial trading risk.

By Faith's reckoning, the seven rules are these:

1. Overcome fear,
2. Remain flexible,
3. Take reasoned risks,
4. Prepare to be wrong,
5. Actively seek reality,
6. Respond quickly to change, and
7. Focus on decisions, not outcomes.

The one that gave me a double take, especially from the view of project management, is the last: "Focus on decisions, not outcomes". Frankly, I'm an 'outcomes' guy.

However, a close reading of Faith's point is that when facing decisions about risky outcomes, especially those that may have calamitous outcomes, the rule really is :
Don't be paralyzed in the decision process by the impact of the decision's likely outcome; make a decision based on an integration of best practice, experience fit to the circumstances, and the impact of not deciding.

The other rule that seems a little unusual as stated is "Actively seek reality".  Here again, one has to read between the lines.  An alternate construction: "Constantly monitor the situation to ensure relevance and applicability of risk assessments and responses."

Perhaps I'll conclude with Rule 8: When reading rules  1 - 7, translate them into a relevant project context.

 Bookmark this on Delicious  

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

Sampling ideas for project managers

Recently, I authored a paper on how project managers can use, and should use, statistical sampling of large populations to reduce the cost and timeliness of handling very large data sets.

I posted the paper at slideshare.net, and you can take a look at it there, or click on the embed below.

Whether sampling for proportion, like what proportion of process users require or endorse this feature or that one, or sampling for descriptive statistics, like the average error rate among development objects, the fact is almost every project manager runs into situations that are best handled by sampling over the course of a few projects.

If you've some Six Sigma familiarity, then you've already studied these techniques. If you've got to explain things to a functional manager, this paper might help.

I used these ideas on a recent ERP project where we were faced with converting millions of data records from legacy systems to the ERP system. We never would have had time or money to validate the readiness for conversion without these techniques.

Project examples for sampling and the law of large numbers

View more documents from John Goodpasture

 Bookmark this on Delicious  

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

WBS benefits

A posting by Brad Egeland entitled "Benefits of the Work Breakdown Structure" caught my eye because, above all else, the activity to create such focuses the mind and draws attention to the architecture of the project outcomes.  And Lord knows, obtaining focus is no small matter!

Creating a WBS is an exercise in disaggregation: breaking things down into pieces and parts from a top-level notion of what the outcomes should be.

However, I've found it handy to then add the pieces and parts up from the bottom and see if their summation reveals any gaps. 

That's the well-known 'V-model' from system engineering: break it down, then add it up and verify the top-down and the bottom-up come to the same project outcome.

Many recognize the 'V-model' as a variant of the well known dictum: "Tell them what you're going to tell them; Tell them; Tell them what you told them"!

That's why when I first saw Egeland's first bullet, I thought "right!", that's close to my thinking also.  But, alas, his detailed description seems to confuse schedule and WBS.  He writes:

1 – WBS forces the team to create detailed steps

The WBS forces the project manager, team members, and customers to delineate the steps required to build and deliver the product or service. The exercise alone encourages a dialogue that will help clarify ambiguities, bring out assumptions, narrow the scope of the project, and raise critical issues early on.

NO! The WBS does not delineate the steps to build anything. Actionable steps to do things are in the schedule.

If by 'steps' Brad means disaggregated deliverables, then ok. But if by 'steps' he refers to activities to achieve those deliverables, then NO.

There's no time line in the WBS, and as debated here before, no work in the WBS either. The WBS is just the proceeds of the work; and those proceeds--that is, deliverables--end at the 'water's edge' of the project.

 Bookmark this on Delicious  

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

Time Management of Complex Projects

Lynda Bourne has a post about a new book to be published in the United States this month: "Guide to Good Practice in the Management of Time in Complex Projects" . It was written by the Chartered Institute of Building in the UK.

I was intrigued by the title, and although I have not read the book, there is a nice 8 page Preamble at the publisher's site that invites more reading.

From that free document come the principles shown below. Of the four principles listed, three deal with risk--I guess that follows naturally from the topic of the book which is complex projects, complex enough to require some serious analaysis to synthesize a schedule from the project plan.

I like the one second one because it speaks directly to the role of architecture in the design of the project narrative and the management of risk. I don't necessarily agree that parallel structures are needed, but definitely there needs to be loose coupling between problematic elements, even in sequence.

In order to achieve effective time management there must be:

■ A competent appraisal of the risks which are likely to severely disrupt and delay the progress of the work;

■ A design which permits the work sequences that are likely to be severely disrupted and delayed by foreseeable events to be separated into parallel, rather than sequential paths;

■ A‘ time - model ’ for the project against which progress, or lack of it, can be measured;

■ A practically achievable strategy for dealing with intervening events during the design, procurement and construction processes.

 Bookmark this on Delicious  

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

Controlling chaos--really?

The April digital edition of PMnetwork has an article entitled "Controlling Chaos", a title meant to be provocative and eye catching, even if it is an oxymoron. After all, the mathematical or engineering definition of a system with chaotic properties is one with dynamic properties such that small changes in initial conditions render widely varying responses that are all but impossible to predict.

Some call this the 'butterfly effect', as illustrated by this recent example: A vegetable vendor in remote Tunisia sets himself on fire, and twelve weeks later a myriad of political events have transpired: two Arab governments have fallen and NATO bombs Libya.

So, now we learn there is a formula for chaos 'control'?

I don't think so.

Actually, the PMnetwork article had almost nothing to say about chaos, but focuses instead on possible but infrequent events, the so-called Black Swans.  Black swans and chaos are really not the same thing; the former could the outcome of the latter, but chaos is more about systemic responses.

But, the subject matter is timely, what with the Gulf oil spill last year, the earthquake et al in Japan, and the 'Arab spring', to name just a few recent events.

In the PMnetwork article, many managers give their advice: the universal black swan strategy seems to be to formalize a process of imagining the possible and then imagine the response. One manager recommended segregating Black Swans onto their own risk register.

That's advice I endorse. Effective management requires effective compartmentalization and affinity grouping. If you are going to walk and chew gum, it's best to have the gum separate from the walkway.

But here's my main point: if you can't practice, model, or simulate the response, or don't make the investment to do these these things, then you're probably just tilting at windmills. In some cases, given the complexity of some events, you might even have engage 'game theory' to evaluate responses.

What I'm saying is that atrophy sets in quickly in these one-off events. When you need it, response and responders are often unavailable, untrained, inoperable, rusty, or perhaps they don't even work as designed.

We learned last week that the blow-out protector for the Gulf oil well actually tried to do its job, but it didn't work as intended because designers didn't imagine that the well pipe might be bent by other calamities, like a gas explosion. Even worse, the performance shortfall may have been caused by a ubiquitous feature of the design.

Everyone it seems has their own black swan story.  Here's mine:

About ten years ago I was responsible for a business unit in Manila where I had 400 employees working in a downtown office building on the 4th and 5th floors. 

At the time, Manila, a city of 12M or more, was notorious for poor fire fighting response in the urban center.

There was only one small staircase for emergency exit.  I ordered my local managing director to organize and practice a fire drill.  Of course, the first issue was: "what is a fire drill?"

Second issue: no where to go. At first no other tenant, like the adjacent parking lot, would agree to let our evacuees assemble. [They wound up across the street in the mall]

A few weeks later I got an email in my office in Atlanta reporting the drill metric: 45 minutes to clear the two floors.  I called to find out why so long?  The answer: everyone was slowed down because they felt compelled to carry their desktop computers to safety!

The point: imagining the event [a fire] and the response [an orderly exit via the escape stairs] was not enough.  You have to invest in training, organization, and practice to have a workable black swan response!

 Bookmark this on Delicious  

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

Cockburn on leadership

Alistair Cockburn--the humanist of project management--writes in what you might call a 'conversational tone'.

Here's a bit on leadership--actually, the posting is on "Leader or Manager?"--wherein he comments on what's he heard at the NASA Project Leadership Forum of 2009:

... to “lead” already implies “change”. So a leader leads a change. (Somehow this thought had escaped my notice – had it escaped yours? It hit me pretty hard in the lecture.)

If the leader in question is the PM, the person is leading a change in order to stabilize things (we can lead in order to increase stability). (This thought knocked my socks off.) ... and then the PM can “manage” the stable ongoing situation.

I think I'll just let his comments stand on their own, except to say his posting has a rich compendium of commentary from the forum, well worth a look.

 Bookmark this on Delicious  

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