Jan 142009
 

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 for this survey and found a clear preference toward smaller projects and the estimation advantages they provide. (See Figure 2, here.)

You can read more of Elli’s analysis at the Cutter website. [Cutter clients, you’ll find even more in the Agile Resource Center.]

Discussion

  4 Responses to “Schedule Problems? Extend It.”

  1. It would be interesting to correlate this with an increasing use of agile methods. The time frame is consistent.

  2. But if you still want to meet the schedule and the scope, overtime is still the only solution. Allocating more resources (which logically comes 4th) will have a negative effect on the project.

    The problem is that almost always cost overruns and late schedules happen all of a sudden. The Project Manager can easily predict (unless it is a very short project) if the project is going to meet the deadline/budget or not. Probably most do, but they fail to admit it until the end. The solution is early and constant communication.

  3. avatar

    Jim, I agree that we should look more closely at how agile projects affect estimation. The current survey data shows that shorter projects have improved estimation (no surprise there) and the trend is positive from the 2002 survey. Now add to that customer involvement and evolutionary development and it can only get better.

    A few more stats: Back in mid-2007 we surveyed project failures and learned that 29% of companies had moved to agile as a direct result of their experience with project failures, and 38% said that failures had led them to improve their estimation skills. Any positive correlation here? Probably.

    PM Hut, I have a problem with your statement that “if you still want to meet the schedule and the scope, overtime is still the only solution.”

    Wanting to meet the schedule and scope is not always achievable (no matter how much you want it), and overtime can sometimes worsen – rather than improve – the problem by diverting your energies away from a more viable solution (painful though it may be) of less functionality or schedule extension.

    You are right, though, that adding resources can often have a negative effect on a project (Fred Brooks told us that back in 1974).

    Let me also say, PM Hut, that cost overruns and late schedules do not happen “all of a sudden”. How do project get late? Brooks replied: “one day at a time” and he was right. It is never the overruns that happen suddenly, it is the realization that happens suddenly. That is why a good status monitoring process (or an early warning system) is so important for all projects.

  4. E.M., thanks for the reply. What I meant by “happening all of a sudden” was explained in the second sentence, Project Managers withhold this knowledge until it is so obvious that there’s no way to withhold it anymore. You did mention this in your reply “it is the realization that happens suddenly”, I quite agree.

    I also agree with the status monitoring, but who do you think should be responsible managing such a process?

 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>

(required)

(required)