“How much longer ’til we get there?” It’s not just a question our kids ask on the way to grandma’s house. It’s one we might also ask when the software project we’re waiting for doesn’t show up as soon as we expected.
Sometimes there’s no excuse for project delays. We’ve heard of cases where developers (working for our competitors, of course!) didn’t even start working on a project until the deadline passed. But more often, another culprit lurks in the shadows. It’s called scope creep.
What is Scope Creep?
You’ll know you’re looking at scope creep when your software development project extends beyond the time or money you planned for.
“How did we get here?” a frustrated client might ask. “After all, we’re intelligent people who know exactly what we wanted and where we wanted to go–right?” Maybe so. But there’s a reason for the word creep in scope creep. Often, a number of incremental changes and improvements take over. These little changes add up–pushing the delivery date much farther out than anyone planned.
Why does this happen? The most typical cause has to do with the project plan.
Project Specification Makes All the Difference
I guarantee it: there will be scope creep 100% of the time when nobody documents what the final product should look like. Sometimes there’s a vast difference between what a client truly wants, versus what the developer thinks the client wants. The problem arises when nobody spells out the project requirements in black and white. Here are a few ways this will become apparent:
- Vague statements of work. Consider this requirement: “Develop a screen to track all vendor communication.” What’s wrong with it? Nothing, as long as it’s the first sentence of a lengthy paragraph describing how the screen should behave. But what if this is the entire screen definition? Do you see how much room for misunderstanding it brings? A good statement of work will go much farther. It will describe every field the form will contain. It will explain how users can access the screen. And it will spell out how every control on the screen will function. Vague statements in the project definition often result in disappointment when the project is delivered.
- Failure to document the criteria for completion. When it comes to software development, “We’ll know we’re done when everybody’s happy” just won’t cut it. Without a set of completion guidelines, programmers and users will often find themselves in an endless cycle of adding “just one more feature” or making “just one more change”.
- Forgotten project components. We also affectionately refer to this as the “Where’s the feature we never told you about?” conundrum. A good systems analyst should be able to map out the scope of software project up front. But sometimes clients fail to mention that they want to include the functionality of an entirely separate application. Only after we reach the beta testing phase do end users complain that something’s missing.
- Changing requirements mid-stream, without updating the project definition. For example, “What we said we wanted two months ago no longer applies, because we’ve started a new product line. And we don’t need the widget feature because we stopped making widgets.” Changing requirements can have a significant impact on the project scope.
Additions, changes, and enhancements can increase the cost of any project. As the size of a project grows, managers may expect software developers to do more than what they expected. When the cost or time frame increases, it can also lead to increased stress on both sides.
What can we do to prevent scope creep?
When it comes to software development, prevention is the best medicine. Authors have written numerous books on how to manage software development. Here are three of the best methods we’ve found to prevent scope creep from delaying a successful rollout:
- Start small–especially when you’re working with a new software developer. This will help to protect your investment of time and money. If the first project goes well, then later enhancements will cause less concern.
- Document expectations thoroughly. What exactly should the finished product look like? How should it work? The more documentation you can put together in the initial stages, the less likelihood of surprises and unmet expectations. Some folks think they’re too busy to take the time to do this. If that’s your situation, consider hiring a systems analyst to do the documentation for you. Failure to do so will likely result in undocumented failure.
- Expect change orders. Even the most detailed statement of work can’t predict changes in a company’s environment, such as a new service offering, mergers or changes in management. And once users start working with the new software, it’s not unusual for light bulb moments. For example, a sales manager exclaims, “Hey! If the software can automate invoicing, why can’t it help us create proposals too?” But it’s important that customers and developers agree that the enhancement is just that–an enhancement. In that case, change orders can help improve the development process. A well-written change order will also set the priority of the additional functionality. Should a new feature be included in the project before the live date, or should it be included in a future release?
Scope creep is nobody’s friend–not the clients, and not the developer. Clients will likely become frustrated by delays and cost overruns. The developer will be disappointed when his or her creation doesn’t fully meet the client’s expectations. So before you embark on your next project, consider taking the time to document your needs. Talk with your software developer about how to make sure everyone is on the same page. Agree on detailed software development plan before a single line of code is written. You’ll be pleasantly surprised with the results.