It’s already three months after the planned launch date of an online shop. The customer doesn’t blame anyone though: they really like what the initial concept eventually turned into, and are looking forward to…
Oh, wait. Did we just say eventually? But on yesterday’s meeting, the customer’s representative listened to the PM telling how the new suggestions would bloat the scope, increase the budget and postpone the delivery date, and excitedly insisted on three more months and another zillion dollar for the new shiny mobile app. The project no longer seems to be predictable, and much less manageable.
No one knows when it will be finally delivered. Scope creep celebrates its glorious victory.
Why scope creep happens
Being a complex problem, scope creep is the consequence of various decisions – and lack of decisions too. Most of them are related to the planning phase – but not all of them. So, in order to better know the enemy, let’s take a closer look at what causes scope creep.
Project scope is not defined clearly enough
Vaguely defined expected results and features of the final product open the way to feature creep – an ongoing expansion of new features added to the product. They are not necessarily critical or important; mostly they are not. Its negative influence doesn’t limit to delays in project delivery: the most adverse effect of feature creep is overcomplicated design, and excessive functionality and, consequently, a product that no one really wants to use.
Changed client’s priorities or needs
This happens often: clients change their minds, want a bit more for the same price, make project-related decisions in the middle of the project course, or look at their competitors’ products and realize they want something similar. This results in new requests to the project team, changes in requirements, and feature creep mentioned above. Again, adapting to the new requirements and delivering new features takes time – large and unpredictable amounts of it.
Poor identification of stakeholders and their needs
It’s not uncommon that stakeholders are not identified clearly at the beginning of the project and their interests are not taken into account or balanced. This is especially the case of large-scale projects like Berlin Brandenburg airport, where there are too many stakeholders and not all of them are interested in the earliest possible delivery of the project.
Poor initial analysis of what’s necessary and reasonable
What a client demands in the course of the project is not always unnecessary bells and whistles. Sometimes, analysis of a new feature request shows that the feature is critical for the end product. This could be identified before the start of the project, at the planning phase – but that’s something easier to do in hindsight than in real time.
Inability to say no
The proverbial client who is always right is another reason of scope creep. A project manager who is not able to say no to the client or lacks the authority to do so cannot prevent the project from expanding, and time, labor, and costs grow uncontrollably. Also, being not vigilant enough and allowing new features to be added to the scope leads to blurred boundaries and unclear requirements.
How to avoid scope creep
No matter how thoroughly your project is planned, scope creep is always lurking around. Not giving leeway to it is key here: careful control of project scope should start before the beginning of actual work on the project. Here’s a checklist of scope control steps that won’t allow scope creep to usurp your project.
Identify all stakeholders and understand their goals
Do it before you start working on the project: identifying visions, interests and requirements of all involved parties in advance is a necessary step of project planning phase. It reduces the risk of scope changes in the middle of your project work and helps avoid conflicts caused by unaccounted interests. Communicate more to understand everyone’s vision and expectations, and prioritize the requirements depending on their importance for the project goal.
Clearly define project scope
Another indispensable step of the planning phase that needs close attention to details. Here, it’s important not only to define what is included in the project scope, but also to list what is not included. This minimizes the risk of misunderstanding and reduces the number of new requests, suggestions, and requirements. A clear scope plan also prevents gold plating – a resource-consuming process of development of unnecessary enhancements.
Plan room for changes in advance
Sad but true: not all risks can be foreseen and prevented, and modifications are inevitable. That’s why change control and management procedures should be clearly defined and documented, and room for possible amendments needs to be provided. Make sure your change management process is focused on project goals, and carefully document steps required for making a decision on a project scope modification.
Take action as early as possible
Identify and address possible scope creep at its early stages. New suggestions from clients or sponsors, updated requirements, or feedback from the team on time estimate changes need to be heard, documented, and communicated to involved parties for consideration. The sooner you make decision on a change, the less harmful effect it will have on the project course and result.
Know when to say no
It’s tempting to implement all suggested features and functions, but it’s rarely good for project delivery time, budget, and the product itself. Saying no to unreasonably time-consuming and expensive features and parts of work is crucial for delivering a quality product on time. Make sure you have a justification for saying no: it can be too much time spent on its development and QA, bloated budget (which may include not only labor costs, but also logistical, legal etc. expenses), or overcomplicated product design.
What to do if it has already happened
How to deal with a project when you’ve already noticed that its scope is expanding? The first obvious step is slowing down or stopping the expansion. However, to make it possible, you need to reclaim control over the project scope and course. How?
Understand the importance of new requests and suggestions
New feature suggestions can be just gold plating – or totally reasonable improvements. Establish a process for considering their significance for the end result. If you figure out that they are important for the product’s functionality, comply with the requirements and need to be implemented, prepare necessary changes to the project scope.
Identify the root cause
Identifying the reason why scope creep has started helps a lot with regaining control over it. Depending on it, initial counteractions can be bridging the gaps in determining project boundaries, balancing stakeholders’ interests, re-prioritizing features, or something else that minimizes or stops the scope creep process.
Analyze the effects of scope creep
In the beginning, it’s not always clear how bloated scope will affect delivery date, project budget, and labor input. Analyze already spent time and budget, forecast future expenses, and prepare a report with exact figures of final project costs. It will help all participants of the process understand the scale of the problem and possible outcomes. this data can also be used to rebuild the process and adapt it to necessary changes.
Find the solution with the stakeholders
Prepare your suggestions on how to stop or prevent scope creep, and communicate with project stakeholders to try to find the solution that suits everyone.
Summary
In most cases, project manager is the person responsible for scope creep and the person who can prevent it. Taking necessary measures to identify its signs at the very beginning and minimizing its consequences is an important part of the project management work. Well-defined and documented processes are key here: prioritizing work, checking how new suggestions align with the project goal, and efficiently managing changes is only possible with clear procedures defined for each step of the project management process.
Top comments (2)
When I'm asked to solve a problem, the usual interaction looks like:
1) Customer: We want "X"
2) Me: "X" can mean a lot of things. Can you be more specific
3) Customer: We want "X"
4) Me: Ok. Sounds like you might mean "A, B, C" when you ask for "X". If I deliver "A, B, C", is that going to be sufficient
5) Customer: That sounds perfect
…time passes as I work to deliver "A, B, C"
6) Me: Here's the "A, B, C" we agreed to
7) Customer: That's great. It really meets what we thought we meant by "X". But, now that we have "X"/"A, B, C" we better understand that we also want "D, E, F". Can you do that?
Lather. Rinse. Repeat.
This article appears to be about taking control. But what I’d control isn’t possible?
Instead of the control of Gantt charts, I get a lot more happiness out of releasing code to the user every 2 weeks and then seeing what they thought of it. There isn’t any chance for scope creep within a 2 week period because you gotta get something out.
And once it’s out you can monitor the metrics, the App Store review, and/or speak with customers to hear if they feel more is needed. Maybe they don’t need more. If so, then you never needed the scope creep! :)