The Scope Delusion

Is your project at risk?

Just 16.2% of software projects are completed on time — which means that more than 80% of projects are over budget or late.

That’s a big number — why do so many projects deliver late or over budget?

In most cases, it’s an inadequate scope. Researchers have found that 50% of project defects and 80% of rework is caused by errors at the earliest stages of the project when the scope and requirements are being decided.

The Scope Delusion

Many people think that a project’s scope is simply a list of features you want to build, which we call the Scope Delusion. Projects planned under this assumption are highly likely to fail, because the features you want to build do not exist in isolation, but depend on other factors.

Project scope is a function of three different variables:

  • Time,
  • Resources — both financial and human, and
  • Features.

The relationship between these three parts of the scope is very important; the features you can achieve are completely dependant on the resources and time available to you and your team.

Essentially, your scope must balance the following equation:

Features = Time × Resources

Clearly, when you reduce the amount of time available, the amount of resources you need to achieve the same result goes up. The reverse is true, if you have fewer resources, you’ll need more time.

Unfortunately, most projects don’t take this relationship into account. We see many scopes that fail to balance this simple equation, aiming for a completely unrealistic set of features given the amount of time and resources available.

These projects are destined to go over time, over budget, or both, no matter how hard the team works. If you refuse to prioritise or cut features, you will need to increase the time or resources you’ve dedicated to a project instead.

Scope Creep — or Feature Creep?

Another serious problem for software projects is the so-called scope creep, which in most cases actually refers to feature creep. This is when additional features are demanded with the expectation that the time and resources available will stay the same. The only way to achieve this is for one or both of the following to happen:

  • Overwork employees — Asking team members to work more than their full-time hours to achieve a project is not a long-term solution. They will experience burnout, make more mistakes, and start to consider whether a better job lies elsewhere.
  • Cut corners — Skipping testing or quality assurance can help get a project done quickly, but it’s not worth it. Problems at launch will adversely affect your reputation and cost more to correct that it would to avoid them.

Increasing or changing the scope is not the problem — as long as your time and resource allocation is flexible enough to cope, but this is rarely the case.

Time is Your Most Powerful Resource

In most cases, increasing the time available to a project is far more effective than increasing the resources. This is because your resources have diminishing returns: the more your resources increase, the greater the management overhead.

Understanding the diminishing returns of your labour is vitally important for getting your scope right. Just because you have double the resources of your last project doesn’t mean you can have double the features.

The Mythical Man Month — or Why Throwing Resources at a Late Project Can Make Things Worse

In his well-known book The Mythical Man-Month: Essays on Software Engineering, Frederick Brooks introduces what has become known as Brooks’ law.

This law simply states that adding extra manpower into a late software project will have the counterintuitive effect of making it even later.

Many businesses try adding in more software engineers to late projects because they believe the myth of the man-month, that it is useful to measure work based on the number of man-months, days, or hours available.

Using this thinking, a business might believe that if a project has 10 man-months of work left to do, but the deadline is in 5 months, the business can simply double the size of the team for the remainder of the project. This is not correct.

Complex programming relies on communication and teamwork, and the interrelationships built within the team are vital to its success. When you introduce new workers into an existing team, they must learn about the project and work out how they fit within the team. The increase in co-ordination overhead that results decreases the effectiveness of the team, pushing the project further overdue.

Avoiding the Scope Delusion

Getting your scope right is a key determinant of the success of your project. To achieve this your team needs to do the following:

  • Don’t underestimate the time and effort it takes to create an effective scope.
  • Engage with stakeholders to ensure that features are correct at the start, limiting the possibility of feature creep.
  • Prioritise features and create a realistic plan for what can be achieved with the time and resources available.
  • Understand that time is your most valuable resource, and that increasing resources (particularly adding team members part way through a project) is less effective than pushing back the deadline.

Can We Help?

The Web Artisans team can help you achieve a successful software project. We understand how to create a realistic scope and ensure your project is completed to specification and on time.

Contact our team today to set up a free consultation