“A project is… temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And it must be used to create a unique product, service or result”. – PMI
As we know, project scope is the specific goals, deliverables, tasks, costs and deadlines of a project and is normally captured in a scope document during the planning phase and then agreed upon by all project stakeholders.
Once it has been agreed upon, there is obviously no reason for it to change, right?
The reality is that most projects suffer what we call “Scope Creep”, where a project’s requirements increase during the course of the delivery. For example, a simple deliverable becomes complex, a single function evolves into five new functions, a product that had four critical features now has ten – there are many examples of Scope Creep that we would all be familiar with.
Scope Creep can often sneak up on the unaware Project Manager and it usually results from:
- Poor Requirements Analysis: customers don’t always know what they want up-front and can only provide a rough idea. This is also known as the “I’ll know it when I see it” syndrome.
- Not Involving Users Early Enough: with the project team thinking they know what the users want or need when in fact they don’t. Users need to be involved in both the requirements analysis and design phases.
- Underestimating Project Complexity: especially when a project is new in an industry and has never been done before, nobody knows what to expect, there are no lessons learned and possibly no one to ask. In these cases, the complexity of the project is often understated.
- Gold Plating: when the project team adds additional features and functionality that are not part of original requirements in an attempt to please the customer. These changes inevitably increase both time and budget and yet are not guaranteed to increase customer satisfaction.
- “Value for Free” mindset: where the customer expects to receive more functions/features from the project then what they originally agreed to, but at the same cost (and time).
- Poor Communication: between all parties when establishing the original scope can lead to the customer not actually knowing what they are agreeing to.
- Weak Project Manager or Executive Sponsor: which can often lead to verbal commitments being given to users and other stakeholders that the project will deliver something that was not originally committed.
- Changing Business Needs: midway through a project, the needs of customers change, prompting a reassessment of the project requirements.
The reality is that requirements can and will change (on most projects) and as a result, the scope of your project will change.
As a Project Manager, there is little we can do to stop requirements changing, and not much we can do to stop Scope Creep. We have been taught that Scope Creep is a bad thing, and that we should try and minimise changes but the truth is that if the purpose of our project is to create something new or different for the business, it might be time to unlearn this lesson, accept that there will be Scope Creep and use it to improve the chances of having a successful delivery. After all, a project that delivers something that the user doesn’t want or use, cannot really claim to be successful.
According to PMBOK, Scope Creep is “adding features and functionality without addressing the effects on the project’s constraints (time/cost/resources/quality), or without customer approval”. Therefore, it stands to reason that if you do address the effect of changes on time, cost, resources, and quality, and you get customer approval, these changes are not Scope Creep, but rather Scope Management or Scope Control.
Scope Creep is not really the problem. The problem is Project Managers who cannot work effectively with their Sponsor to negotiate trade-offs to project constraints and who do not follow good Change Management practices.
Scope Creep is a symptom of a process problem, so how do you avoid it and control and manage the scope of your project effectively:
- Be Vigilant from the Start: The Project Manager must handle all changes to scope and say yes or no to each request as soon as it is made. Start this habit at the beginning of your project and stick with it until the project is completed.
- Understand the Project’s Vision: You will have a better chance of ending well if you start well. Even before you get to project requirements, understand what your client hopes to achieve from the project. Why is it a priority? Is their plan too ambitious?
- Understand the Requirements: You need certainty and clarity around the goals and objectives of the project during the initial planning stage. You need to know what the deliverables are and what their functionality is? Don’t underestimate the project’s complexity – break the deliverables into specific tasks, identify major and minor milestones and include them on your timeline. Review your milestones when scope changes are requested – these dates help to keep your project on track.
- Include a process for Changing Scope: Define how changes will be assessed, approved and then implemented. Introduce a Change Control Board (CCB) that can evaluate the risk of implementing the change and approve or reject it. If a change is approved and it affects any of the project’s constraints, then re-baseline and send out to stakeholder for approval. And don’t forget to address how you will get additional budget for approved scope changes.
- Guard against Gold Plating: Don’t let members of the team over-deliver on the scope by adding additional functions or features.
- Compare Actual Work against Baseline: Before accepting any new change, complete a Variance Analysis and ask yourself: “If I accept this change, how different will the project be from the original plan?”
- Know when to say “NO”: There are going to be requests for scope changes that can’t be approved. Remember, not all changes are created equal. There needs to be definite benefit to the project outcomes in order to approve a change.
- When you can’t say “NO”: In the event that you cannot say no to a request for a change, here are some alternative you could use to minimise the impact to your project.
- Zero-Sum Game – If something new goes into the scope, make sure that something comes out.
- Start a Back-Log – Keep a list of prioritised features for a second project.
- Price the Scope Change – Work out how much it will cost and whether you will charge for the change (internal or external charging). This might discourage some requests.
- Stop the Project – In extreme cases it may be worth putting the project on hold so that new additional requirements can be properly scoped and integrated rather than simply added on.
Scope Creep is a risk that can be experienced in both traditional (Waterfall) and Agile projects and regardless of the project methodology used, the challenge is making sure you expect it and have planned for it.
In a Waterfall project, changes could occur throughout the life of the project, and more often than not happen during the more inconvenient project phases: i.e. later in the project rather than earlier. This means accepting a change may mean you need to go back to an earlier stage in the project and complete through several phases all over again. You may have to update the design, re-do development work, and re-start testing. This may cause the project to go over budget and deliver late and during planning you should include some time and budget contingency to allow for change.
Agile projects handle this situation differently, because the scope is re-planned at the start of each Sprint and is continuously being prioritised by the project team and the business sponsors. You only need to assess the impact of the change if it going to be included in the next iteration therefore, there it is less likely that the project will be delayed.
Remember – Change is Inevitable.
Customer’s needs change over time and delivering a project that answers their needs often means altering your scope. Scope Creep is a reality that every good project manager expects and should plan for. If you have the right Scope Management processes in place, you will be in a better position to control your project, instead of your project controlling you.