Top Three Things You (Probably) Didn

Whenever I have a chance to teach a project management course at BCIT (British Columbia Institute of Technology) or in corporate environments, I usually start my class by presenting my students with the following scenario:

”Imagine, that I walk into the most upscale and exclusive car dealership in your city and ask for the latest model of a Ferrari with a number of custom features. I also specify that I will need a car by tomorrow and that I am willing to pay $5,000 for it. What do you think would be the reaction of the salesperson?”

By the time I am done with my story, most of the students in the class are giggling and exchanging puzzled looks. Finally one or two of them present me with the following scenarios:

• A car dealer would kick me out of the showroom 
• He would call the police 
• He would call an ambulance to have my mental facilities checked.

After the excitement subsides, I ask another question, “How many of you have witnessed a variation of this in your project management career?” This question is usually greeted with silence and somewhat painful expressions on people’s faces.

So, why do we keep seeing scenarios like this one in our professional lives? Are we not doing our jobs properly or are we just extremely unlucky? What’s wrong with our estimation efforts and what can we do to fix them? In this article I intend to analyze the key root causes for our estimation failures and provide some tips that should make life easier.

What are the Root Causes? We are Bad at Estimating

It has been proven by numerous studies that humans invariably tend to underestimate the time and the effort required to accomplish certain tasks. This phenomenon is applicable even in the situations when the person providing the estimate is an expert in the technical field.

Another contributing factor is that the estimation process, no matter how sophisticated, is a guessing exercise similar to weather forecasting or stock market predictions. Our everyday experiences confirm the fact that either one of the above undertakings is prone to wild variations and inaccuracy.

We Ignore All Available Degrees of Freedom

Projects in the technology world are frequently measured (sometimes for the purpose of false simplification) on a one-dimensional scale, i.e. time. Most of the projects usually start with a supervisor or customer approaching the project manager and saying: “Hey, I have a project for you; it needs to be completed in six months … Can you do it?”

For the rest of the journey the only variable in the project is the deadline. It either can or cannot be moved along the time axis to the right or to the left of the desired completion date. Needless to say, the more it is moved to the right of the desired milestone, the higher the rate of customer dissatisfaction. All other dimensions of the software development project including effort (manpower), scope and quality are usually ignored, thus removing additional (and very valuable) degrees of freedom.

We are not very good at understanding our counterparts and at negotiating

Finally, there is another key obstacle that both IT and business sides find very difficult to overcome. On one hand, business people usually do not have any expertise in technology, requirements gathering or project management. While it is fairly obvious to an “average” person that a customized Ferrari cannot be sold by the dealership for $5,000, he will usually have a very hard time understanding why a “simple” web development project can cost $100,000.

On the other hand technical people are either too intimidated or too lazy to explore different options that will allow them to properly align the technological capabilities of their departments with the business needs of their customers.

Do not set yourself up for failure even before the project has started

Warning: in order to understand this concept we need to revisit university statistics!

If you assign the same project to identical teams, repeat the experiment infinite number of times and plot the cumulative frequency of project durations of the XY plot, here is what it would probably look like

Note, that the area under the curve shows the probability of finishing the project on or before the specific date. In this particular example, six months is an absolute minimal time needed to accomplish the project.

For the purposes of our exercise let’s assume that the expected duration of the project is nine months; i.e. there is a fifty per cent chance of finishing the project before the nine-month mark and 50% chance of finishing after. This point is marked as the “Fair Estimate” in Figure 1.

What happens if you succumb to the customer’s pressure and agree to deliver the project in, say, seven months? (Figure 2) Suddenly the chance of delivering the product on time decreases from a relatively comfortable 50% to approximately 20%.

What would happen if you come under even more pressure and agree to a four-month deadline? It is obvious that the chances of finishing the project on time are now zero! The ironic aspect of this situation is that you haven’t even started the project yet …

In some cases project managers “cheat” by padding their estimates. Let’s examine what happens in those cases. (Figure 3)

