Even well-executed eCommerce implementations that are launched on time and budget fail to meet client expectations. Often times no single group (client, consultant or third party) is at fault, and the root cause can be traced back to either differences in the understanding of the body of work to be implemented or changes to that scope.
Defining scope is the most important step in the early phases of the project. We see scope as the actionable requirements that allow the platform to achieve the goals of the project. Additionally, scope is governed by budget and schedule. These three elements of a project form the “triple constraint,” which are key to a successful project. At the end of the day, implementation scope should be driven by a set of key business goals and priorities.
Scope creep isn’t synonymous with a change to requirements or even an addition to scope; scope creep is unmanaged or unaccounted for changes to scope. This is an important distinction. Often times, any changes to scope are seen by project managers and consulting teams as inherently bad, but it’s important to put scope in the context of the problem it’s trying to solve. With good change control processes (that we’ll explore in more detail below), it is possible for scope to change and for the project to be successful with minimal scope creep.
In the rest of this article, we’ll explore why scope creep happens, what its impacts are, and what you can do to stop it from happening.
Why Does Scope Creep Happen?
Scope creep is usually not a malicious introduction of scope to a project. It generally stems from a misunderstanding of a process or phase, project management oversight, differing interpretations of business goals and requirements, as well as poorly designed acceptance criteria. There are a number of pitfalls that lead to scope creep:
Unguided Requirements Gathering: The term “requirements gathering” doesn’t really encapsulate the entirety of the process. While part of the process does include understanding the business’ overall desires, it is important to understand the problems that the business is trying to solve through their requirements. Based on this understanding, we can tactically form the scope around the problems, using past experience to inform future decisions rather than documenting a wishlist of functionality that may lack cohesion and opens the door to scope creep. Using a collaborative approach to requirements gathering, we avoid many of the challenges associated with misaligned expectations and misunderstanding of requirements.
Unsolicited requirements from outside parties: Scope is often added by outside parties who were not initially identified as key business stakeholders. When there is not a well-defined criteria for who is involved in the project and who isn’t, it is easy for unsolicited feedback and opinions to find their way into the scope, inflating the original size of the project.
Internal scope creep: Sometimes internal implementation teams hinder their own progress incidentally, stemming from poor communication between groups. Without collaboration among groups over the course of the project, and clear lines of communication between groups, scope can be added (and subtracted) internally. There should also be clear lines of communication through the groups and back up to the client, to avoid scope being added by requests not going through the appropriate parties.
Gold Plating: There’s also a type of internal scope creep known as “gold plating” by project teams who strive for perfection at the risk of creating and developing unscoped features. This is often caused by a project team not fully understanding all the constraints that govern a project. While this type of freelancing is driven by a desire to exceed expectations and is well-intentioned, it is a type of scope creep and causes the associated delays and complications of scope creep.
Misunderstanding of UAT: User acceptance testing (UAT) is one of the last phases during which additional scope can be introduced, and due to its proximity to launch, scope added in this phase poses a serious risk to the project. UAT scope creep is a symptom caused by some of the issues we’ve already discussed – usually it’s from people who have not been involved in the project until this point, and feel that their input hasn’t been included over the duration of the project. Additionally, there are often misunderstandings surrounding what the purpose of UAT really is. UAT is the phase during which business users have the opportunity to test the platform in the context of their day-to-day business operations. UAT is also a time for the business to assess their customers’ potential reaction to the new platform. Given the number of people with differing priorities, UAT is a phase riddled with potential roadblocks, based on how fluid scope can seem when it’s subjected to the interpretation, goals and acceptance criteria of many teams. It’s important to set expectations with all parties conducting UAT so that extraneous items are not added into scope and so that testing is executed against defined, in-scope requirements.
“Scope creep isn’t synonymous with a change to requirements or even an addition to scope; scope creep is unmanaged or unaccounted for changes to scope.”
What are the Impacts of Scope Creep?
The math behind scope creep is simple: adding scope increases the amount of work to be done which increases cost or forces other scope to be deprioritized. This, in turn, extends project timelines, requires additional staff, or decreases the quality of the finished product. Let’s take a look:
Resource constraints: As scope balloons, the first reaction is to throw additional resources at the project, which can cause severe resource constraints, impacting other projects and organizations across the business. As the number of resources increases, so does overhead, and productivity is decreased as a result. There are some cases, however, where additional resources can be added to a project successfully, depending on ramp-up time and divisibility of work.
Turnover: The next downstream impact are the burnout and turnover created by quickly devolving projects. There is a well-documented cost associated with turnover that can be traced back directly to high-turnover projects. Depending on the timing, this cost may not be entirely transparent in a project budget, but it comes as a direct result.
PR Implications: And finally comes the fallout from a failed project. Scope creep can lead to PR nightmares for consulting organizations, resulting in failed client relationships, and poor customer satisfaction for businesses. Souring client relationships and low customer satisfaction can impact future business as news of the issues spread.
Beyond the fallout from delayed projects and lost profit margin, projects with runaway scope often do not address the core problem from the inception of the project. These projects lack a sense of cohesiveness, and the investment into the platform is no longer justified due to the convoluted scope.
What Can Be Done to Manage or Stop Scope Creep?
While scope change is a reality of eCommerce implementations, scope creep does not have to be. With strong, but simple, processes in place, scope creep can be managed and stopped in its tracks and even turned into a business opportunity. This starts at the inception of the project, before any code has been written or requirements have been defined. A great way to stop scope creep before it starts is with a project charter. The charter outlines the project goals, defines the roles and responsibilities of all parties, determines the acceptance criteria and approval process(es) and details the Change Request (CR) process. This document should be approved and signed off on before the project begins, and serves as a point of reference throughout the project.
Despite differences in methodologies, and organizational preference for certain methodologies over others, a commonality across the board is that early diligence pays off down the road. This doesn’t preclude a project from using certain methodologies, only that if you have a solid foundation upon which to build, then the development, testing and launch of the project will proceed (relatively) painlessly. Projects get into trouble when they start off on the wrong foot – either in the sales cycle, or during the early definition and design phases. As such it is important that consultants utilize their deep expertise to gather requirements by holistically evaluating relevant components of the client’s business and client’s view their consultants as truly trusted partners from the inception of the project.
The expectation that scope is rigidly defined and impossible to change without “scope creep” is unreasonable. Scope is dynamic, but changes need to be managed using processes and controls. A backlog should be used to put focus on what is critical for launch and what isn’t. This backlog should be periodically sized, groomed and prioritized, however this is the topic of a future analysis on project methodology. If the development team has capacity and certain items can be completed in a responsible way before launch, then they can do so, however backlog items are typically reserved for post-launch.
“My scope has already crept! What do I do now?” This is a situation that, despite your best efforts, may happen for a variety of reasons. The first thing to do is to manage expectations across parties. Failing to manage expectations will exacerbate issues down the road when the stakes are higher. The expectations should cover impact to budget, timeline and staffing concerns at a minimum. These changes need to be clearly communicated, and documented using the established change control process.
We hope this has been an informative overview on something that has the ability to affect all projects. If you have any questions or comments, or want to share your own experiences with scope creep, comment below!