At best, retailers usually define which stores are included, when the deployments must be completed, a very general overview of exactly what is being deployed, who will run the project, and how many technicians are needed, maybe. Later, they can’t understand why their deployment project falls flat right from the start.
Developing a well-defined scope means you are aligning expectations with actions and building controls that allow you to maintain fiscal accountability. In other words, clearly documenting everything you are going to do allows you to control costs for your project—you’ve established very clear boundaries. To do anything different only sets you up to not only fail at the deployment itself but also to overrun your budget because you didn’t clearly define the scope upfront.
The exercise of scope definition is pretty straightforward: Simply define the who, what, when, where, and how of your deployment. However, depending on the depth, breadth, and complexity of your specific deployment, this can be a daunting task. To help get you going, I’ve outlined key considerations for each of the components.
The Who
A deployment project involves a lot more than deployment technicians and a project manager. You must also consider logistics coordinators, help desk technicians, technical subject matter experts, schedulers, financial analysts, procurement and configuration specialists, store operations, executive oversight, and a change control board.
Additionally, for every resource that is required to execute the project, you must define the expectations of their role and how many of each resource you will need. You must specify whether they should be internal or external resources, permanent or contract, and full-time or part-time. These are all things that can have a significant impact on costs, so the more specificity, the better.
The What
The “What” must clearly outline what specific equipment will be installed and/or decommissioned from the store, along with how the equipment will be acquired and shipped to/from the store. If there is configuration required, this must be specifically outlined along with how long it is expected to take to complete the configuration. Be sure to state if you expect asset information to be collected and provided by procurement and/or deployment technicians.
Along with the specific equipment to be installed or decommissioned, you must be specific about how it will be installed or decommissioned. Clearly specify how long you believe the install/decommission will take to this part of the scope definition. If it’s not clearly defined, this can run into out-of-scope charges during the deployment, which can add up very quickly if not properly scoped and controlled.
The When
Make sure you clearly define the earliest date the deployment can start and the latest it can be completed. This information drives scheduling and plays a key role in defining resource requirements for the entire project.
To ensure minimal in-store interruption, clearly define when deployment technicians can complete their scope of work and the process for them to follow if they run into issues that could negatively impact the length of the deployment. Also, define blackout periods when no deployments can be going on in the store.
You’ll want to define a ramp-up and ramp-down period if this will be applicable to your project. To ensure that support resource utilization is as predictable as possible, define the minimum and maximum stores that can be deployed per day.
The Where
Be sure you include the exact store list with store numbers and full addresses that are included in the deployment project. This allows for a coverage analysis to be conducted, which allows for proper planning of resources and predictive scheduling.
It’s also very helpful to provide the type of footprint for each store (assuming you have some form of standardization across your store portfolio) and current as-built floor plans that allow the deployment technicians to know where existing infrastructure already exists, and they can optimize their time in the store.
It’s important to specify any special considerations for a store so that can be built into the deployment design accordingly. If the deployment itself has specific requirements (e.g. a dock), document how stores that do not meet the requirement will be handled.
The How
The first part of the “How” outlines how the deployment itself will be completed. Provide as much information as possible on the steps to be taken as part of the deployment (include the actual installation script if possible). Indicate whether a pilot and/or proof-of-concept is expected to be completed as part of the scope and how many stores should be included in each.
The second part of the “How” defines the deployment model to be used. If it’s a relatively small project, perhaps it can all be handled by a project manager. For larger and more complex projects, you may want to establish a command center or war room type of approach. You will need to specify whether you expect team members to all work in one room together or if they can work from remote locations.
The last part of the “How,” and usually the most overlooked, is to specify the governance model to be used, reporting requirements, escalation points, the decision-making process, and how the change control board must be utilized.
As you can see, these key considerations generate a cascading set of questions, which are then used to fully complete the scope definition. Once the scope definition is completely developed, it is fed directly into the deployment design. Your deployment design will only be as good as your scope definition, so make sure you give it the attention it deserves.
