We’ve already told you about what scope creep is and how to handle it. Now it’s time for the real world examples. Once again we turned to business owners and project managers of the world, with a single request:
Would you mind telling us about your experience with scope creep, and what have you learned from it?
We’ve selected the best answers and brought them to you - just so you know you are not alone.
Anticipate scope creep - and then upsell it
Kyle White, now a chief executive at VeryConnect, had a close encounter with scope creep several times during his career. Thanks to those encounters, he determined that scope creep is best mitigated with meticulous requirements, detailed mockups and putting in the legwork even before the project starts.
Very often we highlight the concept and problem of scope creep to the client and other departments (marketing and support team) right at the start of a build. By getting it on everyone’s minds early on, without pressure then it can easily be referenced back to when things are asked. It’s worth pointing out that it’s a reciprocal thing, scope creep leads to delays even if it’s determined to be included in the budget.
Ultimately, scope creep will never be prevented. It can, however, be translated into upsales or add-ons, which can then be scoped and priced in their own right.
When resources are scarce, opt for “quick and dirty” solution
For David Attard, a product manager at Collective Ray scope creep is something he faces on a day-to-day basis. As he is (usually) a part of a startup, finite resources like time are scarce, so he sometimes opts for “faster ways to get things done”.
Every day we have situations where there are multiple ways of developing a specific feature or function. Typically, there are two ways this can be done: a quick way (which works and is fast to develop), and the ideal way (which includes all the bells and whistles but takes 3 times as much time to develop). The perfect way is the pure definition of scope creep.
In an ideal world, you go for the perfect way to do something. However, clients will often want things to move quickly - and that is when I take the quick route.
For example, we wanted to redevelop the Sign-Up process and enable login directly from the landing pages. There was the way which required redeveloping a landing page and a backend to add more fields which were necessary. Then there was the quick and dirty way which autogenerated the missing fields based on a predefined rule. Although the latter solution was non-ideal, it allowed us to release quickly, so we opted for this.
The quick and dirty way is only put in place when developer resources are scarce. Eventually, as there are more hires and a bit of more luxury, or some of the initial quick and dirty start to become problematic, these would eventually have to be redeveloped correctly.
Do not mix billing by hour and billing by deliverable
According to Robert McGuire, the founder of Nation 1099 scope creep occurs when the project implies a mix of activities which are priced differently - by deliverables and by hour. When these two modes get commingled, expectations on each side become unaligned.
The best way to prevent all this is to have a very clear scope of work document. It’s also important to outline how “delivered” will be defined. Then when a client wants you to do some additional work, you can say in a definite way if there is any room left in the deliverables budget to do that.
If there’s room, you are using the budget differently and agreeing to do less of what you originally planned. If there’s no room, then they are asking for scope creep. Lastly, make sure your scope of work has a line about how much per hour you charge for work added on to the deliverables.
The other strategy that helps a lot is to make sure your contract has terms for advance payment and regular ongoing payment. Get a deposit for the startup phase of the work, and every month send an invoice that itemizes what has been delivered so far. When you remind the client regularly what you agreed on and what they are paying you for, they will understand a change order for what it is.
Focus on mid-term priorities
Sergio Flores is currently a product owner at a Berlin-based startup called Smartfrog, but was involved with many startups in the past. On one occasion he had to tackle a severe issue of scope creep with one of the in-house projects: company executives were so excited about a project’s potential, they wanted to improve it with new features again, and again. Soon, their enthusiasm became a burden.
My approach to handling this problem was to sit down with the executive board and persuade them to continue having the same future vision of creating a breakthrough product, but also encourage them to focus on mid-term priorities.
Persuading them was not an easy task, but I was able to tackle-down the problem by comparing market performance data results from products with limited features which we used to enter new markets in the past, and those of current newer product deliveries which had lots of features. My argument was mainly around the fact that in those past products we unconsciously focused on mid-term priorities and therefore managed to find unique strategic positions (i.e.: specific features) that were already possible to develop but simply overlooked by established competitors.
It is surprising, but once the mid-term priorities were defined, an entirely new sense of purpose grew within the team. Later on during my career, I also experienced similar situations, but was able to prevent scope creep from happening by always staying true to the long-term philosophy of the product, but focusing firmly on what the medium term priorities were.
Changes make scope creep grow exponentially, not linearly
Stanley Tan, is now a digital marketing manager at Selby’s, but his first experience with scope creep came during his very first software development project. His team wanted to create a tool for SEO agencies, with a focus on reporting.
Even though the initial goal was to build a simple tool that creates reports for SEO agencies, things quickly spiraled out of control. Before I knew it, we were creating a task manager and then a template system to create tasks for repetitive projects. Then a backlinks manager came to be, and then a client dashboard. Every feature that we added resulted in more bugs, and it came to the point where every day things were breaking. Instead of building a great tool that works, we were putting out fires. Looking back, we didn’t pay down our technical debt which resulted in this. A lot of managers make the mistake of not understanding that making one change after another will cause not a linear, but exponential growth in scope creep. For example:
- Making one change might take 30 minutes.
- Make two changes will take 70 minutes, not 60 (30 minutes + 30 minutes).
- Making ten changes might take 1000 minutes, not 700 (70 minutes x 10).
The longer the project goes on for, its foundation becomes more developed. Sooner or later, one change will result in overall scope change which will affect other parts of the project.
“No scope creep for XX days”
We kept the best for last. Sherolyn Sellers, founder, and CEO of Pivotal Performance Group came to us with excellent and comprehensive insight into how she handles scope creep. We decided to share it with you in full.
When I manage projects, I spend a good amount of time at the onset asking detailed questions. I seek to truly understand the business drivers behind WHY the project is being undertaken, funded and prioritized to expend time and resources behind it. I try to understand what sponsor’s and customer’s expectations will be. After this understanding is met, I then deep dive into ensuring detailed requirements are captured, and I use the SMART model to hedge that we get a clear picture of what is being delivered.
Additionally, I endure my documentation is clear as to what IS being delivered and what IS NOT being delivered, and I get alignment from my key stakeholders, in addition to sign-off. After the sign-off, we baseline the scope and any changes whatsoever past this date must go through the change control process. .
Sherolyn states that while this method is not a 100% guarantee that the project will evade scope creep, it is a significant step towards lessening the probability that it will occur. But if it happens, there is a game plan as well - and it starts by pinpointing the breach in the process.
In technology projects, it typically comes in through development team members adding quick fixes to the code while completing a new requirement.
I first assess the culprit to understand what scope was added.
Next, I prepare an analysis of the impact that came as a result of it. However, I’m not going through the change control process.
Finally, I share the outcome with the project team and the stakeholders as part of the standing team meetings and status reporting. The goal is raising awareness about the impact and discouraging support of scope creep happening again. It tends to be pretty effective. (No, I do not call out any names. However, the guilty always know who they are).
Finally, Sherolyn shared an unconventional “anti-scope creep” method.
Once, while working with a company notorious for scope creep within their projects, the team decided to adopt a rather unconventional behavior as part of our ‘team agreement’. Just as in environments where safety is a key focus (such as manufacturing plants, for example), we placed a visual on our landing page for our project Sharepoint site with a sign stating ‘NO SCOPE CREEP FOR XX DAYS’ which mimicked the safety record signs reading ‘no accidents in XX days’. It was a lighthearted way to maintain focus on a scope creep as a continual issue in projects, while at the same time keeping track of the ones making it through the system.
Scope creep may be a nuisance, but with proper handling it doesn’t have to turn into a nightmare. We’re certain there are many other stories such as these all across the industry. So, don’t be shy about sharing some of your own experiences in the comments below.