It is obvious that, by padding their estimates, project managers can increase the chances of finishing their projects on or ahead of schedule. Typically, while somewhat effective in the short run, this technique usually backfires in the long run. Eventually management and/or customers will notice that, for some reason, your projects take longer and cost more money than similar projects handled by your peers.

Having said that, there is at least one scenario where padding is justified, providing it has been communicated to the customer. What happens if you are responsible for a regulatory project that has to be completed by a specific date? Would a 50% probability of finishing on time be sufficient to the customers? Probably not. In such cases giving your team 12 months to deliver the project (see Figure 4) would most likely be more appropriate than nine months.

Cone of uncertainty

One of the most counterintuitive things about estimating is the principle of uncertainty. We are used to think of estimate as a single number, e.g. “we will finish this project in six months”, “this project will cost us $15,400”, etc. Interestingly enough, the guide to Project Management Body of Knowledge (PMBOK) defines the estimate in the following manner:

“An assessment of the likely quantitative result. Usually applied to project costs and durations and should always include some indication of accuracy (+/- x percent).”

This definition implies that the estimate, although a solitary number in our minds, is actually a range with an implied minimum and a maximum. If we look up the PMBOK guidelines for estimation we will discover that recommended estimate ranges are:

• +75/-25% for the Initiation stage 
• +30/-15% for the Planning stage and 
• +10/-5% for the Execution and Control stages

In other words if the actual cost of the project turns out to be $100,000, it is absolutely acceptable for the project manager to provide the customer with an initial estimate ranging from $175,000 to $75,000.

The study of IT and software companies conducted by Barry Boehm (the “father” of software economics and estimation) demonstrated the funnel for software development projects was even wider. Among other things it showed that even good software development companies were in +300% -75% accuracy range when estimating early in the project life.

Work with all the degrees of freedom: Understanding The PM pentagon

Approximately five years ago I was introduced to the concept of the project management pentagon (I was using a triangle before). While it is very similar in its concept to the PM triangle, the pentagon differentiates between the concepts of “Cost” and Effort” and between “Scope” and “Quality”.

The first differentiation is explained by the fact that some companies (especially government agencies) usually have a fixed headcount (i.e. effort) but frequently have enough funds to outsource work to contractors.

The second differentiation is, in my opinion, more important for project managers because it acknowledges the fact that the number of features produced and their quality do not necessarily go hand-in-hand. If you are having difficult time understanding this statement, try to remember the first Windows 95 release. The operating system had a lot of new features when compared to the previous versions of Windows. The quality of the program, however, was far below the level required by customers.

Transition from the one-dimensional approach, described earlier, to the five-dimensional picture provides project managers with more flexibility and opens more options. Once the project is assigned to you, start analyzing alternatives and asking questions like:

1. Do we have a fixed or a flexible deadline? Can it be moved? 
2. What is the size of the team assigned to this project? If we discover that we need a larger team can we get extra bodies relatively easily? 
3. If we can’t increase the team size, do we have enough money to outsource some of the work? Will this be permitted? 
4. How flexible is the scope? Which features are “Must-have” and which ones are “Nice-To-have”? 
5. What about quality? Will we have to fix all the bugs or just 95% of the key ones?

Obtaining the degrees of freedom

I like to call this a game of “How Badly Do You Want This Project To Succeed?” With proper preparation this is one of the most exciting tasks a project manager gets to do in any project! Once you have formed your initial opinion of the project and have analyzed the above questions, try channeling your curiosity towards customer and/or your own management. Here is a list of sample questions that you can use to improve the chances of the successful delivery of your project:

