Was Your Project Late or Underestimated?
By Ben Snyder, CEO of Systemation
It’s amazing how a simple tool such as a project schedule, with multiple tasks and a project completion date, can create so much shame or joy for people in an organization. Taken at face value, completed tasks and projects bring about strong emotional reactions. If the task or project is late it’s a bad thing. If they are early it’s a good thing. Very black or white. Quick judgments about the outcomes imply negative or positive behavior respectively on the project manager or team member.
It’s common to hear statements like, “The project manager must have been unorganized or did not work hard enough to keep his team on schedule.” “The business analyst really knows what she is doing, superior skill allowed her to finish the requirements document early.” These judgments sound very cut and dry but, are they correct? Actually, they could be misplaced.
The problem with the above statements is they assume estimates are sound constants and a person’s skill, experience, and behavior are the only variables. The fact is, more often than not, estimates are flawed. If a project is completed late, perhaps the time required to complete the task or project was underestimated. Conversely, if a project is completed early the duration could have been overestimated. Yes, behavior and skill do vary but no more than project schedule estimates do.
In reality, most estimates that are underestimated come from lack of experience or succumbing to management pressure. Most estimates that are overestimated also come from lack of experience or risk adverse sandbagging. A lack of experience in estimating, the level of skills people posses, and odd behavior only improve with time. But when all these factors are taken into consideration a late task or project could simply be the result of management pressure and an early task or project the result of sandbagging. Now which person deserves the shame?
Next time you observe and assess a completed task or project, remember that you shouldn’t judge the results at face value. Dig deeper and look at the underlying circumstances, experience, behavior, and skill. That’s where the truth lies, that’s where just judgments are revealed.
Ben Snyder is the CEO of Systemation, (www.systemation.com), a project management, business analysis, and agile development training and consulting company that has been training professionals since 1959. Systemation is a results-driven training and consulting company that maximizes the project-related performance of individuals and organizations. Known for instilling highly practical, immediately usable processes and techniques, Systemation has proven to be an innovative agent of business transformation for many government entities and Fortune 2000 companies, including Verizon Wireless, Barclays Bank, Mattel, The Travelers Companies, Bridgestone, Amgen, Wellpoint and Whirlpool.
Interesting article Ben, that raises a question in my mind – how do we get better at estimating so that the same thing doesn’t happen next time? There are a few options here, including (but not lmited to):
+ Modifying base or generic estimates using an efficiency / skill rating adjustment to compensate for variations in speed between individuals or groups of people; (needs careful management as people could be sensitive about the efficiency / ability pigeonhole you put them in)
+ Using three-point (aka PERT) estimation (optimistic / pessimistic / most likely) and presenting the estimate as a weighted average of these.
+ Expressing durations (and therefore delivery dates) as a range rather then a single, point value. Then your project isn’t late unless it comes in after the latest date in the range.
Having said all that, if the delay is spotted early enough then it could/should be possible to extend the timescales with a Change Request, in which case the project isn’t really “late”.
But all this is academic if Someone In Power insists that you cut whatever estimate you present by 25%. Then you get into the padding / cutting game, which helps no-one.
Any thoughts anyone?
In the end… its not methodologies , tools, resources, customers or staff that make projects fail. Its just Politics. By definition, Isnt Politics devoid of set measures and agreed principles..
Each Manager up the chain has their own agenda (KRAs)
their focus is only on the month ahead till the next set of performance figures are due. Its hardly surprising that they press well beyond the carefully constructed estimtes. Which is why just over 50% of all projects in the US fail. Yet if they had more faith in their IT staff, the projects would not fail with such alarming frequency. When presenting their end date to the upper managers, tney ought to guote this figure and suggest they reconsider the 25% reduction in time.
just a thought..