In an ideal world, once an application’s scope and requirements have been defined, and you have moved into wireframing, prototyping and building, no changes will be made to the requirements or scope.
Notice that we said ideal. In reality, this rarely, if ever, is the case.
The fact is, some amount of scope change is going to creep into every application project. It’s simply the nature of the beast. Your job as application owner is to understand what drives scope change so you can do your best to minimize its impact on your project.
Key culprits of scope change.
The number one cause of scope change is the fact that it’s difficult for people to describe everything they want from an application when that application is just a theory. Until users can get their hands on a functioning application (or at least a prototype) they may not realize everything they need the application to do or how they want the application to do it. That’s why determining user needs — and defining the functional and design requirements that will meet those needs — is an ongoing process that may extend beyond your initial launch date. Bottom line? What users want and need from an application evolves over time. And that drives scope change.
Another reason behind scope change is poor resource planning. It’s important to not only gather your brand, content and data resources well in advance of the application building process, but to also validate the usability of those resources. If you think you have photos ready to go, then you find out during design that the images don’t meet with the design requirements, you now have a new photography component of the project to fit into the schedule and budget. Or, if your application is dependent on another system for data, and you discover during architecture that the intended integration cannot occur, your integration approach — and, therefore, the scope of the application — will change.
The snowball effect.
Scope change is such a sensitive topic because it impacts virtually every aspect of your application, ultimately costing you more time and money. Depending on when scope change occurs, it can lead to additional work or rework. For example, if the scope change is the result of new requirements, then portions of the user interface that have already been designed and approved may need to go back to the drawing board. Code may need to be rewritten to accommodate modified or new functionality. This, in turn, can impact testing and even plans for deployment and support.
Sooner is better than later.
Scope change is less disruptive the earlier in the process that it occurs. Imagine building a house. Making changes to blueprints is much simpler than making changes once the foundation is in place or the walls are up. In the same vein, requirements and scope changes that happen during wireframing and prototyping are easier, faster and less costly to deal with than scope changes that occur once design or development work has begun.
Minimizing the damage.
It’s important to go into your application project with the mindset that scope change can and will occur. However, while some change is inevitable, you can mitigate the impact by following these best practices:
- First, make sure you have a plan in place for talking to users early and often to determine their needs. Keep going back to the users to get their input and to validate their requirements, especially during the planning, wireframing and prototyping steps.
- Go through as many revisions to your requirements documents, wireframes and design concepts as needed to make sure they are as close to perfect as possible before final design and development begin. Remember, it’s more expensive and time consuming to change code than it is to make changes on paper or screen.
- Be sure to give resource planning the time and attention it deserves. Assemble your application creation team and do your resource audit early in the process to ensure that brand, graphical, content and data assets are ready to go when you need them.
It’s just human nature to want to get through planning as quickly as possible so you can get to the ‘good stuff’, or the building phase where your application starts to become something you can see and touch. But if you rush critical steps like requirements gathering and wireframing, you can count on contending with costly, time-consuming scope change down the road. Though it’s impossible to entirely eliminate scope change, it is certainly possible to keep changes to a minimum by investing time and effort in the application preparation process.