• Can we deliver only the “Must Have” features? (Scope) 
• Can we split the project in two phases and deliver certain features later? (Scope) 
• Is it possible to even cut some of the features? (Scope) 
• Do we really have to perfect and hone all the requirements? Can we relax certain design attributes? (Scope) 
• Can you (your boss) provide me with more programmers? (Resources) 
• If you (your boss) can’t provide me with more programmers, can you assign more experienced ones? (Resources) 
• Can you (your boss) provide me with a more experienced business analyst, tester, architect? (Resources) 
• Can you (your customer) be more involved in the requirements elicitation process? (Resources) 
• Can we set a schedule goal but not an ultimate deadline? (Time) 
• Can we use estimation ranges, and agree to refine them as the project progresses? (Time)

As I have mentioned earlier, there are two surprising aspects to this methodology. Firstly, you would be surprised how many different doors open for you when you ask proper probing questions! Secondly, if the answer to all of the above questions is an emphatic “No, I can’t do that!” you can draw your own conclusions about how much your customer and/or boss are interested in the successful delivery of the project.

Change your strategic approach: Presenting your estimates properly

We have already discussed the fact that an estimate is not usually a single number but a range that typically includes a minimum and a maximum. Here is a list of other options for effective estimate presentation:

• Plus-or-minus qualifiers – e.g. “6 months ± 2 months” 
• Ranges – e.g. “4 months to 8 months” 
• Cases – e.g. Best case – 4 months, Most likely – 6 months, Worst case – 8 months 
• Coarse dates and time periods – e.g. “three-quarters” instead of “270 days” 
• Confidence factors – e.g. “We are 95% sure the project will be done in between 90 and 118 days

Pre-packaging available options for better understanding

Here is how you can take your estimation methodology one step further and really impress your management and clients. Let’s assume that you have been given a project described in Figure 1 i.e. there is a 50% chance of delivering the project in nine months. Your boss, of course, expects you to deliver the project in seven months. Instead of saying “yes” or “no”, you can prepare a list of possible scenarios that may look something like this:

OPTION 1:		OPTION 2:		OPTION 3:
Scope:	Remains the same	Scope:	Decrease number of features by 20%	Scope:	Decrease number of features by 10%
Time:	Seven months	Time:	Seven months	Time:	Seven months
Effort:	Add two developers and replace the business analyst with a more experienced one	Effort:	Remains the same	Effort:	Replace the business analyst with a more experienced one

Beware of these difficulties:

So, what are the drawbacks of these methods? I have to be honest; there are a couple of aspects associated with this approach that can make your life a tad more complicated.

Firstly, you will have to be more courageous than before. Your bosses and customers may be somewhat “surprised” if you start grilling them with questions outlined in the “Obtaining The Degrees Of Freedom” section. I have personally been in situations where customers’ and/or management’s reaction to such questions ranged from surprise to utter outrage. However, the good news is that it only takes one successful run through the project to completely win these people over and have them convinced of the effectiveness of this technique.

Secondly, you have to do your homework every time you meet with the customer. You need to be armed with some historical data and/or PERT estimates to be able to prove your case. This implies dedicating a certain amount of time for going through “what if” scenarios, and having enough academic knowledge in the estimation methodologies.

Finally, you have to be able to put on a “business thinking” hat. Your manipulations with the project management pentagon have to make business sense; otherwise your whole effort will be wasted.

Conclusion

To sum up, here are the steps you will need to take to greatly improve your estimation efforts:

• Understand the relationship between estimates and probabilities 
• Use the “Cone of Uncertainty” to your advantage 
• Understand the project management pentagon concept and utilize it to obtain various degrees of freedom for you and your project team 
• Learn to present your estimates properly 
• Do your homework 
• Be brave and don’t forget to put your “business thinking” hat on when talking to customers!

Good luck with your projects!

---

Jamal Moustafaev, BBA, MBA, PMP is president and principal consultant at Thinktank Consulting (www.thinktankconsulting.ca, an industry leader in providing management consulting services to North American software development companies and IT shops. Services include: project management and requirements engineering; business analysis consulting and outsourcing; process improvement programs and audits; business process re-engineering; change management; requirements engineering; estimation; project management; portfolio management; IT business alignment and training. Jamal Moustafaev can be reached at [email protected] or at 778-995-4396