Project planning

The pros and cons of changing the scope of a project?

ebook-template-lp-image-2

One of the key objectives during the planning phase of all projects is to determine the scope. This entails reaching an agreement on what will be delivered as part of the project and what will be excluded. However, many project managers find themselves faced with change requests throughout the project long after the scope has been signed off by all parties.

There are two schools of thought when it comes to changes on projects. Some project managers are strict in their approach to change; they will not approve any changes once the scope has been formally signed off. Other project managers believe change is an inevitable part of a project and they factor it in to their planning of the project. Which approach is right?

This article looks at the pros and cons of each approach and asks the following question: can a project truly be successful if the scope is changed?

Strictly no project changes - the pros

It keeps the plan on track

Avoiding changes once a project scope has been signed off is popular with many project managers. One of the main reasons it is popular is simply because it allows the project manager to control the project plan and prevent it going off-course.

It reduces risk

Anytime change is introduced to a project, it introduces an element of risk. Avoiding changes is one of the most straightforward ways to manage risk on a project.

Strictly no project changes - the cons

It can be too rigid

The reality of business is that flexibility is required. Businesses are exposed to outside influences and fierce competition. They must adapt to meet the changing demands of their customers. By refusing to approve changes to a project, you could be putting your organization at a disadvantage.

You might push the project in the wrong direction

No project manager can predict the future. What seems right at the start of the project may not necessarily still be the case several months down the line. If you won’t entertain the idea of accepting change on a project, you may simply take the project in the wrong direction and ultimately end up with a project that fails.

Allowing changes on a project – the pros

It ensures the project can flex with the times

Allowing changes to be introduced to a project means that it can adapt to the changes required by a business or a customer. There may be a subset of the requirements that are mistakenly missed out during the planning phase, or a requirement that only becomes apparent after work has started on the project. The requirement could be fundamental to the project and by embracing change on a project it ensures your end result is as good as it can be.

It is a customer-focused approach

Customers want flexibility from their suppliers. This is true even if you are dealing with an internal customer for your organization. By accepting change as an inevitable part of a project you demonstrate to a customer that you are responsive and accommodating.

Changes are allowed – the cons

It is costly

Change can be expensive for a project. If a project has a fixed budget, any change is going to require additional funding otherwise the project will risk operating at a loss. Changes to the requirements of a project once work has started can also mean that some of the existing work has to be scrapped. Again, this is an added cost to a project that could have been avoided if the requirement had been identified at the very start.

It stops the end user or customer from making a firm decision

There is a reasonable argument to suggest that if you allow a customer (or the end user of the product) to make changes once the scope has been signed off, then they may place less emphasis on taking the time up front to fully identify the requirements. In an ideal world, a project would be launched with a detailed and well thought-through set of requirements. Allowing a project to accept changes may cause this to be compromised.

So which approach is right: can you really change the scope of the project?

There are solid arguments from both sides when it comes to project changes. Most organizations will want projects to be nimble, competitive and flexible, but they will also want them to operate lean, within budget and on time. So can change be accommodated? The answer is yes. However, it does depend on the individual project and there are a number of questions you should ask yourself first:

  • Does the project have a fixed budget? If so, is the budget very limited? If the answer to both questions is yes, then change may not be a sensible approach to consider. If there is limited or no opportunity for extra funding to pay for changes, it is best to avoid them altogether. If the budget is fixed but there is the potential for additional funding in exceptional circumstances, small changes to a project may be considered.
  • Does the project have clear requirements? If the answer is no, then accepting change is not the best approach. The project is already under threat through a lack of concrete details, and this needs to be addressed first rather than relying on changes further along in the project.
  • Is the project strategically important for a business? Perhaps the project is for a new customer, or perhaps it is designed to win further work from a customer. A project may even have objectives to launch a product ahead of a competitor. If it is strategically important, then flexibility is essential. In these cases, accepting changes throughout the project is a sensible approach. However, unless the budget is generous you may need to accept the possibility of the project operating at a financial loss.

Summary

Every project is different and a project manager must rely on their own experience and expertise to make a judgment call. Changes are not necessarily damaging to a project but they can place it at risk. They need to be considered on a case by case basis and be given a thorough assessment before a decision is made about whether or not to approve them. However, changes should never be a substitute for proper requirements at the start; detailed requirements are the cornerstone of a good project.