Project Description
Commencing a Large-Scale Retail System Implementation
Plan to Succeed
Commencing a Large-Scale Retail System Implementation
Plan to Succeed
If you search the internet for large-scale retail system implementation failures, you will find many “top ten” lists. In fact, one article from CIO Magazine, “15 famous ERP disasters, dustups and disappointments” estimates that collective lawsuits resulting from ERP failures are in the billions of dollars.
In this point of view, we will discuss some of the critical elements required for a successful retail system implementation based on lessons learned through Parker Avery’s extensive experience with a wide variety of companies.
- Preparation and Organization
As most project managers know, the PMI® Project Management Book of Knowledge (or PMBOK®) defines project stages as Initiation, Execution, Monitor & Control, and Closure. Many project managers are competent in the Execution and Monitor & Control phases where a project will spend most of its time. While there is no fool-proof solution to prevent the previously mentioned failures, in our experience, most project managers do not spend enough time during the first phase where many of these potential failure points can be identified. A project manager needs to allocate sufficient time and resources during the Initiation phase to set up a solid foundation and structure.
At the onset, there are two key elements required for any project: methodology and project team. Parker Avery has published points of view on the importance of both of these, “Project Management: Keys to Project Success” and “Ensuring Transformational Success: Bringing the ‘A-Team’.” A company can have the best methodology in the world, but if the right organization is not in place to support it, the methodology will not matter.
Beyond a solid methodology and suitable project team, there are other tactical items that should not be neglected. These are especially true in a major retail system implementation where there can be over 100 full-time resources involved across multiple teams. These key elements include development of a project charter, establishing a solid change control process, outlining specific approaches for making decisions and managing risks and issues, as well as selecting and utilizing the proper tools and documentation. By following these guidelines, managing a large-scale project—while not easy—should be more manageable. Let’s take a deeper dive.
Too Big to Fail?
Recently, a contingent of Parker Avery consultants worked on a massive, multi-year enterprise resource planning (ERP) implementation project for a retailer based in Canada. Just prior to this project commencing, news of Target Canada’s ill-fated demise circled endlessly throughout the media. The client’s leadership team was concerned that if a much larger—and traditionally very successful—company could fail in such a colossal way, then the potential for failure for their initiative was conceivable.
Thus, to not repeat those mistakes, articles outlining the reasons for Target Canada’s failure became required reading for anyone joining the project team. While the objectives and scope of Target Canada’s initiative were markedly different than an ERP project, many of the reasons attributed to their failure—supply chain issues, bad data, poor project management, wrong IT solution, among others—are symptoms often associated with botched large-scale retail system implementations.
- Project Charter
The most important document to be created when a project begins is the project charter. This document defines what the project is and serves to ensure the project delivers what is expected. The project charter should include, at a minimum:
When agreed upon and approved by the stakeholders, the project charter becomes the project blueprint. On a large project, there should be an initial kickoff meeting (or multiple meetings depending on size of teams), where the project charter should be socialized. All project team members should have an in-depth understanding of the project charter, and there should be no deviation from the charter without going through the change control process. It is not a bad idea on a multi-year engagement to review the charter on a periodic basis to ensure the scope is being maintained and the governance structure is still being adhered to.
- Decision Governance
As part of a retail system implementation, there will be many process improvement opportunities identified and many process-related decisions that need to be made. It is critical to create a decision governance model to identify how the changes will be reviewed and who decides if the change should be incorporated or not. Additionally, the escalation path should be outlined. Building this model will ensure the program avoids spin and prevents the revisiting of decisions and scope.
A sample model is shown below:
| Harmonization | Optimization | Transformation | |
|---|---|---|---|
| Core Team | Develop proposed ‘to be’ process through mapping workshops | ||
| Business Leads and Subject Matter Experts | Review processes through workshops | ||
| Operational Steering Committee | Review process improvement summary in steering committee meeting | Review each transformational change and its impact and benefit | |
| Executive Steering Committee | None | Approve and socialize to organization | |
Typically, the process opportunities can be classified across three categories:
- Harmonization: Standardizes an existing process across the organization
- Optimization: Improves an existing process to be more efficient or effective
- Transformation: Introduces a new or significantly different capability
The chart is completed by identifying the different program roles and the responsibility of each role across the different categories. In the above example, the project core team is responsible to identify all opportunities and present any key decisions. The new opportunity/decision is presented to the project’s business lead(s) and other subject matter experts, as required, for their review. This ensures the “doers” have buy-in.
Upon the business leads’ approval, the change or decision is presented to the next level. For those decisions that standardize or improve an existing process, the project steering committee should review and approve. For proposals that significantly alter a process or introduce a dramatically different capability, the decision on whether this is good for the organization needs to be made at the executive or C-level. Again, this is to secure buy-in. Additionally, all decisions must be documented to avoid revisiting the same issues (which inevitably will occur).
Enabling this type of governance model and the supporting documentation will prevent decisions from being re-visited. They key is to start bottom-up and work your way through the organization depending on the significance of the change or decision.
The model outlined is an example and should be tailored to suit the organization and the type of changes that are being proposed. Most importantly, any decision model should identify who is responsible, accountable, consulted, and informed (RACI) as well as clearly outline the decision-making path.
- Change Control
Similar to decision governance is change control. The main focus of change control is project scope (as opposed to changes to business processes). However, change control can involve other things such as project duration (i.e., scope stays the same, but the project will take longer to complete) or budget. There can be overlap when a business process decision impacts scope, but the main point of differentiation between these two models is that change control is about changes to the project.
Most companies have a change control process established within their software development life cycle (SDLC) methodology. However, in many companies, it usually is not much more than a form and a change log. There may even be additional verbiage that the change request should include in order to be reviewed and approved.
To most effectively manage project changes, a change control process should specify what types of change need to be approved and by whom. As an example, no time or money impact can be approved by the program manager—but rather, these changes must go to a steering committee or executive board. However, for a large-scale project, while these steps are a start, it is not sufficient.
Large-scale retail system implementation projects have many different moving parts and usually consist of many smaller projects rolled into one. As such, the change request needs to proceed through several layers to ensure it is worthwhile and does not conflict with deliverables/requirements. To accomplish this, a process that includes a review board prior to going through an approval process must be created and implemented. For example, the change request should first be identified as required by one of the project teams. The requesting team completes the change request form and presents it to a cross-team review board. This board’s purpose is to review, not approve, the request to ensure there is no impact to other project deliverables. If there are no issues, then the change is presented to program leadership, and depending on approval process, a steering committee or executive leadership. All of the above should be outlined in a simple flow and included as part of the project charter.
Change Control Steps
Identify change request
Log change request
Review change request (several rounds)
Assess change request
Approve or reject change request
Update scope, budget, and/or schedule
Of course, there are additional complexities when working with scope changes. In some cases, it is not unusual to have an approval process to proceed with the analysis first because the work to complete the analysis is significant. If so, the analysis request would go through the same process to determine if there is any impact and if there are other considerations.
By instituting these simple steps, you can prevent later “oops” moments when a change leads to additional issues because it impacts another area or team that did not make the request. As mentioned earlier, as design sessions occur, just as the sun rises every morning, a previous decision will be challenged. As with decision governance, when a solid change control process is in place, scope creep can be avoided by referencing the log to prevent previous decisions from being revisited.
- Risk Management
In our experience, an area that does not get nearly enough time and energy devotion is risk planning and management. One of the first things to establish is a risk log. The key elements a risk log should contain include:
- Impact or severity
- Probability
- Risk exposure level (calculated using severity and probability)
- Mitigation steps
Once the log has been established, it must be actively managed. During the project kickoff, the risk management process should be defined and explained, as well as what specifically constitutes a risk. Many people have a hard time understanding the difference between a risk and an issue. The simplest explanation is that a risk is something that can happen, and an issue is something that has happened. If the risk materializes, it then becomes an issue. Risk management is the process to avoid having risks turn into issues; therefore, risk management needs to be an ongoing exercise. The project manager needs to be proactive and not reactive—essentially, throw away the fire helmet and put on the construction hat of an engineer.
A kickoff meeting should be held to ensure all project resources understand what a risk is and the importance of early risk identification and mitigation. After the kickoff, the individual project teams should conduct ‘risk identification brainstorming’ meetings. During this exercise, a moderator will need to segregate the project into different components (e.g., resources, scope) to lead the discussion. Additionally, the moderator should have sample risks identified to get the creative juices flowing.
Once the project team identifies some risks, each risk should be assigned to a specific individual who will be held accountable for mitigation, or in some instances, avoidance. The purpose of this exercise is to educate the team on risk identification as well as enabling them to proactively prevent risks from becoming issues. It is well worth the time to ‘pay a few pennies now to save dollars in the future’.
After the kickoff, there should be regularly scheduled risk meetings. Similar to reviewing an issue log, existing risks are reviewed, and additional risks are added. These meetings can occur weekly or monthly, depending on the project length.
- Issue Management
To ensure nothing is missed, anyone should be able to raise an issue. An issue may impact scope, timeline, budget, or quality of deliverables. Issues should be managed within a project issues log, and as with risk management, this must be kept simple. Further, all issues shall be assigned to a resource with a realistic and agreed-upon due date.
Members of the project team should be empowered to resolve issues at their level of competence and authority. Issues of a strategic nature or requiring additional budget will be escalated to the program manager and raised as a change request. Typically, at the time of creation and assignment, the status of an issue is ‘open and active’ and remains so until resolution, at which point the status will be changed to ‘resolved.’
If the issue, after further review, is deemed a ‘non-issue,’ the status will be changed to ‘closed.’ If it is determined the issue will not be resolved within the current project and it has no impact on the current scope, then it should be noted as a future enhancement and the status of the issue changed to ‘deferred.’
Retail System Implementation Tools
The most important thing to do for both risk and issue management is to have an easy and accessible tool to manage them. While perhaps an obvious point, there are many tools available such as HP-ALM®, JIRA®, or a spreadsheet within Office365® or Google Docs®, but the key is to keep it simple. By keeping it simple, project resources are more likely to access the tool and use it. End user simplicity is critical to foster consistent use of the tool, but capabilities that allow program managers to effectively govern the program should also be a key consideration. While spreadsheets are normally the simplest and easiest tool, they are not necessarily the best.
For a large-scale retail system implementation project, it is usually worthwhile to use a tool designed for this purpose such as JIRA®. These large-scale tools usually have reporting capabilities that allow a program office to flag and communicate risks and issues that need to be reviewed at various levels. Many of these tools have workflow included to aid in building approval and/or task assignment processes, which assist the project manager in tracking and monitoring progress. For risk management, they will have the severity and probability weight calculations built in to quickly identify which risks need to be addressed first.
It cannot be stressed enough to not get too complicated, as well as avoid having a different tool for each process (e.g., spreadsheet for issues, a tool for risks, another tool for change requests). Whatever tool is used, ensure it is easy to use and efficient. If not, then people will bypass it or ‘pencil whip it.’
Final Word
We have outlined the key factors on which to focus when initiating a retail system implementation to ensure the team is organized and poised for success. These elements are meant to be a guide and give food for thought, but there is no one ‘perfect’ recipe. Every project has unique characteristics and constraints. Do not be afraid to modify a ‘standard process’ or approach to fit a project’s needs. Half the battle is ensuring all team members are playing from the same playbook and understand what is expected.
One last thing to mention is to not neglect the very final stage when a project is complete. While many times project resources are more than ready to move on and begin a new project or resume their prior role, it is vital to conduct a post mortem or ‘lessons learned’ session when closing out a project. Many implementation methodologies have been improved based on what went right and what did not; therefore, documenting this information and leveraging it during the onset of future initiatives helps to greatly improve the chances of success.
Contributors
The Parker Avery Group is a leading retail and consumer goods consulting firm that transforms organizations and optimizes operational execution through development of competitive strategies, business process design, deep analytics expertise, change management leadership, and implementation of solutions that enable key capabilities.
