May 182010

Everyone knows estimating work in IT can be difficult.

Whenever you ask an IT expert for an estimate, the sequence of events can look like this:

  1. Requester asks, “How long do you think that will take?”
  2. The expert pauses, silent, eyes looking up. You can see the wheels spinning.
  3. After a few moments, the expert responds: “It depends.”
  4. The expert and the requester begin a new round of conversations, further specifying what “it” is and what “depends” means.

Estimating isn’t really estimating at all. It is a process of understanding with greater specificity, breaking the work down in greater detail and nailing down unstated or less clear choices. Once all the details are known and can be easily related in the mind of the estimator to work done in the past, the expert can give some estimates. The key challenge for estimators is that requesters often want estimates without needing to go through the extra specification. What is the right balance between accuracy of an estimate and the speed at which the estimate is delivered?

Estimators should break the estimation process down into two distinct components: nouns and verbs. The noun part is a comprehensive enough list of what is being requested. Rather than describe work broadly as high-level business requirements, it is better to describe the work as a set of tangible items with which the requester will interact. The second part of the process is to break each noun down into the actions that will be required to create the noun.

This sounds simple enough, but getting this level of decomposition appears (wrongly, IMHO) hard for many people. Some of the reasons this is difficult include the following:

  1. The mental effort it may take the requester or the estimator to decompose what is needed will require more uninterrupted time than they can afford at the moment (too many fires to fight).
  2. The requester and estimator are tackling something novel that the organization or the rest of the world hasn’t done or encountered.
  3. The estimator has no idea how long things have taken in the past.
  4. The estimator can’t elicit enough concrete information from the requestor about what is needed, or the estimator can’t understand or visualize what the requester is reasonably stating.

The first problem, I suspect, is the more prevalent. After all, most IT people are taught to dispense with what is easily done and delay the difficult until later. From a planning perspective, this is exactly backward. I have often broken larger projects down and prioritized components with the most uncertain components tackled first and the easiest pieces put off until later. With complex projects, go for the jugular. Attack the unknown first, fast and furiously. To tackle a large portfolio of projects will require estimators and requesters aggressively tackling unknowns faster than thought possible. I contend that one can address unknowns actively by researching potential problems even before a requester begins asking. The more the IT organization is on its toes anticipating unknowns and relentlessly pursuing them until they reveal their secrets, the more efficient, nimble, and streamlined the IT organization and the project management process will be.

The second problem is also easily dealt with. Every time I run across teams stuck in this mirage of a rut, I ask a simple question: “Are we the first people in the world doing this?” If so, fair enough. But 99% of the time, what a team thinks is unknown has actually been solved elsewhere in the world. What is unknown is where that knowledge resides. IT shops can leverage vendors, the Internet, and social networking to gather this “hidden” knowledge quicker than ever before.

The third problem is somewhat odd in that it is often invoked yet seldom accurate. In most organizations, someone knows fairly well how long something took in the past. The estimator needs to find out who those people are and seek them out. If the level of turnover is high, the estimator can do what I suggest is done in number two: go out and find people in the world who know. In addition, through project management and time tracking tools, this can be easily known by looking at prior projects.

The fourth problem is the second most prevalent problem and, unfortunately, this often intertwines with organizational politics. Some estimators and some requesters are very good at “kicking up dirt” while trying to get concrete on a new project. Most of the time, the players are trying to avoid accountability, have a hidden agenda, don’t really agree with the project, or are trying to maintain their power position because the project represents a political change as well. Sometimes this occurs because the intellectual skills and abilities for the estimator or the requester are not suited for this task, which can be difficult enough. The solution to this problem is to get the best and brightest minds working on the decomposition of the project and free them from any political entanglements (however that can be done).

I will suggest that most of the time a failure to estimate properly is a failure to address one or more of these three problems. I will also suggest that most projects fail for one or more of three reasons:

  1. Teams fail to know the unknowns fast enough.
  2. Intellectual skills of the designers (technical and functional) are not matched to the demands of the project.
  3. Organizational politics are not dealt with appropriately.

With attention to these three factors, good estimates ought to flow like water running downhill: easily. The difficulties in generating estimates may have less to do with the project management methodology and more with the organization’s culture and the IT leadership’s ability to match people’s skills with well-designed roles. More project management and estimating methodology will simply be a bigger bumper on a slow, gas-guzzling car.


  4 Responses to “Breaking It Down to Avoid a Breakup: Estimating vs. Decomposing”

  1. Agile people notice that people often don’t really know what they need. They specify what they want. And deployed systems can have half the content-workings unneeded. A system that quickly does and shows the client, then adjusts, can sharpen up the tuning real needs instead of wants, and discard a lot of specification waste. An agile team estimates for only some days ahead, and they still average only say 60% of full work-at-the-keyboard estimates. Bigger, longer, and farther from the keyboard estimates aren’t going to be better.

  2. avatar

    Good comment.

    FYI, I am an agilist and use agile methods frequently. Some people really do know what they need and can articulate this well. The problem is there are far too few of those people around. They tend to be A+ players in hot demand or are up and out of the organization.

    Also, most common people do not know what they need because it is too hard, cognitively, for them to think about what it is they want in a systematic and effortful way. They typically lack the problem-solving orientation or the detailed knowledge to deal with problems in the abstract. It is much easier for them to react to a concrete example that others have created.

    Agile methods cause the further decomposition of things within shorter chunks, similar to what I described in this entry. In this sense, a great estimator can do the same decomposition that an agile team does, just entirely inside their heads.

    While both techniques for chewing through what appears to be unknown are valid, they are different techniques.

    IMHO, the good designers of things do both: abstract the essentials in a thorough way at a distance and use agile-like approaches. The best designers know precisely when to use either approach.

    Also, decomposition ability (aka estimating), IMHO can be learned/developed and turned into a high skill. Just imagine an agile project with such a race of geniuses!

  3. avatar

    A further problem is the pressure that is applied to estimators to provide concrete answers.

    Decision makers want concrete answers, it makes their job easier (they think), and they have the organizational clout to lean on estimators to get this. Unfortunately, this is a recipe for problems.

    Estimators that succumb to this pressure end up, at best, misrepresenting the risks associated with their estimate. Far more common is that they focus on identifying areas of certainty and overlook areas of uncertainty.

    The first questions decision makers should ask when given an estimate are: What is the range of uncertainty in this estimate? And, on what basis has that range been determined? If they do not get satisfactory answers to these questions, especially the second one, then they should reject the estimate outright. (NB: It is particularly important to actively reject inadequate estimates, given the impact that estimates, however incorrect, have on expectations – expectations that can unduly influence decision making throughout the entire life of a project.)

    Rather than asking for concrete estimates, decision makers will get far better outcomes if they require that every estimate they receive includes a range of uncertainty as robust as the estimate itself.

  4. avatar

    The key question also to consider for estimates based on past projects is what to do when the previous projects have failed and the project investors are looks for more accountability in terms of return on their investment. It becomes a challenge for the estimator also when they know they will held accountable for an estimate they had provided(e.g. with a confidence level of 70%).

    The key question in estimating is how an estimate is interpreted. If its going to be taken as an estimate with 100% confidence or 30% confidence. If that confidence is established within the interaction then this discussion can be very contstructive. Otherwise it will cause a lot of burn outs and impacts to the overall effort. Its usually easy to say to qualify an estimate with a confidence level, but in reality the confidence level estimates are mostly ignored by the people using the estimates for planning/execution purposes.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>