Random Acts of IT Project Management

Project Management for Information Technology

Avoiding Project Estimating Mistakes and Constructive Pessimism

Posted by iammarchhare on 10 July 2009

It happens to everyone sooner or later.  Someone made an error in giving an estimate on a task or set of tasks.  The causes can be many.  Sometimes, the estimate might be fatal to the timeline of the project.  How can this be avoided?

Erik Eckel of TechRepublic says that his “Three tips for avoiding project estimating mistakes” are: 1. Confirm all assumptions, 2. Don’t expect trouble-free projects (aka plan for “unknown unknowns”) and 3. Specify exactly what estimates include (aka put it all in writing).  He goes into each of these in his article.

The Defensive Mentality

I’ve been an advocate for “defensive programming” for years now.  Developers are notorious for being overly optimistic.  They can’t fail.  After all, it is their code, and their code always works, right?  I know this attitude to be true.  I was a software engineer myself for a while.  Needless to say, my code did not always work right the first time.  I had to learn to expect that something will go wrong and plan for it.  Just like the driver learns defensive driving and plans ahead because accidents even to good drivers, the developer must plan for strange inputs and react accordingly.  The developer needs to come up with a test plan before coding.  The assumptions should be stated not only in design documents but also as code comments first.

I know what you are thinking, as I have thought it myself: That is going to add a lot of overhead to the project.  The plain and simple truth is that it reduces effort on the project.  Sure, your estimates will go up.  Sure, management is going to question why a module takes so long to code.  The answer is that it actually reduces coding time and, better yet, wasteful time produced by context switching, because there is less rework!  It puts the effort closer to the front of the project, where it is cheaper.  Have you looked to see how much rework occurs on projects?  How much of this was even planned?  Wouldn’t you like to reduce it, planned or not?

The project manager needs to be aware of this and prod people to adopt a defensive mentality.  Basically, when you look at Eckel’s three points, they boil down to being “constructively pessimistic”.  In other words, you expect bad things to happen and plan accordingly.  Even if you use defensive techniques, the PM needs to be pessimistic too and build in rework for a project.  To reword Eckel’s list slightly, the PM needs to challenge assumptions (pessimism that assumptions, particularly about inputs and outputs, reflect reality), not expect lack of problems (general pessimism that all will go as planned without any unit testing and without any rework) and be specific in communication (pessimism about understanding and being clearly understood).

No Fear

Eckel actually has a 4th tip, though.  Near the end of his article, he states, “Analysis paralysis isn’t just for politicians and leaders in other industries — it affects IT managers as well.”  Fear, in his view, makes you less efficient.  As we discussed yesterday in “Keys to Successful IT Projects”, this fear can lead to not making important decisions that would otherwise make the project successful.

So, while I advocate a certain amount of pessimism, don’t make the mistake of rooting the pessimism in grid-locking fear.  Constructive pessimism, however, simply acknowledges that things will likely go wrong and forces you to make a plan for the event.

Of course, you should plan for success as well.  After all, if you are being constructively pessimistic about your constructive pessimism, you’ll also realize that some things go right, so you need to plan for those events as well!

OK, I’m teasing, but only slightly.  Each event will either be a success or not.  What do you do if A goes according to plan?  What do you do if A does not go according to plan?  Always have a back-pocket plan if something of significance doesn’t work out.

Reality Check

Developers are notorious for being overly optimistic.  I have found that many infrastructure engineers are just as optimistic.  They don’t plan for failure, so they don’t know what to do when it hits them.  Many PMs have come up from the technical rank.  Unfortunately, these PMs sometimes still carry much of the same optimism they had before.

“Constructive pessimism” is the antidote to naive optimism.  Naive optimism doesn’t plan for things to go wrong at all.  Constructive pessimism says things will go wrong, but here is what we will do about it.  It provides a reality check to the team.

The funny thing is that this actually increases confidence in the overall project because contingencies have been identified that provide a safety net for the team.


Sorry, the comment form is closed at this time.

%d bloggers like this: