Software projects are  packed chock-full of Risk. It’s important to acknowledge the risks and to mitigate them. How you address the risks depends on which type of “project process” you are following. The two types of project processes that I have experienced are Agile-type and Waterfall-type projects. In this post I list some of the common ways to mitigate well-known risks for both these project types.

When given a choice we prefer to adopt an Agile approach. We believe that following an Agile approach leads to a far superior final product. We also believe that Agile is much less risky. So this post is unashamedly biased in favor of Agile.

First, a brief description of the two types of projects:



Waterfall-type project:

A waterfall project typically has a set deadline for set functionality.  Many businesses like this type of project because it seems predictable and makes it easy to get a budget approved for the project.

Process: Plan, Build, Test, Done.

Problems:

• Trying to predict accurately while software development is very unpredictable.
• User Requirements Specifications are usually insufficient and open to interpretation, which leads to errors.
• Scope Creep is time-consuming to manage and often “sneaks” in due to unclear specifications. This puts pressure on the development team to deliver more functionality in the same amount of time.

Agile-type project:

An agile project is typically seen as a recurring monthly expense instead of a big capital expense. Features are delivered frequently  (typically every two weeks) and the project carries on for as long as it is delivering useful functionality.

Process: Plan, Build, Test, *Repeat Repeat Repeat

Problems:

• Unable to promise specific features at a specific deadline far in the future.
• Difficult to work with businesses with a “waterfall” mindset (most big old businesses).
• Difficult to get project approval when hard-and-fast promises can’t be made.

Advantages:

• Deliver what’s useful, not “what the spec said”.
• Deliver useful features early.
• Detect problems early.
• Embraces change.

Why Projects Fail

Projects can be considered failures for many reasons. The most common reasons that I have observed are:

1. Budget Overruns and Late Delivery – these two usually go hand-in-hand.
2. Incorrect Functionality delivered – the client expected one thing and the programmers built something else.
3. Technical Problems – for example: the system is too slow to use, or it doesn’t integrate with another critical system in the software ecosystem.

Below is a list of ways to combat these three problems in either a Waterfall or Agile project.

Problem 1: Budget Overrun/ Late Delivery

Waterfall:

• Add extra time to mitigate risk. For example: estimate 13 hours for a 10 hour task. Not optimal. Expensive.

• Track progress against milestones to ensure the project is progressing on schedule. (The problem with milestones is that they can give a false sense of security. When you think something is “Done” it might not really be. “It’s done! (except for the styling, or integration with external system X)”)
• Work overtime if needed to catch-up.

Agile:

• Frequent delivery means most important features get delivered early.

• If less important features are late it is not such a big deal. The system is constantly improving and maturing.

Problem 2: Technical Problems

Waterfall:

• Do lots of prototyping in the first stage of the project to try and spot technical challenges.

• If caught late it may be too late to do anything about it. Major losses.

Agile:

• Will be picked up early due to continuous early delivery. Project can then go a different direction, or cancel project if absolutely necessary (at least it will be early).

Problem 3: Wrong Functionality (incorrect assumptions)

Waterfall:

• Write very detailed user requirements specification. (The problem with User Requirements is that they give a false sense of security. Now matter how explicitly they are written, they are still open to individual interpretation and interpretation may not be what the author intended.)
• If caught late it may be too late to do anything about it. Major losses.

Agile:

• Agile embraces change. Frequent delivery ensures that the correct functionality is delivered and any “mistakes” are detected early. The client is continually evaluating the system and can change direction as required.