Top Ten Reasons Why Projects Fail – Reason #5

Reason #5 – Estimates

The Project Management Institute’s (PMI) book of all things project management (PMBOK) has a chapter dedicated exclusivey to risk. There are several facets to risk management but the one I want to mention today is risk identification. Yes, I know, we’re talking specifically about estimates here. But what I wanted to point out is that as input to the identification of risks, PMI posits several items, two of which are notable for our discussion. One is activity cost estimates, the other is activity duration estimates. Hmm. Why should those two factors be significant inputs to the creation of a risk register, which contains all your identified risks?

Because, simply put, they ARE risky items. Why? Because when all is said and done, estimates are frequently guesstimates. In my experience, most team members are just guessing at how long something will take or how much it will cost. This is because they truly have no idea of how long something will take or how much it will cost. (For sake of this discussion, I am going to focus on estimates of duration or time here. Not only for brevity’s sake but also because in my experience I have found that most PM’s are not asked to deal with cost. But that’s another discussion).

Let’s say you have a team member, call him Bob. He is a software developer and he has several tasks whose duration you have asked him to estimate for your current schedule. So he sits and thinks about all of his tasks and gives you duration for each one. So, e.g., 10 days for task A, 20 days for task B, etc. How does he come up with those estimates? Well, typically by thinking back to what he’s done previously. And maybe adding in a day or two for complexity over and above what he’s done before. And surely he’ll add in a day or two for buffer so that he can meet his schedule. And so now you have a 20 day estimate that for all you know might really be 10 or even 30 days! Minus any kind of historical record, there is no way to gauge the accuracy of his estimate. Multiply this by all the team members on the project and you can see why PMI declares this to be a risk. Simply put, you are basing the end date of your schedule on a bunch of guesses by a bunch of team members who are not certain how long their tasks will take.  And then you are presenting this schedule to management. And as you may know, once a date on a schedule gets published – and gets out to the world –  it’s really hard to change.

Now this is not to say that there are no estimation methods out there in the world. Even though I’m using software developers as an example, they do have methods they use that are described in books. I’ve heard good reports on books such as “Software Estimation: Demystifying the Black Art” by Steve McConnell, for example.  (Not a plug, BTW. Just to let you know that these books do exist). And construction people often use industry-specific standards. But in my experience, most team members don’t have or use such methods. (And I spent a lot of years in IT working with software and hardware developers. In all that time I think I met one guy who knew of and worked with software estimation methods).

One possible solution to this dilemma is to estimate as a team. So if you are currently planning a project, have team members firstly come together to work out their estimates as part of, say, their WBS development. I always advocate that method for a variety of reasons, not the least of which is team buy-in. Then you can work on a consensus estimate rather than just an individual one. Secondly, as the project runs, keep track of how close to the estimate that actual work was. This will take some diligence on your part but it’s a worthwhile effort. You’ll find that some teams and/or team members are more accurate than others. You can use this as input for the lessons learned meeting. Also, keep historical records of various projects over time. You can then look back at these records and see what was estimated previously and what did and did not work. (One technique you can consider ia what is called a PERT estimate which is a calculation of the optimistic, pessimistic and most likely estimates. But it’s difficult to get team members to estimate their many tasks this way).

Like many of the other things I talk about, these methods (historical records, etc.) often don’t get used because they just feel too cumbersome and time-consuming to the team (and to management). But I would argue that lack of these tools will create much higher risk and lower level of confidence in your schedule.

(Coming soon – the ever-popular but woefully underused risk management)