For training call +44(0)1273 6222 72

Your basket is empty View Cart shopping cart

theBLOG

Managing Scope Creep on Projects

/ home / blog /Managing Scope Creep on Projects

Written by by Claudine – Tue 06 Nov 2012

Scope creep is a project manager's nightmare, which makes it an important part of our Introduction to Project Management course. In this post, our PRINCE2 and project management trainer Claudine gives a brief oversight of scope creep and how to manage it.

Firstly let’s clarify what scope is. It is the boundaries of what will be included or excluded from your project. For example:

  • Features or functionality of a product
  • Information or data included or excluded
  • Organisations or stakeholders
  • Procedures or processes

Managing scope creep is easier when using an established project management methodology like PRINCE2, which goes some way to explain why PRINCE2 Practitioner training is one of our most popular courses!

Why is it important to define scope?

One of the biggest gripes project managers have is of the “moving goal posts” or scope creep. This involves a large number of additions or changes to the requirements of a project, resulting in timescales and budgets to be exceeded. In addition, it also becomes difficult to plan and resource a project that is in a constant state of flux and transformation.

So it is important that scope is managed correctly so that the project manager is able to deliver a product within their objectives of time, cost, quality, scope, risk and benefit.

How is scope defined?

Ideally this should be done very early in a project, possibly even before the project is initiated. There are a number of ways this can be done.

  • Scoping workshops
  • Requirements gathering
  • MOSCOW analysis (Must have, Should have, Could have, Won’t have for now)

Once a list of requirements are identified, MOSCOW analysis can be applied to sort the requirements into a list of Must have’s and Should have’s. Agreement should be gained from the Project Executive or Project Board as to what will and won’t be included in the project.

Once the scope is defined, the project can be planned and costs estimated based on the scope to be included. These plans and costs will be authorised and as far as the project is now concerned, only the defined scope will be delivered by the project.

How does scope change?

On occasion there will be a request to change the scope of the project. Maybe something hasn’t worked properly and only a change will rectify the problem. Maybe the customer has decided to add in something extra or to change something that has already been defined.

As the project costs and timescales have already been agreed based in the defined requirements, consideration now needs to be given as to how to pay for the scope change.

If the customer is requesting to change something or add something extra, they should be made aware of the time and cost implications to the project and decide if they wish to proceed.

If the change is as a result of a failure which must be changed to rectify the problem, the cost and timescale to make this change must be negotiated between the Customer and the Supplier until agreed.

Fundamentally, the important thing to remember is that as a scope change is changing an existing agreed requirement, it will always require a decision by the appropriate decision makers.

How should scope changes be dealt with?

To ensure that scope changes are handled appropriately, every project should have in place a change control procedure. This would be documented in a Configuration Management strategy. An example of the steps are as follows:

  • Capture the request for change (in an Issue or change request register)
  • Examine the change – conduct and impact analysis into the effects of the change on the project
  • Propose a number of options to deal with the change and recommend an appropriate option
  • Decide on the best option – this is most likely going to be done by a Project Board or a change authority
  • Implement the change – update the relevant plans and documents and make the change

Remember, not all changes will be approved. Some may be rejected as it will be too late or too costly to make the change or possibly even the change does not add any benefit to the project.

Either way, it is essential to ensure that all changes, big and small, always receive appropriate approval before being implemented.

Images by ahisgett and Nguyen Vu Hung (vuhung) on Flickr.

Posted under:

Back
blog comments powered by Disqus