The top issues that have been seen across industries are:
1) The complete lack of an executable project plan. Even when the SOW indicates it is part of the System Integrator's deliverables, some of the SIs are resistant in creating one, or at best creates a shell that is not used in actual execution of the project. Many things happen or more accurately, don’t happen when there isn't a plan. First, there is no way to know where the project is relative to each milestone, so it is absolutely impossible to explain to senior management if the project is on time or budget. Secondly, the dependencies that can be built into the plan aren’t visible to the project team, so deadlines are missed due to others not completing the work in the right sequence, hence the go live date is always being adjusted out further in the year. Also, the roles and responsibilities and who is responsible to perform which activities is also vague because the names and ownership is not attached to an actively managed task. Finally, The lack of a plan associated with such complex projects, leads to more change orders that add time to the project and cost to the budget to get what was promised in the SOW. It costs more and takes a lot more time to do.
2) Another severe project issue is the Business Justification and Executive buy-in for the project. Without the leadership of the company supporting the project, the necessary resources and commitment from other managers and peers in the organization can withhold valuable people who are needed to complete the different and difficult tasks aligned in the project plan. The senior management of the company is responsible for funding and approving key decisions that have a direct impact on the outcome of the effort. The culture of the company comes into check here, without commitment, the project can and usually becomes an IT effort that the business can later not adopt, or continue using the older legacy applications that have been in place forever.
3) Definition of Scope and Requirements are the bread and butter of ERP. Without clear direction, even the early configuration of the instance cannot be completed without significant assumptions. Gartner has developed a PACE layering approach that now focuses on the differentiator and innovation within the business requirements. During the workshops, the Subject Matter Expert or SME and business representative are asked not what everybody else does, but what makes the company unique. Finding the key differences between one company and the market, allows the company to focus on what is important rather than worry about the non-value added capabilities of a software package. Some of the non-value areas might be paying the bills or running payroll. Every company is different in which features and functions are foundational and which add competitive advantage to the company. Gartner’s Pace Layering and defining the 3 levels of features helps narrow what areas need to have resources attached to the deliverables and which might be outsourced. This stratification of the functions sets up a clearer prioritization of work to deliver what is most important to the company.
4) The Definition of Key Deliverables and Milestones is imperative in developing the overall project plan. Knowing what the key deliverables are is the first step to knowing who might be responsible for them and when they fit into the project execution sequence. Some of the key milestones might be the approval of the project, funding or charter to start the project. In some companies, there is a formal capital request process that must be completed to ensure the financial return is included in the project deliverables. Just a quick note on that, the interesting thing is most companies never go back and check the actual payback or loss after the project has been completed. The other milestones might be specific deliverables in the scoping and design of the application, the build phase is a big deliverable and of course, the completion of testing is a huge milestone for any ERP Project. Knowing the major efforts enables the outline of the project plan to be completed. Now all you need are the dates and resources to make it complete. It should be that simple right?
5) Planning for the Project is by far one of the most important tasks that can be done during the preparation of the launch. Once the System Integrator is onboard, it might be too late for the plan to have much chance to be a true reflection of what the project needs to complete and when. Most of the projects I am asked to assess, and in the end, rescue, lack any resemblance of a plan. Face it; writing a project plan is hard to do. Each ERP project includes a different application footprint, and the companies have a different hardware and workflow configuration and user base, plans have to be custom written for each project. Let’s make it simple. As much work as they might present there are only five things that have to be described at the beginning of the project.
§ The Milestone which might be a deliverable
§ The Tasks that support the Milestone
§ When the Deliverable needs to be done and how long it might take
§ Who is going to do it
§ Which tasks depend on other tasks being done before another
Obviously there is a tremendous amount of work to describe the project when it is a Global, multi-company effort. The trick in getting the plan together is starting at the beginning and knowing you have a structure that can be expanded to include the other sections. Most project plans are broken into 5 sections, 1) Analyze, 2) Plan, 3) Design and 4) Build.
In the Analyze phase is really the discovery phase, what is the scope of the project, which order should the software be deployed, are there regional or localizations necessary to include in the deployment, and what does the implementation team look like with the definition of the core team and partners such as System Integrators or other 3rd party vendors.
The Planning phase is just that, developing the plan and getting the proper input to know what, when and who will have a part in the delivery.
Once the project is planned, next comes Design. Actually thinking about the company requirements and how the software will represent the configuration of the different processes within the company. This section also includes the Architecture solution and infrastructure necessary to bring the system online. There will be database design, instance design, programming design, security, and identity or Separation of Duties, or SOD design.
The final step is building what has been designed. This step also includes the deployment and go live processes. There is testing embedded in the processes as well. Remember, each one of these actions require a set of tasks written in the project plan to execute. I would like to offer just some hope that any of these steps is easier than the one before, but they each present challenges in their own way. Testing is part of the build phase for most companies. In some cases, there have been companies that decided not to test. You will test, the question is if the testing will be in the pre-production environment or in production. It's much cheaper to do it before it is rolled into production.
6) Communication or the lack of is another area that can have a devastating affect on an ERP project. In one case I was found a company that literally had no communication up the management chain on the project. The issues that were found during testing or development were never shared with the team so the only way things were uncovered were when the proverbial stuff hit the fan. The bad news got trapped in the rank and file so risks continue to go unattended until it was too big to keep secret, and the cost to fix them were too high for the lower management to sign off. The best practice here is to have an open and honest communication pathway all the way through the organization and project team. From the very start, the executive team must insist on open and honest communication. I have suggested to some of my clients that they should award those individuals who find the most bugs within the system.
In the beginning of the project during the pre-launch phase, develop a communication plan that includes not only what you will communicate but how and how frequent.
7) One of the parallel deliverables along with Communication is the development and distribution of project metrics. These too are perceived as difficult to extract from the project and hence, not very often included in the status reporting and communication model of ERP projects. Some companies support the PMP and PMI, PMBOK approach to project management, which can be effective, but besides the certifications, still requires a lot of attention to the project plan detail. taking the project manager role for an ERP project has been equated like herding cats. For a twelve billion dollar consumer products company, I suggested just five metrics at first to set the baseline to communicate with the executive team. Once the metrics had been vetted and accepted by the team, another included 2 types of metrics were added for clarity.
First, always include operations metrics that will resinate with the executives as the metrics will be recognized as key business indicators. Metrics such as Inventory Management, Procurement to Pay and other Key Performance Indicators or KPI are part of the daily operations of a business. The final set of metrics introduced into the project are the financial metrics for the company, ROI on capital investments that are made, Cash flow and a budget to both forecast and apply the actuals similar to how most companies run a budget and P&L. Having the financial metrics available to the team can change the payments and alter the cash-flow to the company. At the end of a fiscal year, ask to hold payment until the first day of the next month which is the following fiscal year to save the cash flow. If I didn't say it in the beginning, I should have: these projects are all about the money. Be as sensitive to the spending and savings as you can be for the project.
8) Risk Management will either help or cripple the project depending on what is being captured and how the team responds to the findings. The failure numbers are tossed around in the software industry depending on the audience. The high number is 80% failure and the low around 45%. Neither number is good. The planning and allocation of funds and people is all about risk. Without clear Risk Management, the ERP projects have the likelihood of going off the rails sometime during the project execution. It is far easier to track the issues rather than attempt to rescue the project.
At a minimum, listing the risk on each track status report and highlighting the severe show stopper level on the main communication to the management team will help allocate and redistribute the necessary resources to mitigate the risk and make sure the project is on the right path. JoMax Consulting LLC has developed a new metric that represents the Risk Tolerance in a new Risk Tolerance Model, Risk Mitigation Quotient™ or RMQ™ that can be used as an effective tool in describing risk in a quantifiable way. This metric assigns a quantifiable value to the risk tolerance of a company or project.
9) Governance is part of managing an ERP project and maintaining the controls similar to the defining the risk to the project. The governance and oversight of the project should be considered well before a partner is selected or the project is put out for RFP. Ms. Karen D Schwartz said in CIO online, “Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance.” I don’t think I could have come up with a better description for IT governance. Governance is the set of processes that keeps the IT Projects aligned to the overall business direction and strategies. Supporting the governance of the project would be the performance metrics and Risk model and administration. There are volumes written on the IT Governance topic, this text is related to the broader delivery of a successful ERP project.
10) Most of the ERP projects I have been involved with include multiple phases and span multiple years. One of the best practices I see is the use of documenting Lessons Learned and actually learning from the lessons as painful as they may be. I have many clients who believe they are ERP experts because they have done 1 ERP project badly. Sadly, it takes more than 1 project to learn what is needed, what patterns can be seen and how the plan maps out to the final cutover into production. Learning is a continuous process, which hold true here as well. Capturing the lessons at premeditated intervals during the project and summarizing them at the end of phases and actual projects is the only way to leverage the learning into the next project. That is why hiring experts who have done the work previously is a benefit to the company. So another best practice. Talk to other companies and contacts that have gone through the deployment process of an ERP project and listen to their experiences, those count as lessons learned as well, they just didn’t hurt as badly as if they occurred to you.
There are other best practices that should be included here, these seem to be the most obvious, and most neglected by companies I have seen struggle to deliver the ERP project. I’m convinced, greater communication, a complete executable project plan that is managed with metrics and clear transparency is the key to reducing the risk of implementing an ERP project in any environment. I am asking others that have other hints in managing the ERP project to offer them in the comments section, there are as many as there are projects.
1) The complete lack of an executable project plan. Even when the SOW indicates it is part of the System Integrator's deliverables, some of the SIs are resistant in creating one, or at best creates a shell that is not used in actual execution of the project. Many things happen or more accurately, don’t happen when there isn't a plan. First, there is no way to know where the project is relative to each milestone, so it is absolutely impossible to explain to senior management if the project is on time or budget. Secondly, the dependencies that can be built into the plan aren’t visible to the project team, so deadlines are missed due to others not completing the work in the right sequence, hence the go live date is always being adjusted out further in the year. Also, the roles and responsibilities and who is responsible to perform which activities is also vague because the names and ownership is not attached to an actively managed task. Finally, The lack of a plan associated with such complex projects, leads to more change orders that add time to the project and cost to the budget to get what was promised in the SOW. It costs more and takes a lot more time to do.
2) Another severe project issue is the Business Justification and Executive buy-in for the project. Without the leadership of the company supporting the project, the necessary resources and commitment from other managers and peers in the organization can withhold valuable people who are needed to complete the different and difficult tasks aligned in the project plan. The senior management of the company is responsible for funding and approving key decisions that have a direct impact on the outcome of the effort. The culture of the company comes into check here, without commitment, the project can and usually becomes an IT effort that the business can later not adopt, or continue using the older legacy applications that have been in place forever.
3) Definition of Scope and Requirements are the bread and butter of ERP. Without clear direction, even the early configuration of the instance cannot be completed without significant assumptions. Gartner has developed a PACE layering approach that now focuses on the differentiator and innovation within the business requirements. During the workshops, the Subject Matter Expert or SME and business representative are asked not what everybody else does, but what makes the company unique. Finding the key differences between one company and the market, allows the company to focus on what is important rather than worry about the non-value added capabilities of a software package. Some of the non-value areas might be paying the bills or running payroll. Every company is different in which features and functions are foundational and which add competitive advantage to the company. Gartner’s Pace Layering and defining the 3 levels of features helps narrow what areas need to have resources attached to the deliverables and which might be outsourced. This stratification of the functions sets up a clearer prioritization of work to deliver what is most important to the company.
4) The Definition of Key Deliverables and Milestones is imperative in developing the overall project plan. Knowing what the key deliverables are is the first step to knowing who might be responsible for them and when they fit into the project execution sequence. Some of the key milestones might be the approval of the project, funding or charter to start the project. In some companies, there is a formal capital request process that must be completed to ensure the financial return is included in the project deliverables. Just a quick note on that, the interesting thing is most companies never go back and check the actual payback or loss after the project has been completed. The other milestones might be specific deliverables in the scoping and design of the application, the build phase is a big deliverable and of course, the completion of testing is a huge milestone for any ERP Project. Knowing the major efforts enables the outline of the project plan to be completed. Now all you need are the dates and resources to make it complete. It should be that simple right?
5) Planning for the Project is by far one of the most important tasks that can be done during the preparation of the launch. Once the System Integrator is onboard, it might be too late for the plan to have much chance to be a true reflection of what the project needs to complete and when. Most of the projects I am asked to assess, and in the end, rescue, lack any resemblance of a plan. Face it; writing a project plan is hard to do. Each ERP project includes a different application footprint, and the companies have a different hardware and workflow configuration and user base, plans have to be custom written for each project. Let’s make it simple. As much work as they might present there are only five things that have to be described at the beginning of the project.
§ The Milestone which might be a deliverable
§ The Tasks that support the Milestone
§ When the Deliverable needs to be done and how long it might take
§ Who is going to do it
§ Which tasks depend on other tasks being done before another
Obviously there is a tremendous amount of work to describe the project when it is a Global, multi-company effort. The trick in getting the plan together is starting at the beginning and knowing you have a structure that can be expanded to include the other sections. Most project plans are broken into 5 sections, 1) Analyze, 2) Plan, 3) Design and 4) Build.
In the Analyze phase is really the discovery phase, what is the scope of the project, which order should the software be deployed, are there regional or localizations necessary to include in the deployment, and what does the implementation team look like with the definition of the core team and partners such as System Integrators or other 3rd party vendors.
The Planning phase is just that, developing the plan and getting the proper input to know what, when and who will have a part in the delivery.
Once the project is planned, next comes Design. Actually thinking about the company requirements and how the software will represent the configuration of the different processes within the company. This section also includes the Architecture solution and infrastructure necessary to bring the system online. There will be database design, instance design, programming design, security, and identity or Separation of Duties, or SOD design.
The final step is building what has been designed. This step also includes the deployment and go live processes. There is testing embedded in the processes as well. Remember, each one of these actions require a set of tasks written in the project plan to execute. I would like to offer just some hope that any of these steps is easier than the one before, but they each present challenges in their own way. Testing is part of the build phase for most companies. In some cases, there have been companies that decided not to test. You will test, the question is if the testing will be in the pre-production environment or in production. It's much cheaper to do it before it is rolled into production.
6) Communication or the lack of is another area that can have a devastating affect on an ERP project. In one case I was found a company that literally had no communication up the management chain on the project. The issues that were found during testing or development were never shared with the team so the only way things were uncovered were when the proverbial stuff hit the fan. The bad news got trapped in the rank and file so risks continue to go unattended until it was too big to keep secret, and the cost to fix them were too high for the lower management to sign off. The best practice here is to have an open and honest communication pathway all the way through the organization and project team. From the very start, the executive team must insist on open and honest communication. I have suggested to some of my clients that they should award those individuals who find the most bugs within the system.
In the beginning of the project during the pre-launch phase, develop a communication plan that includes not only what you will communicate but how and how frequent.
7) One of the parallel deliverables along with Communication is the development and distribution of project metrics. These too are perceived as difficult to extract from the project and hence, not very often included in the status reporting and communication model of ERP projects. Some companies support the PMP and PMI, PMBOK approach to project management, which can be effective, but besides the certifications, still requires a lot of attention to the project plan detail. taking the project manager role for an ERP project has been equated like herding cats. For a twelve billion dollar consumer products company, I suggested just five metrics at first to set the baseline to communicate with the executive team. Once the metrics had been vetted and accepted by the team, another included 2 types of metrics were added for clarity.
First, always include operations metrics that will resinate with the executives as the metrics will be recognized as key business indicators. Metrics such as Inventory Management, Procurement to Pay and other Key Performance Indicators or KPI are part of the daily operations of a business. The final set of metrics introduced into the project are the financial metrics for the company, ROI on capital investments that are made, Cash flow and a budget to both forecast and apply the actuals similar to how most companies run a budget and P&L. Having the financial metrics available to the team can change the payments and alter the cash-flow to the company. At the end of a fiscal year, ask to hold payment until the first day of the next month which is the following fiscal year to save the cash flow. If I didn't say it in the beginning, I should have: these projects are all about the money. Be as sensitive to the spending and savings as you can be for the project.
8) Risk Management will either help or cripple the project depending on what is being captured and how the team responds to the findings. The failure numbers are tossed around in the software industry depending on the audience. The high number is 80% failure and the low around 45%. Neither number is good. The planning and allocation of funds and people is all about risk. Without clear Risk Management, the ERP projects have the likelihood of going off the rails sometime during the project execution. It is far easier to track the issues rather than attempt to rescue the project.
At a minimum, listing the risk on each track status report and highlighting the severe show stopper level on the main communication to the management team will help allocate and redistribute the necessary resources to mitigate the risk and make sure the project is on the right path. JoMax Consulting LLC has developed a new metric that represents the Risk Tolerance in a new Risk Tolerance Model, Risk Mitigation Quotient™ or RMQ™ that can be used as an effective tool in describing risk in a quantifiable way. This metric assigns a quantifiable value to the risk tolerance of a company or project.
9) Governance is part of managing an ERP project and maintaining the controls similar to the defining the risk to the project. The governance and oversight of the project should be considered well before a partner is selected or the project is put out for RFP. Ms. Karen D Schwartz said in CIO online, “Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance.” I don’t think I could have come up with a better description for IT governance. Governance is the set of processes that keeps the IT Projects aligned to the overall business direction and strategies. Supporting the governance of the project would be the performance metrics and Risk model and administration. There are volumes written on the IT Governance topic, this text is related to the broader delivery of a successful ERP project.
10) Most of the ERP projects I have been involved with include multiple phases and span multiple years. One of the best practices I see is the use of documenting Lessons Learned and actually learning from the lessons as painful as they may be. I have many clients who believe they are ERP experts because they have done 1 ERP project badly. Sadly, it takes more than 1 project to learn what is needed, what patterns can be seen and how the plan maps out to the final cutover into production. Learning is a continuous process, which hold true here as well. Capturing the lessons at premeditated intervals during the project and summarizing them at the end of phases and actual projects is the only way to leverage the learning into the next project. That is why hiring experts who have done the work previously is a benefit to the company. So another best practice. Talk to other companies and contacts that have gone through the deployment process of an ERP project and listen to their experiences, those count as lessons learned as well, they just didn’t hurt as badly as if they occurred to you.
There are other best practices that should be included here, these seem to be the most obvious, and most neglected by companies I have seen struggle to deliver the ERP project. I’m convinced, greater communication, a complete executable project plan that is managed with metrics and clear transparency is the key to reducing the risk of implementing an ERP project in any environment. I am asking others that have other hints in managing the ERP project to offer them in the comments section, there are as many as there are projects.
