Plan to Succeed:

Commencing a Large-Scale Retail System Implementation

Parker Avery Point of View by David Birdsall




Too Big to Fail?





Over the last several years, a contingent of Parker Avery consultants have been working on a massive 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 retail system implementations.

If you search the internet for large scale software failures, you will find many ERP failure “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 ERP implementation—lessons learned through extensive experience with a wide variety of companies.

Start Off on the Right Foot

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. Project Charter 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 point of views 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 large-scale 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.



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:

Reason/Why

This answers the question of, “What is the business need or business case?” for what is to be accomplished/built by pursuing the project.

Scope

This defines what specific functional areas, requirements, processes, systems, etc. are in or out of the project’s domain. Some project managers take a black and white approach of only listing what is in scope and then stating if it is not listed in, it is out. While a very simple and clear structure, it is better to also specify any important elements that are not included. This prevents the problem of “you didn’t tell me that was not included.”

Organizational Structure

The organizational structure outlines the roles for the project, where the team will physically work (e.g., co-located work space), and the overall governance and decision-making structure (e.g., steering committee, escalation path).

Budget

The project budget and how it is allocated must be specifically defined.

Project Dependencies

Dependencies will include things like another project that is expected to complete before a current project deliverable can be met, as well as environmental or political dependencies such as a new law that is expected to be passed. Some of the items here may seem straightforward but it is important to list as many dependencies as possible, regardless of if they seem obvious. During the review process, this section will usually set “light bulbs” off and additional items will be added that the project team neglected to mention during the initial discovery. Project Charter

Assumptions

This section is similar to dependencies but includes items that are required for the project to function properly. With many large-scale implementations, there are multiple companies that all have a different way of managing and implementing a project. This section specifies what the methodology will be, what language the project will operate in, and what tools will be used for change, risk and issue management (discussed later), among other elements. The purpose is to ensure all parties from the different companies work with the same set of ground rules.

Requirements

Depending on how or when a project starts, there may be previously defined requirements, or they may be part of the project itself, in which case this represents a key project step.  

Decision Governance, Change, Risk, and Issue Management

Many projects tend to overlook this section and do not spend enough time identifying the decision-making governance or how change requests, risks, and issues will be managed. Next to scope definition, this is most important item. Your charter should have a separate section on each of these areas. We’ll take a deeper dive into these areas in the next sections.


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 large-scale software 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:

Decision Governance

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.

Change Control Process

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 ERP 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.

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.

Risk Log

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. Project Risk vs. Issue 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.’



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 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 some of the key factors on which to focus when initiating a large-scale 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.


If you’d like to learn more about our vision or understand how you might take advantage of this strategy, contact us at Contact@parkeravery.com or call 770.882.2205.

Download PDF Version (1.2 MB)

Return to previous page