Why Estimate is a bad word

What is an estimate?

According to Dictionary.com the verb means:

1.
to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education.

2.
to form an opinion of; judge.

and the noun means

4.
an approximate judgment or calculation, as of the value, amount, time, size, or weight of something.

5.
a judgment or opinion, as of the qualities of a person or thing.

6.
a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work.

So, why is that a bad word? Well, I don’t think it’s really a bad word, but in the case of software development, the use of the word results in some serious problems.

Case 1: A developer leaves a task unfinished, that is not according to Definition of Done. The reason is that he’s run out of time according to the estimate so he drops it or finish it with lacking quality.

Case 2: A developer starts working on “something else”. The reason is that he finished what he was supposed to in less than the estimated time and felt free to spend the rest of the time with that other stuff.

Case 3: A project manager gets upset that a project is late. The reason is that he feels that the project is late because things took longer than the estimates.

So, why is estimate a bad word? It’s because it can cause people being pushed into not completing the tasks or not doing the things that have the highest priority. It causes confusion.

And if you consider a project where Case 1 and Case 2 are common, what happens? It causes some stuff to be bug infested which probably causes later delays and you’re never able to make up the time since when the developers are faster than the estimate, instead of moving on to the next item, they fill up the time with other stuff. Observe that I don’t assume that they are surfing the web or just idling, perhaps they refactor or something else. So, it is often good stuff, but not the most important stuff. And it does not help in catching up. So, what does this lead to; Case 3. If the project delivers poor quality and unfinished work and never makes up the time, of course the project will be delayed.

So, what word is better? Planned? Don’t think so, even if Microsoft Project use that word. This word most definitely leads to all these cases. Assumption is no better. When you think about it, you just have to realize that the word will lead to misunderstandings. So, what do you do?

Well, to handle Case 1 & 2 you need leadership and here I think that Kanban is a real savior. You cannot just drop the work and you cannot use the estimate as “your time”.

But what about that project manager? When it comes to the project manager’s need for planning, it’s important for him to realize that an estimate is a guess. A good or a bad guess. And when you’re guessing, you need to know the value of the guess. I like working the PERT analysis when this is a big issue (isn’t always??). You give three estimates; an optimistic, a probably and a pessimistic. Here is an excellent presentation on PERT analysis by Ricardo Vargas.

Pert Analysis in Projects

View more documents from Ricardo Vargas.

You can also add a value of risk to the estimate. So, when you estimate something, you estimate the size and the risk. And you would be stupid if you don’t realize that if you have a big task with a high risk, you cannot take that estimate for granted.

Microsoft Project Tutorial Part 20 – Debunking the critical path

The Critical path, a wonderful way to find the critical tasks in a project, wouldn’t you say? Well, perhaps not. Here goes. We have a project:

According to Microsoft Project. the tasks which are included in the critical path are A, B and D. How can I see that? Well, using the default Gantt chart you cannot see this, but if you switch to the Network Diagram (View—>Network diagram) shows you just this:

Other ways to view the critical path is to use the Gantt chart wizard or viewing the Tracking Gantt:

But what is the critical path?

Well, everything in Microsoft Project is based on calculations and fields and the critical path is no different. We insert two fields, Critical and Total slack.

Do you spot the pattern? Yes, what differs task C from the others is that Total Slack is over 0 and Critical is set to No. You cannot manually change Critical, since it’s based on Total Slack. So, the definition of a task belonging to the critical path is that total slack is 0, which leads to Critical being Yes. So, if we want C to become critical, we can change the duration with 3 days.

And if we add another day to the duration of C, guess what happens:

Yes, now that C > A + B, A and B are no longer critical.

If you look at this very briefly, it sounds all right, but really; we have no idea at this point which type of tasks we’re dealing with. Are all tasks as crucial? Critical path does not take into consideration how devastating it would be for D if C was not completely finished. Perhaps we can start anyway?

The problem is not unique to the Gantt chart view, the network diagram have the same problems and if you use some kind of PERT diagram, you will see the same definition.

As with everything using a tool like Microsoft Project it is important to understand how the program works. Think about your definition of a word like Critical and compare that to the definition in Microsoft Project.

I end this post with yet another setting in Microsoft Project. I wrote that the definition of a task being Critical as Total slack being 0. If you have very long tasks, this might not be very telling. Perhaps you want Project to highlight all tasks which cannot be delayed more than 5 days before turning red in your diagram. You can then select Tools—>Options. Select the Calculation tab and change the setting of Tasks are critical if slack is less than or equal to X days.