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.
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:
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:
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.
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!