Home > Miscellaneous > Can we put an end to this ‘Estimate’ game of fools?

Can we put an end to this ‘Estimate’ game of fools?

When I was a young software programmer, I had to develop features with estimates given by more senior programmers. If more time was required for the task, I had to explain the reasons – and I’d better be convincing about that. After some years, I became the one who had to provide feature estimates, but this did no mean it was easier: if the development team took more time to develop, I had to justify it to my management. Now, after even more years, I have to provide estimates for entire projects, not just fine-grained features.

But in essence, what do we need estimates for? For big enough companies, those are required by internal processes. Whatever the process, it goes somewhat along these lines: in order to start a project, one needs estimate in order to request a budget, then approved (or not) by management.

Guess what? It doesn’t work, it never did and I’m pretty sure it never will.

Note: some organizations are smart enough to realize this and couple estimates with a confidence factor. Too bad this factor has no place in an Excel sheets and that it is lost at some point during data aggregation :-(

Unfortunately, my experience is the following: estimates are nearly always undervalued! Most of the time, this has the following consequences, (that might not be exclusive):

  1. In general, the first option is to cancel all planned vacations of team members. The second step is to make members work longer hours, soon followed by cutting on week-ends so they work 6/7. While effective in the very short-term, it brings down the team productivity very soon afterwards. People need rest and spirit – and developers are people too!
  2. After pressure on the development team, it’s time to negotiate. In this phase, project management goes to the customer and try to strike a deal to remove parts of the project scope (if it was ever defined…). However, even if the scope is reduced, it generally is not enough to finish on budget and on time.
  3. The final and last step is the most painful: go back to the powers that be, and ask for more budget. It is painful for the management, because it’s acknowledging failure. At this point, forget the initial schedule.
  4. Meanwhile and afterwards, management will communicate everything is fine and goes according to the plan. Human nature…

In some cases (e.g. a bid), that’s even worse, as the project manager will frequently (always?) complain that those estimates are too high and pressuring you to get lower ones, despite the fact that lowering estimates never lowers workload.

You could question why estimates are always wrong. Well, this is not the point of this post but my favorite answer is that Civil Engineering is around 5,000 years old and civil engineers also rarely get their estimates right. Our profession is barely 50 years old and technology and methodologies keep changing all the time.

I’m not a methodologist, not a Project Manager, not a Scrum Master… only a Software Architect. I don’t know if Agile will save the world; however, I witnessed first-hand every upfront estimate attempt as a failure. I can only play this game of fools for so long, because we’re all doomed to loose by participating in it.

email
Send to Kindle
  1. April 14th, 2014 at 09:07 | #1

    I do not fully agree, but in one point you are definitly right: Estimations are hard.
    May I ask you how you do your estimations? As far as I understood, you (or the senior members of your team) do the estimations for the whole team – shouldn’t they become better when the whole team can estimate? (like the ‘original’ idea of the planning game?)

  2. April 15th, 2014 at 18:34 | #2

    You’re assuming that estimation plays the same role in an Agile process that it does in a Waterfall process. That is completely wrong. The four points you note as consequences are waterfall artifacts. None of them occur in a true agile environment. If you are experiencing them – which I assume you are, from the tone of your post (:-) – it’s your *process* that is the culprit, not estimation

  3. antych
    April 16th, 2014 at 11:55 | #3

    Estimates work perfectly fine if you do them right. Take Scrum for example, you don’t estimate time, you estimate relative size/effort. You use it to track progress so you can project outcome. You use planning poker, you average them over time and they become very reliable indicator, essential in planning your project. There’s nothing that can go wrong here.
    If, on the other hand, you estimate time when a single task will be done, then as you have learnt, you’re asking for trouble, and yes, this will never work very well.

  4. TweeZz
    April 17th, 2014 at 08:24 | #4

    Hi,

    I also don’t fully agree and do think that at least trying to make honest / realistic estimates is a must. I’m sure this allows a team to make better planning then when it would make planning without any estimates.

    The part where I mainly feel your pain is where the management asks you to reduce your (honest / realistic) estimates and makes (‘big’ / longer term) planning based on the numbers management agreed on with the customer (before actually any estimate was made).

    We’re about to go live with a project we’ve been working on for 1,5 years. About 3-4 people fulltime.
    My original estimate to make a base framework for what we needed was +6 months. Implementing ‘the rest’ another good 6 months.

    In september 2012, we were given 3 months for the whole thing. That is also what was promised to the customer.

    How did reality turn out? Like the original estimate..

    I’m happy I’m not a customer of the company where I work.

  1. No trackbacks yet.