“Scope Creep is like a Vine if you don’t control it becomes unwieldy and overwhelming.
Scope Creep as a concept is not unique to software development projects but it applies to all industries and areas however it seems that there is always more leeway or more reasons to allow it within software projects. Whenever it does start happening it can easily run away from you and derail the development.
We should probably define Scope Creep before we get any further. Scope Creep or Feature Creep is the term used to explain or describe the process in which a projects Scope or Features change and increase over the duration of that project. What this means in simple terms at the start of the project you have 10 features and by the end of the project you now have 15 features. 5 of those features popped into the project due to Scope Creep or Feature Creep.
This creep can happen through Project Managers accepting every client suggestion and either adding new requirements and features or updating existing ones. Another way this happens is internally within the team with poor communication allowing for misinterpreted features being developed, this is caused by the team either assuming something or not taking the initiative to clarify and verify with the client or project manager what actually needs to be developed.
If the changes are accepted and budgets and timelines are adjusted then we have avoided the Creep and used a change management process to successfully manage the project.
With the old Waterfall methodology where everything was locked away at the start of a project and you didn’t really allow for flexibility, this was a huge issue as a little creep can have a huge impact and very quickly derail a project. This model didn’t factor in changes and reviews at frequent period so it became very difficult to manage and thus the concept of a “Change Request” was invented to manage the process by introducing a formal way to halt a project, force the customer or stakeholder to incur a fee for the inconvenience of a change and make the project start again. This process was mainly to prevent changes from happening and to “protect” the team and let them keep on working.
Projects then moved to the agile methodology and scope creep is effectively built into this model. Each sprintA software development sprint is typically used within the agile methodology and is a predefined set of work for a... should be reviewed and adjusted based on how it performs, this allows for changes to occur at certain times. Agile projects can pivot and change however it’s still a process that needs to be managed otherwise it can really take a project off course as each sprintA software development sprint is typically used within the agile methodology and is a predefined set of work for a... you spend in the wrong direction can take you very far from your original requirements and goals.
The changes need to be managed and no project is exactly 100% defined at the start of a project. Software Development is very fluid and should allow for the scope to change as long as it is managed correctly and the expectations and impact are clearly explained to the team, clients and stakeholders.
- Is everyone aware of what impact adding or changing a requirement or feature has to the timeframes?
- Will it cascade and affect other features or requirements?
- Has it introduced a new risk that wasn’t there before?
- What does this do to delivery timeframes or budgets?
Types of Scope Creep
There are many reasons that scope creep can happen:
- Lack of Clarity
- Weak Project Manager/Team lead
- Direct communication with the implementation team and client
- Teams adding “more value”
- Teams overpromising
- Lack of stakeholder involvement
- Differing stakeholder opinions
- Late feedback and testing by clients
- Poor Estimates
- Not questioning requests or changes
Lack of Clarity
When nothing is clear and defined it becomes very difficult to make the right decisions and be able to focus on the goals that will deliver the outcomes needed. If things are left open for interpretation then anything said by the stakeholders/clients can be misinterpreted by the project manager and team, they can then waste time and resources developing and working on things that are not needed and deliver no value.
How can a team or project manager focus on the correct elements and deliverables when they do not know exactly what is being asked of them? How can a team deliver or work on the correct features when they are making assumptions about what to do?
Weak Project Manager/Team lead
One of the last things you need when undertaking a development project is to work with “Yessers”. This is the team that will say Yes to anything and just do as they are told. These people do not add value or manage the project well at all. Any request or thought from the client is accepted and not challenged. Allowing anything into the pipeline, without questioning it, is a great way to achieve no value, miss deadlines and go over budget.
The team should not be trying to make the client or stakeholders happy by agreeing to everything. Their job is to please the client through service and value by ensuring they are working on tasks that deliver on the outcomes that are defined and needed.
Direct communication with the implementation team and client
Having clear defined process and communication channels are a must to ensure a project is delivered on time and budget. When these processes are not followed and you allow your development team to directly liaise with the client and take suggestions on board, the only thing you can guarantee that will happen is Scope Creep. This “appeasing” of the client by developers can happen because it’s “just a small thing” but all those small things do add up and it’s a very easy way to make a project blow up and include features, changes and tweaks that add no value, cause more bugs or are there for no real reason.
Teams adding “more value”
How can you go wrong adding “More Value” to a project? Well, it’s easy, you either do it at your own cost or you’re charging the client and adding features that were not requested, out of scope or do not add to the platform in a meaningful way. This is another case or trying to make customers happy and not following the processes that are in place to ensure that all efforts are focused on the correct outcomes. If you leave a developer on their own for too long they will start developing what they want as they think it’s useful/cool and would really help the project. This doesn’t work out too often. When you have clear outcomes and project scope defined with processes in place the manage the project you can avoid this type of scope creep.
Teams overpromising
When your team has the “Under-Promise & Over-Deliver” mindset it rarely goes right, this type of scope creep affects the client and/or team. Either the client is wasting money or the team is killing profits and reducing the hourly rate by trying to over-deliver.
Trying to keep the Clients expectations low and then deliver above and beyond with the features or deliverables is a way to blow a project out and welcome Scope Creep with open arms. Instead of trying to trick the client by under-promising, ensure that you work with them to clearly define the scope, ensure that you deliver and hit the deadlines that are set out and ensuring communication through the process will do much more than trying to deceive a client by over-delivering.
Lack of stakeholder involvement
Stakeholders who start a project and explain what they’re after then disappear for weeks or months at a time or don’t appear until it’s delivered are a recipe for failure and a huge warning sign for the success of a project. This scenario never works out and it can’t. The stakeholders and team need to work collaboratively to manage the project, outcomes and requirements to ensure that the project is delivered as expected.
This scenario only opens the doors for people to assume the outcomes, goals, what would be required or useful to implement. This is how projects can be delivered and are not what the stakeholders expected, they never made their expectations clear, they didn’t provide input and the team is at fault for just doing what they thought was best!
Differing stakeholder opinions
There are these old sayings we’ve heard a million times before:
“Too many chiefs and not enough Indians”
“Too many cooks spoil the broth”
But have you heard this one
“Too many stakeholders with different motivations, create bad products”
I know it’s not as catchy as the other two and it doesn’t roll off the tongue as easily but it’s just as important. What it means is, that when there are too many people involved things barely work out. This is true in most areas and something that has to be managed in the right way with stakeholders during a software project. Getting too many stakeholders involved with different motivations will create confusion over the outcomes, approach and requirements of a project. They will all have different reasons for wanting what they want, the software will affect each of them differently. Trying to please all of them will no doubt introduce a Scope Flood not just Scope Creep.
Late feedback and testing by clients
The feedback cycle during development is just as important as the development cycle. Unless you are constantly measuring and asses what has been done and delivered how can you ensure that you’re still travelling on the right path?
If stakeholders are absent or present for somethings but fail to provide timely feedback and testing how can they be sure the deliverables will meet their needs? How does the team know what they are developing is correct and meets the goals and outcomes? Things change in business all the time and unless the feedback is present the scope can change without being managed, the features can be built to address the wrong needs and the deliverables can miss the mark completely.
Poor Estimates
Every project we’ve ever worked on has involved the question “So how much will this cost me?” in the early days we would throw a number out in a meeting, then provide a fix price quote for an entire project. What these two scenarios involved was poorly estimating what was involved to deliver the project correctly. Poor estimated create an environment of unknown’s where the teams end up delivering more than they thought they had based on their quote.
This scope creep affects the team more than the stakeholders however it’s detrimental to both, the teams feel overworked, under-appreciated and end up killing their profits. This makes the team just want to finish the project as quickly as they can to get out of the situation and move onto the next project.
Projects are complex beasts that are ever-changing, it’s impossible to provide an accurate number of what a project costs, how can you? There are so many unknowns in this space.
If you’ve ever been on a project where deadlines were constantly missed, you had one of two things. Either the stakeholders were adding more features that just crept in or the team underestimated what was involved and those deadlines were flawed, to begin with.
Not questioning requests or changes
As a development team, it’s juggling act managing client expectations and deliver software to meet the outcomes within the budgets provided. When requests or features are asked it’s critical to question them and understand why they are being requested and what problem they are trying to solve. A lot of times the feature being requested is to solve a symptom but not the root cause of the problem. Taking every request a face value and not questioning or trying to understand what they are actually for is an awesome way to introduce more scope to a project, that sometimes, adds little value.
How to manage scope creep
There are many ways to deal with all the creeping scope and in all shapes and forms:
- Have a clearly defined scope
- Client underestimates the complexity and scope of the project
- Be clear on milestones and deliverables
- Get stakeholders involved
- Have stakeholders review and provide feedback regularly
- Have a change management process in place
- Monitor the project
- Manage client expectations and changes
- Don’t be afraid to say NO
Have a clearly defined scope
“If you fail to plan, you are planning to fail!”
The same meaning applies to not having a clearly defined scope. With a clearly defined scope, you are able to understand everything that needs to be done, when it is to be done and the outcomes that each item is addressing.
Some time needs to be spent with the client, stakeholders and the team to be able to identify all requirements and features. This is to ensure that the root problems are being solved and that all of the requirements and features collectively will create a usable system capable of meeting those outcomes. This allows your team to focus on delivering and rarely deviating from the scope unless a change process is followed. By following the scope you can prevent the unwanted scope from creeping in and derailing the project.
Client underestimates the complexity and scope of the project
Software Development is not an easy task and what looks like simple changes or simple things happening within it are rarely that. Managing Client expectations and having an understanding of a project and its complexity is a great way to manage scope creep.
There a lot of moving components and one thing can affect the other and frequently does, so having that understanding that a minor change while seeming simple, could inconceivably affect the underlying platform and introduce weeks of work.
This is why a solid base and foundation are critical to any project. This only achievable by understanding the scope and what the client wants to achieve not just with the project but where it should be in the future.
Be clear on milestones and deliverables
When there are deadlines and timeframes associated with doing something it puts focus on the tasks and what needs to be delivered upon those deadlines. Having clear and reasonable milestones puts a focus on the tasks for that milestone and will help keep the team focused and prevent them from creeping onto features that shouldn’t be worked on.
If there are no clear deadlines and milestones the teams just keep working on things and it’s easy to build in features without having a particular reason for them. The deadlines and milestones also help clients and stakeholders manage their expectation and organise themselves and organisations around deliverables and what to expect when.
Get stakeholders involved
Whether you are creating your own product as a startup, developing a tool for an organisation or trying to automate a process and workflow, you can’t do it on your own. You cannot be the only person who has created the scope and works with the team.
You need to:
- Define your problem and potential solution
- Identify your stakeholders (Who is going to be affected or using it)
- Interview or host workshops with stakeholders and discuss the solution and problem
- Evaluate and use their feedback
- Update problem and solution
Without the involvement of stakeholders, you will only be addressing the issue from one perspective and it could be skewed. You could be creating more work for people down the line by not addressing their issues or needs and worst of all create features and requirements that are useless and just waste time and money. Prevent the scope creep introduced by getting them involved late and reacting to feedback by getting them involved early and using their perspectives and ideas to help mould the product to best address the outcomes.
Have stakeholders review and provide feedback regularly
Once you get stakeholders involved at the start of the process it should not end there with them. Use them to help review and assess deliverables and milestones and provide feedback to the team. Without this, you may still go off-track and develop what is not required then struggle to reign it back it when it finally does get in their hands. Another great strategy to manage scope creep is to have a regular feedback channel with key stakeholders that will assess the deliverables of the project and adjust its scope based on their or their organisation’s needs.
Have a change management process in place
Software projects are fluid and flexible and should allow changes, planned changes. Planned Changes are the ones that follow a process are not Scope Creep. Scope Creep is what happens when there is no change process in place and new suggestions get taken on board and worked on with a solid process to follow.
An early and crude way to avoid changes in scope in early software projects that were following old methodologies was to avoid changes altogether. In these fixed scope developments an environment was created where every change in scope raised incurred a cost (to try and avoid them from being raised) this prevent the clients from trying to make changes and worked to the detriment of a project.
Using a change process allows new features or changes to be raised and then evaluated against the outcomes or changing needs of the organisation. When they align, they can then be considered and approved for development causing a change in the plan, milestones, deliverables or overall project scope. However, you have to manage this process as this cannot happen daily or weekly as that causes chaos for developers and nothing gets completed and with partial features having been developed.
Monitor the project
Good project management is key and constantly monitoring the project is crucial to its success. Without this monitoring, check-in etc you won’t where it’s at, what’s developed, how milestones are tracking and is it on time or on budget. Having a solid foundation to allow for monitoring and management allows you to keep track of tasks, features and requirement. YOu can then cater for new features or changes in requirements as they are raised. Closely monitoring these helps prevent the team from randomly working on features due to developer interest or for the sake of trying to please the client.
Manage client expectations and changes
This is always a tricky situation but managing client expectations as a team is difficult. It puts you in a position of trying to deliver a great solution and making sure your clients are happy. As a client, it’s difficult to hear no some times and expect everything. However, you need to be realistic and understand what can be achieved within a certain budget, timeframe or technology.
When a client and team work in a collaborative relationship and can manage outcomes, requirements, features and scope in an open way it becomes easy to understand and explain
Don’t be afraid to say NO
This point specifically for teams, Don’t be afraid to say No. You cannot be a “Yesser” and successfully deliver a project. Saying No doesn’t put you at odds with a client or set a negative tone for a relationship. Not every idea is great, not every feature is required, not every requirement is a requirement. By saying No and being able to question and assess issues or questions as they arise you provide yourself with the opportunity to explore why things are necessary and are they needed to actually solve the issue at hand.
Saying No the right way and having a process to handle things is a key component of managing a project and moving forward.
Scope Creep can cause so many problems within a project that there is probably an entire field of study somewhere focusing on management methodologies and processes. I’m not sure if there is but it sounds like there should be.
By understanding Scope Creep and being able to identify the point in your process where it can occur it is easy to manage. By having a solid change process in place you can then manage the scope and changes and prevent creep. We all want to deliver successful projects, we want clients to have successful products that are used and meet their outcomes. Sometimes saying No is the best thing we can do as long as we follow our process and investigate the why first, this allows us to change the scope when its required and not because it’s suggested.
