Software projects, no matter how carefully conceptualized, almost always encounter a number of changes, modifications, enhancements, and even fixes that make it difficult to accurately predict budget and commercial viability. The cause of this unpredictability is usually related to failure in one of three areas: setting expectations, drawing up thorough plans, and properly managing the project. Unlike commodities like a gallon of gas or milk, the ending cost of a software development project is often based on a conceptual understanding of the goal, not a step-by-step plan with strict mutual commitment and even stricter execution. And when this understanding is out of alignment between client and vendor, that’s when we start to see scope creep. This refers to uncontrolled expansion of the scope of work through the addition of new, non-forecasted features or complications. It may seem like you need to accomplish "just a few more items to get there," but the finish line keeps getting farther away as new items arise once the previous ones are finished, and suddenly the budget, timeline, and workflow are out of control. While scope change — planned for, agreed upon, and managed carefully by both parties — is completely normal, scope creep can cause significant problems for both businesses and their development partners.
So, how do we prevent scope creep? Best practices change slightly depending on the development model — waterfall or agile — but the principles are the same. While almost all software projects undergo numerous changes along the way, those changes can be managed and scope creep can be avoided if the stakeholders follow the framework as defined below.
First, Focus
While the main idea of any project may be about what to do, it’s equally important — and sometimes more so — to be clear on what not to do to avoid losing sight of the goal, as Steve Jobs reminds us:
"People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying ‘no’ to 1,000 things."
Steve Jobs, as quoted in Forbes by Carmine Gallo
The same article recounts an instance in which Nike CEO Mark Parker asked Steve Jobs for advice. "Well, just one thing," said Jobs. "Nike makes some of the best products in the world. Products that you lust after. But you also make a lot of crap. Just get rid of the crappy stuff and focus on the good stuff." Parker realized Jobs was absolutely right — Nike needed to edit.
And Jobs put his money where his mouth was. We all remember that the first iPhone did not have MMS capability when it was released. But it did offer a revolutionary Internet browser, which changed mobile browsing completely. What if Apple had tried to implement every feature and functionality right away, saying yes to every good idea? We might have had MMS right away, but would it have been good? Would we have sacrificed the outstanding browser? Without laser focus, Apple might have missed out on setting the new standard for smartphones that changed digital industry.
Plan Accordingly
How do you know what to do and what not to do? It comes down to the proper planning, which consists of creating clear milestones based on project requirements, an overall work estimate, and general activities like quality assurance, business analysis, technical reviews, and user acceptance testing that should accompany every software project. For more on creating these milestones, we invite you to read our recent blog post on the Discovery Phase of software development.
Planning usually includes three essential components: time, money and quality. For the purposes of this article, we assume that the quality is not an issue — scope creep is about expanding, not fixing work. Therefore, time and money are the components that can be regulated, but they can’t both be fixed — there must be room for change and flexibility. Given that a software development project has commercial applicability, time is always the most important component. So, to fit into a deadline, the parties should be in mutual understanding that, since the timeline is fixed and the size of the team remains the same, the scope must be finite.
Ideally, the vendor and client can work together to define most of the scope of work before starting actual development. Then, when a project manager and product owner work together keeping the timeline in mind, they can identify what does and does not need to happen in order to release application components by their specific deadlines, which may mean implementing some changes and dropping others to stay within reasonable set of functionalities. (SCRUM-based, or agile models may require planning and adjusting on the go, but that doesn’t mean chaos. Even using SCRUM, you should be able to define what is and is not important, honor the scope within each sprint, and always keep the main goals and the release date at the forefront.)
This translates into making investments (in terms of the time and money) into the planning phase. After all, to paraphrase Seneca, "If one doesn’t know where to sail, there is no favorable wind."
Work Together
Planning does not do any good on its own, especially if the plans are being altered and generally ignored. We have seen perfect plans give way to completely different realities too many times, when clients and developers weren’t committed to them. Therefore, sticking to the plan is crucial for both parties, and that commitment can be reached only via mutual trust and openness during discussions, basing business decisions on the right information and ensuring all stakeholders have the same perspective and vision. This is proper project management, conducted by both the product owner (from the client’s side) and the project manager (from the vendor’s side). When this relationship is open, trust-based, and strong, then changes can be managed effectively without edging into scope creep. The project manager should find the balance between implementing changes that are really necessary for the project and advising the client to stay the course when changes would be distracting, costly, and/or ineffective.
The software development team cannot design and develop the project on its own and expect to avoid scope creep, as the vendor cannot decide what’s important and what’s not without input from the product owner, whose primary responsibility to understand the baseline of features necessary to solve the business problem the software is designed to address. Instead, proper planning and management should be based on mutual trust between a vendor and a customer, which means they both should be in sync on the project’s vision and open enough to accept each other’s opinions and expertise. After all, the product owner knows the business applicability of the product and its features, while the project manager understands the technical aspects including the team’s velocity and the complexity of each feature and has experience implementing similar features and integrations. When both parties are committed to proper planning and collaborative management, even though there may be changes along the way, scope creep will no longer be an issue.
