Project Estimates versus Targets

I was going to have another Blog post that talked about Agile estimating, but I think a Blog about estimates versus targets should be done first. In short, I think the confusion and mingling of the terms have led to many ‘perceived’ project failures. As usual, let’s start at the start. ūüôā


Estimate РAn opinion and educated guess as to the amount of work, people, and ultimately duration. An estimate can only considered an estimate if practitioners have created it. Ideally, an estimate is only an estimate if the project team has created it. But it the consulting world, this is sometimes impossible. The most I can hope for is that skilled and competent technical resources have created the estimate, even if they are not going to be on the project team.

Target РA opinion and uneducated guess as to the amount of work, people, and ultimately duration. A target is different from an estimate in that it is usually created by non-Practitioners. The target is usually created to put a stake in the ground to reflect an Enterprise objective or goal, Regulatory requirements or the criteria required so that a business case holds.

The Problem

The problem that I have seen over and over again in the¬†Information Technology¬†industry is the inter-mingling of¬†targets and estimates.¬†Many times¬†we¬†ourselves are¬†the problem. In¬†an effort to be non-confrontational we accept targets as now the project estimate. Subsequently, the corporation wonders why our¬†Software Development projects never meet estimates. In my experience, Software Development teams meet estimates pretty well, where we struggle is meeting targets. Is this any surprise? I’m sure if I created a target for the annual budgeting process for a large corporation I also would be way off because I can’t appreciate all the processes and factors that need to be considered. (Hey, an analogy I can use!) ūüôā

I have usually found that even if a project team acquiesces to a target provided/imposed, the project itself usually comes in at about the estimate the project team created. Typically, the project team can estimate accurately unless the project is in a totally new technology or domain.

But what If I am not given a choice?

This is a situation that probably occurs more often that not. I would estimate that most of the times project teams adopt a target as an estimate, they do so because of direction from Senior Management. So what can we do?

I would recommend the following approach:

  1. Education –¬†Start diligent¬†and professional educational communications¬†with Senior Management. Ensure they become aware of the differences between targets and estimates.
  2. Language – Use the language and terminology in all discussions and documentation. This is part of the education plan to communicate the difference between the two terms.
  3. Track both¬†– Even if the project is executing according to an imposed target, track the project actuals against both the target and estimate. Evaluate after the project is complete and build up data from multiple projects. Don’t use this data to support an¬†unprofessional ‘I told you so’ communication. This is¬†very bad form. But this data will be interesting to present in a professional way.¬†Executives¬†don’t like surprises and being called out on the carpet when their initiatives always exceed¬†the plan. Presenting these figures in a¬†professional and respectful manner may convince executives to accept estimates rather than targets. (when possible)
  4. Use estimates internally РEven if targets have been imposed on your team, I would recommend to still create estimates and then use these estimates to track progress with your team. Tracking with targets is unfair to the team. It will create an atmosphere of mistrust and unhappiness. The team will feel that they are constantly failing. The team wants to feel they are doing a good job. Tracking by estimates gives the best opportunity to do that and to measure progress.  Ideally create these estimates with Planning Poker and manage in an Agile way, but that is a topic for another Blog.

Decision Point

These are strategies to move the company and Senior Management in the right direction to have successful projects. It is not a short-term strategy will take multiple projects. If Senior Management chooses to not listen after you have been able to gather the information and present your case, every individual has to decide if the culture of the company is right for them.

But I believe that unless we go through the process to inform Senior Management, we are also part of the problem. The worst thing we can do is just to accept the targets as estimates.


My #1 Agile Failure

Some of you may have read my personal Agile Adoption Story and possibly thought that it was a good story on Agile Adoption and how Agile can sometime succeed on the first try. I know I’ve read many stories about the pain and suffering on the first Agile projects people have been on.

If you missed the Blog Post on my personal Agile Adoption story, you can find it here:

My Agile Adoption Story

So given that my first Agile project was successful? What was my #1 Agile Failure? Simply put, it was the fact that my first Agile Project was successful!


Please let me explain. We came out of that first project with a false sense of security. We thought we nailed this ‘Agile’ thing. I mean we didn’t do many of the core Agile practices and still we delivered on time, on budget, and satisfied the client. This false sense of security was at a personal, project, and perhaps even a company level. We thought that we could deliver again with different teams, different problems, and different technologies.

I often say that I would have rather failed slightly on the first project so we knew we still had a way to go. Unfortunately that didn’t happen.

Why did we succeed then?

I believed we succeeded primarily due to the expertise of the development team and the expertise of our client/Product Owner. Having these two factors can address shortcomings in many other areas.

To recap, here are the Agile Practices we did not follow:

  • Test Automation
  • Continuous Integration
  • Kan Ban
  • User Stories
  • Planning Poker
  • Pair Programming
