How do we present a cost estimate to our project stakeholders?

We can give them a number that we all know, based on past history, the project is unlikely to make.

One approach suggested on a project management forum, is something like "I'm 60% certain we can do it for $450,000," and hope no one asks about how much the other 40% is likely to cost.

A slightly more enlightened declaration would be "I'm 90% certain we can do it between $360,000 and $875,000." That, at least, recognizes the uncertainty in the projected cost.

All of these and related approaches fail miserably in that they don't give stakeholders a voice in choosing how much risk to accept in the project outcome. In fact, for any one project plan, there are many plausible cost outcomes, and for each, a probability that it'll turn out to be the actual cost. In other words, the project budget projection has a probability distribution.

How to get that distribution? The short form of the prescription is to replace every uncertain number--every average, every expected value, every number that has a less than 100% probability of being right with a probability distribution, and use Monte Carlo simulation to compute the project outcomes. That's a whole separate topic I'll address in a future post. Right now, let's talk about the result we want to present to our stakeholders.

The best way to present the relationship between probability and cost is with a cumulative probability S-Curve.

This curve plots cost against the probability that the project will cost that much or less. Another way of looking at it is that it plots budget against the probability of success--finishing at or under budget. With this information, stakeholders can decide how much risk they are comfortable with and allocate the budget accordingly.

If they are risk-averse, they might choose $1,150k with its 85% probability of success. A different group mught take a lower budget with its lower probability of success, say $1,050k at 50%. There is no algorithm that can make that choice; it takes well-informed people.

On the other hand, they might reject the tradeoff altogether, and it's back to the drawing board.

There are always different possible plans. In particular, changes in the level of concurrency change the probability distributions. The plan can have a lot of things happening at the same time--faster but it needs a bigger team, more coordination, and it's relatively more expensive. It can have low concurrency, with the activities stretched out in time--slower, smaller team, and relatively less expensive.

I discuss this in previous posts: Sampo Zashi and Project Planning is Process Design

In any case, a comprehensive presentation would include multiple s-curves plotted on the same graph--one for each of several different plans, so that stakeholders have more possibilities to choose from.

Time is also an issue, so each plan would come with an s-curve for the schedule. The schedule is closely related to the cost curve, so picking a plan and a cost invokes a schedule. There's an interesting scatter plot that brings it all together, relating cost and time and risk for each of the plans so that any particular decision or commitment is a point in the scatter plot.

I'll talk about those in future posts.

## No comments:

## Post a Comment