The Project Coach

One of the most perplexing dilemmas of any project portfolio process, a catch 22 really, is how to estimate the size of the potential candidates being submitted before the selection board.  The catch 22 is that the selection committee wants an estimate of how much the project will cost before they can make a decision on whether to approve of it.  However, no work has been done on the project yet to define the scope or requirements to know what work would be necessary.  In fact the team that could even do the estimating has not yet been assembled.  No one wants to even invest the time to do any discovery until they understand the overall cost of the project.  So, if you are a program manager, you argue, it is impossible to determine a reasonable cost.  The decision makers counter-argue that they cannot make a decision without some kind of budgetary number to consider.  So you assemble a technical team and ask them to give you some kind of ballpark estimate based on the very sketchy facts you have at such an early point in the project.  They of course protest, suspicious that they will be held to the number when requirements balloon later in the project.  And round and round you go …

There is no silver bullet answer to this.  You cannot get a high quality detailed estimate without detailed requirements.  One simple approach to this however, is to not try to over think things at the project selection stage.  It is an established fact that estimates have a greater degree of risk and less certainty earlier in the project when less is known.  Rough order of magnitude (ROM) estimates made during project initiation can have margins of error in the range of +-50% from actual.  As the project progresses and knowledge increases, the risk goes down and the margin of error on the estimate decreases to as little as -5 to +10% when all the requirements are hammered out.  So beating the team up to get a binding estimate at the beginning is futile and the selection committee should be educated on that.  A technique that works better is using range buckets.   The ‘McDonald’s approach’: i.e.  - small-medium-large works very well for this.  Usually a project request has been documented briefly with some amount of information regarding high level purpose and objective, business need and justification.  Based on this, a technical resource should be able to slot the project into one of 3 possible ranges or buckets such as:

The actual numbers associated with small, medium, and large, can of course be adjusted to whatever makes sense in your organization.  This first estimate should be understood to be within some amount of error, depending on the detail in the project request, but enough to determine approval.

We like to re-visit estimates twice more during the project.  After the scope baseline has been defined, a second estimate, considered a “planning estimate” is developed.  This should generally be between 10 – 25% from actual. The third time is after detailed requirements are developed and clarified between the business and the implementation team.  That is when the team should achieve the -5 to +10%  accuracy.  The rule is, at each of these points if the new estimate varies significantly from the understanding of the project steering (approval) committee, the team must seek permission to continue, or make adjustments to scope to get back to the cost in the original estimate.  That way the team is protected from being saddled with work they didn’t get funding for in the original estimate, and the sponsors stay in control of costs.