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:
- Requester asks, “How long do you think that will take?”
- The expert pauses, silent, eyes looking up. You can see the wheels spinning.
- After a few moments, the expert responds: “It depends.”
- 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:
- 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).
- The requester and estimator are tackling something novel that the organization or the rest of the world hasn’t done or encountered.
- The estimator has no idea how long things have taken in the past.
- 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:
- Teams fail to know the unknowns fast enough.
- Intellectual skills of the designers (technical and functional) are not matched to the demands of the project.
- 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.