I would not even dream of being on another project without at least 5 and possibly all 6 of these practices. We really had a project that we led in an Agile way but that did not use XP practices, Agile Requirement practices, or any Test Automation! In addition to these 6 practices, I have learned about many other Agile Practices that I also would not be without on a future project. Some of these are:
  • User Story Mapping
  • Paper Prototyping
  • User Design Studio
  • BDD
  • TDD
  • And many others
But it took me a couple of hard projects after this first successful project to teach me that the hard way. I’ll leave it up to a future post to tell the story of a couple of the hard projects. ūüôā

Stop the Madness and Frankenstein Projects

My apologies for the delay in the posting but I was under  the weather and also basking in the glow of the Packers SuperBowl victory. I know I stated that the next post would be on why the testing phase is so hard to let go of, but during a discussion with a colleague at Protegra we came up with a perfect metaphor for Waterfall or Traditional projects: A Frankenstein project. Please indulge me:

The Frankenstein Project Body Parts

The Torso: The Frankenstein¬†Torso¬†is the project structure itself. Not the business problem or the project objectives but just the¬†overall structure¬†that is required for the Traditional project to function¬†and execute. This can be thought of as the project methodology,¬†processes, and procedures. (yes the excessive meetings are part of this)¬†In general, it is this body that holds the project together for good or evil. (Author’s note: copious foreshadowing)

The Left Arm: The Left Arm is the limb closest to the heart of the project and as such is the Business users. This arm defines the business objectives, outcomes, reasons, and rationale for the project being required. Unfortunately this arm has to be connected to the project in some way. Traditional projects have chosen this stitching to be in the form of extremely detailed documentation and business user sign off. Unfortunately this arm was grown in a lab separate from the torso, so the parts don’t match 100%. This is addressed by more detailed documentation and eventually the arm is attached.

The Right Arm: The Right Arm is closely connected to the Left Arm and represents the analysis required for the project.¬†(This can be both Business and Systems Analysis)¬†This is the translation of the Business objectives, outcomes, reasons, and rational for the project into Software Development Requirements. This arm is again¬†connected to¬†the torso¬†by the Traditional Project artifact of documentation.¬†Unfortunately the Right Arm was also grown in a lab separate from the Left Arm using mainly the documents used to attach the Left Arm, so the parts don’t match 100%. (Although the Left¬†Arm and Right Arm do look somewhat similar)¬†This is addressed by more detailed documentation to address the inconsistencies¬†and eventually the Right Arm is attached.

The Left Leg: The Left Leg is the critical part of Software Development for the project. This represents the Software Development required to translate the Software Development Requirements into actual code. The code deliverable itself is what is used to connect the Left Leg to the torso. It is actually a pretty good stitching job but by this time the Left leg is not looking at all similar to the Left Arm. Oh dear.

The Right Leg: The Right Leg represents the critical part of testing on the project. Unfortunately the Right Leg can only be attached after the three other limbs are attached fully. The Right Leg is attached via the test cases that are generated from the documents that were used to attach the Left Arm and Right Arm. The stitching is looking pretty inconsistent with some areas covered quite well and others not so much. The Right Leg is really looking dissimilar to the other limbs. The other major problem is that the Right Leg is only half the length of the left leg as we ran out of material; The Schedule. I believe the project will have a limp.

The Head: The Head represents the architecture of the project. It is the Architect that is trying to put together these different parts¬†and produce something that satisfies the understanding of the desired outcome both from a functional and technical point of view. The unfortunate¬†thing is that the Head does not look at all similar to the Left Arm.¬†It is similar in functionality but not intent. Typically the brain that Igor found for the Head is from a brilliant technical person who doesn’t quite understand the business domain. Pity.

The Mad Scientist: Ah yes, the Mad scientist. By now you may have surmised this is the Project Manager. ūüôā He or She is trying to understand all the issues that come with piecing the parts together from different parties but at the end of the day there is a fixed budget and thunderstorm coming to bring the beast to life and we need to make that date. He or She feels they need to come up with the solutions and push the team forward. We don’t need collaboration and team problem solving. He or she will solve the problems and then we just¬†need more Igors!

At the end of User Acceptance Testing when the thunderstorm arrives to bring the beast to life, we really have the ultimate big bang implementation. The beast lumbers to life, crashes through the walls, and pillages the village of business users. The project did not resemble what was intended and the villagers are now rioting demanding the head of the Mad Scientist. Sequestered in his Ivory Tower away from the users, he wonders how it could have gone so very wrong. It seems the business forgot to quantify the non functional requirements.

Eventually the Mad Scientist and the Business write-up a plethora of Change Requests and a good part of them require the removal and re-attachment of the entire limbs. Some require parts of the limbs to be replaced. An elbow here, a knee there. Oh dear, the project is looking even worse than before.

Finally the tamed project lumbers out and does the base functionality that was intended in a way that is not elegant or satisfactory. But we have produced something and on the date! And the business did sign off after all!

Next Post: To build a better Monster.