Sunday, December 30, 2007

Death By Feature


The Cutter Consortium, which has been analyzing data on software projects for many years, has found that an over aggressive feature list is the second most common reason for project overruns (the first is changing requirements). At times, trying to provide too many features actually ends up providing less (or none, in the case of a failed project).

Reducing the feature list is a key step in recovering a software project that is on the road to ruin. Paring this list to an acceptable minimum is no easy task. Reducing the list too much will produce a deliverable that is completely ineffective and serves no business purpose.

In the feature list reduction process, or more simply "goal reduction", is it essential to know who in the company sets the project goals. Any changes to the project's goals will require the approval of those who originally set them.

When reducing the list of goals to those deemed "essential", there are three basic categories to keep in mind:

  • Essential: requirements without which the project will have no real value.
  • Important: requirements that significantly improve the project.
  • Would be nice: requirements that add things such as attractiveness, ease of use, bells and whistles, etc.

Remember: the longer you wait to define realistic goals, the less you can actually deliver.

Monday, December 17, 2007

Is Your Project A Budget Catastrophe?


E.M. Bennatan states that "a project is a budget catastrophe if the remaining projected cost far exceeds what the development organization is willing to pay for it". Or as it often is, what the sponsoring department or customer has allotted for the project.

Project overruns are often the result of schedule overruns, or of attempting to reduce these overruns (e.g., adding staff), so usually a schedule overrun is evaluated first.

A budget alarm is usually triggered if the expected remaining cost far exceeds its break-even value, however, many times this value is not given enough consideration up front.

Should the project be canceled if the remaining projected cost far exceeds what the development organization is willing to pay for it? Not always, since it was the projected cost that set off the alarm. Reducing the project scope may be an alternative, thus reducing the projected cost and allowing the project to continue. This is one of the key objectives in disentangling a software catastrophe.

Sunday, December 9, 2007

Being Out Of Control



Managing a software project that is out of control is a miserable experience. It seems as everyone looks at you with anger or pity.

Many times senior management does not know when a project is out of control, or why. Too often they think that it is the project manager's fault, even when it is not. A project can be out of control for many reasons: senior management, appeasing the stakeholders, no rigor to the development cycle, etc.

Determining if a project is out of control is not always easy for in-house personnel to do. Many times it is best to bring in an outsider, much like a marriage counselor, to help evaluate and pose emotionally neutral conclusions and suggestions.

Once this has been done, the project can either be sorted out and re-started with a fresh set of goals and a new focus, or it can be shut down entirely.

Having a solid set of criteria with which to evaluate an out of control project, and the right evaluator, are paramount to the success of this process.