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 Read more …

My colleague, Kim Leonard, highlighted some of the first analyses of Cutter’s recent study on software estimation back in November (Software estimation “a tough beast to control“). Elli Bennatan‘s analysis is ongoing; here are some of the latest highlights:

In 2002, the most common remedy for schedule problems was overtime. Now, six years later, a Cutter Consortium survey has revealed some interesting news: when projects run into scheduling problems, the two most common remedies are extending the schedule and reducing functionality, with overtime relegated to third place, followed by adding staff. … To a large degree, the shift away from adding overtime indicates a positive change in culture. Organizational behavior is improving!”

Previous Cutter Consortium research has consistently shown the move toward more manageable agile software projects (short, evolutionary, customer-driven). Bennatan examined this phenomenon Read more …

One of the most costly results of poor estimation skills is often the complete cancellation of a project. Cutter Consortium recently examined the extent to which software organizations have abandoned or cancelled projects over the past three years due to significant budget or schedule overruns. This survey effort studied software project estimation at more than 100 software development organizations and was analyzed by Cutter Consortium Senior Consultant E.M. Bennatan.

The first area we examined was comparative performance; how are projects estimated today compared to six years ago? We defined success by the ±10% rule: success means hitting the mark within 10%.

Organizations were asked: In the past three years, what would you say is the percentage of your organization’s software projects that are developed within plus or minus 10% of the original estimated time? Reports Bennatan,

Read more …

The subtitle of Extreme Programming Explained , Kent Beck’s groundbreaking book, is “Embrace Change.” The full range of behaviors that this seemingly simple phrase can be affect are in fact very far-reaching. Part of this impact can be explained by altering the focus of the phrase to one that is a little, well, fuzzier: embrace uncertainty. In his intriguing talk on the future of agile development at the Agile 2008 conference, David Anderson commented about three outcomes: right, wrong, and uncertain. Of the three, uncertainty, is the hardest to deal with in most organizations. The comment, “I don’t know,” is often an unacceptable response, while it is often the best response.

To a manager’s question, “How much will project Zebra cost?” the answer: “Well, somewhere between $2 and $6 million,” would be Read more …