Keeping Project Scope Creep under Control

What issue consistently appears in the top ten causes of project failure, and what is the easiest and arguably most effective measure a Project Manager can take to virtually eliminate that issue?

The answers are “Scope Creep”, and “Change Management”, respectively.

Without a solid definition of scope, scope creep is almost inevitable, and implementing change management is like trying to swim up the Colorado River in full flood!! However, if the PM and their team do a good job of identifying and documenting scope requirements, then scope creep can be virtually eliminated by a good change management plan and unyielding execution.

So, assuming the project manager and team have started scope definition with a deliverables-based Work Breakdown Structure (WBS) and have then broken these deliverables down into activity definition, they will end up with a list of activities required to complete those deliverables. Great start! However, we all know that before the ink is dry on the scope definition, some kind soul will usually want to change it. Does this cause disruption to the project manager’s karma? Not if there is a good change management plan in place that has been communicated to all stakeholders and is being enthusiastically followed. Change is good and healthy for a project provided:

• The entry point for change is the PM (without exception)
• The change required has been well defined
• All ripple or knock-on effects within and outside the project have been evaluated
• All impacts on time, cost, functionality, risk, and quality have been assessed and documented on the change impact analysis
• The customer (or entity paying for the project) approves and authorizes the change

If any one of the above does not happen, your project is in serious jeopardy. Let us look at each element in turn.

The change request is given to the PM

Without exception, the change request’s path to glorious implementation starts with the PM who first receives it, logs it, then allocates it to a team member best suited to assess and evaluate that request.

It is well defined

A change is like any element of scope definition, if it is not well defined, neither the PM, the team, nor the customer can be clear or unified on what needs to be delivered, a grand opportunity for different interpretations by all concerned.

All ripple or knock-on effects have been evaluated

Once the change is received, the position of the affected deliverable on the WBS can be determined, and potential impacts on other areas can be assessed. Following this first assessment, a qualified team member can evaluate what other areas of the project may be affected. For example, lengthening an address line field from 25 to 35 characters on an input screen and database record may have impacts on many other areas such as invoice printing, search engines, etc.

All effects on time, cost, functionality, risk, and quality have been assessed and documented on the change impact analysis

This is the crux of the impact analysis and is what the customer needs to understand before they authorize or reject the change. This may not only affect the baselines for scope, time, and/or cost, but other areas such as risk. The customer should also be able to assess the business case for the potential effects of implementing the change before authorizing.

The customer (or entity paying for the project) approves and authorizes the change

If the customer does not approve the change, the decision is logged and the change request filed with no further action by the PM or team. If the customer does approve the request, this formally recognizes that they accept all the implications and impacts of that change, particularly to the triple constraint baselines. This will be logged by the PM, who will provide authorization to the team to implement the change.

Summary

Once a change management process is defined and communicated, the next task is for the PM to review it thoroughly at the kick-off meeting so that the team is in no doubt of the process to follow if anyone asks them to implement a change, or if they want to propose a change themselves. It should be heavily stressed that no change at all will be implemented without approval by the PM. It is also advisable, for the PM’s longevity in the job, to emphasize that not adhering to this process would be a career limiting event!!

Why is this easy to implement? Because it just needs one standard process, communication of that process to all stakeholders, and strict adherence to the process during execution.

What if there is no impact to time or cost baselines, do we still need to go through the process? Absolutely yes! Suppose a minor screen change is requested that will re-arrange the appearance of fields on the screen and maybe add a new easily accessible field. None of this will take additional time or money to implement because it was requested before there has been any work done on that deliverable. But when it comes to acceptance, the acceptor will look at the specification, then look at what is delivered, and say, “This is not what I asked for!” and will fail acceptance because the specified deliverable and the actual deliverable are not identical. However, if there is a formally authorized change request to explain the difference, the acceptor will say, “Hey! This is awesome!” and will place a tick in the right box.

One common issue with this process is that the optimum resource to assess a change request is often working on a critical path activity, and time taken for evaluation may affect the timeline of the project. This has many project dependent solutions which could be the source of a further paper!

The moral is to identify, communicate, emphasize, and strictly adhere to a change management process – it could save the project, and with it, the PM’s career aspirations (but only where there has been a good initial scope definition).

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.

Copyright © Global Knowledge Training LLC. All rights reserved.

 

---

Bruce Beer, PMP, is a certified project manager with over 35 years in the IT industry and over 25 years of project management experience in Europe and North America . He established his own consultancy company (Apollo Project Management Consulting) and specializes in PM training, project recovery, and PM support. He is a project management instructor with Global Knowledge and is also a course developer. He works mainly in North America, but also in other countries, with extensive experience in Europe.