Beyond Execution

This topic came up in one of my classes.  Here is the conundrum:

Project managers pretty much know that the estimates we receive from team members have padding in them. There's a mixture of CYA and pride involved; people don't want to fail by giving a number that is too low, so they tack on a bit extra.  And while we know that, PM's generally don't dispute it very much (2 exceptions - either the number is completely out of whack or the PM has a good basis to refer to). And many times, PM's will tack on additional contingency onto these estimates, creating a greater sum than before.

 

And yet, here is the head-scratcher - many times, the project will still run overbudget!!?!  This has to be in the top 3 problems facing all projects (anecdotal statement, I have no statistics to back me up here).  So what are we doing wrong here?

There are a few possible reasons for this that I can hypothesize:

1)  The individual estimates are inaccurate.  The interesting thing here is that the team members know that it is inaccurate, which is the usual reason why they add padding.  But they are STILL OFF THE MARK!  So we need to develop better accuracy into the numbers somehow.

a)  One method is to decompose the estimate level to much smaller pieces.  This is PM 101, what the PMBOK tells us to do.  Take the WBS and decompose to smaller elements, the rule of thumb being 40-80 hours of work.  This will allow a tighter range of estimation, while at the same time, minimizing the risk of a large over/underestimation.  Don't accept estimates that are greater than 15 days (3 weeks).

b)  Estimates are not being compared to previous estimates or results.  If there is sufficient historical information (to borrow the PMBOK term), there should be a better estimate.  Have team members look up previous examples, talk to other team members on the risks and issues that were experienced.

c) It's possible that the team members are not experienced enough to provide a proper estimate.  Take a look at their background and their track history.  See if they need training, mentorship or just more closer supervision.

d)  The estimates need to be calibrated.  I'll write this up in another post later on, but there is an excellent method described in the book "How To Measure Everything" by Dr. Douglas Hubbard.  Bottom line is, after calibration, team members should be able to give estimate ranges with a percent confidence level.  We should use this confidence level to establish...

2) A better risk analysis.  Another root cause of budget overruns is that unforeseen issues have sprung up and consumed additional time and effort.  I certainly won't suggest that the PM can foresee everything that can happen on the project, since it's pretty much impossible.  The reality is, risk identification can be a poor implementation in real practice, so many risks may not end of being identified, and subsequently planned for.  One way to improve this is to use a better risk identification tool/method.  Look up previous risks for similar projects.  Talk to other people from previous teams.  Use VIRT (see my whitepaper section).  Use checklists.  Use three point estimates and find out why the difference between best and worst case numbers.  Then avoid/transfer/mitigate/attack/allocate contingency against them.  (Note the missing approach of 'accept').

3) The scope is misunderstood.  Use the same approach as doing a root cause analysis and continue to ask "why" until there are no further answers.  Dig deep and leave no stone unturned.  Create more assumptions, communicate them at the beginning of the project and validate them frequently. An invalidated assumption gives you an "out", to make adjustments to your scope, schedule and budget. This is not CYA, this is good project management practice. You have a baseline - protect it.

4) The estimates are not coming from the team members performing the work.  Yes, we would like this to happen but reality is that this isn't always possible.  So to get around this, we should at least get the performing team members to review the estimates and validate them.  Get them to a 95-100% confidence level for validation - this means they better do their homework and making sure they agree with the numbers.  Otherwise it will just be an excuse parade when they go over - "I didn't give the estimates", "Well I didn't believe in those numbers from the beginning", "The estimates were not realistic" etc.

Anyways, this is a good start to finding and correcting the root cause of this common problem.  As always, I am sure there are more, and some are very dependent upon the company's culture and processes.  But chances are, it's something as basic as the above suggestions.