In the world of ERP deployments where the reported project failure rates go as high as 70 per cent, many factors cause things to go astray. With failure rates this high, you have to wonder how System Integrators (SIs) stay in business.
When researching why so many ERP implementations are late, over budget, or fail to meet the expectations of performance, you will uncover the usual cast of characters:
- Lack of executive support
- Software that is not aligned with business process needs
- Poor estimates
- Lack of rigorous project management
- Out of control scope
- Lack of qualified talent
- Lack of user participation
So why do SI’s still make money?
The answer lies in the fact that most of these conditions are products of misalignment on the client’s side and are therefore not covered by the contract. The SI can legitimately claim contract adjustments were necessary because certain assumptions that were documented were not met.
Your SI will be up-front and provide a process for risk mitigation. It will involve entering these specific risks and others into a risk register and developing specific tactics to mitigate the risk or suggest you build contingency plans in the event these risks turn into real issues. This cannot be your only answer for addressing these risk points. I would offer that these conditions of failure are likely a symptom of a deeper problem rooted in your business relationships.
I used to tell my CEO that within 5 minutes of visiting a location that was getting ready to deploy an ERP system, I would know exactly how successful that implementation was going to be. How did I know? I simply asked the business executive responsible for the location what the current status of the project was and what his/her biggest concerns were. If the executive rattled off a set of problems and issues that they were addressing, I knew we were going to be ok. If the executive suggested that we talk to the local ERP deployment lead, then I knew we were in trouble. The success or failure at a location all revolved around the relationship the deployment lead had with the executive in charge.
Extending this line of thinking, here are 8 critical relationships in an ERP program that are at the core of ERP successes and failures.
1. The CFO and the COO – Many ERP projects have been labeled as failures because the ERP package selected did not meet the business needs. This is often a translation for the Supply Chain or Manufacturing Process Owner and the Financial Process Owner not compromising to accommodate one another. They need to establish a shared vision and project this vision down through the whole organisation. When significant disagreements surface and there is not a clear understanding of escalation and problem resolution, then project assumptions made regarding speed of decision-making become invalid and scope change requests will be forthcoming.
2. The Program Lead and the CIO – Schedule achievement within ERP programs is highly dependent on the agility of the IT infrastructure team to rebuild test and development environments. Typically, these resources are under the full control and authority of the CIO. Given that the Program Lead is completely revising the application infrastructure currently supported by the CIO, there are often power struggles regarding the control and management of the infrastructure.
If there is not a solid relationship and mutual respect with open communication channels, schedule slippage is inevitable. Schedule slippage related to the performance of internal resources will result in a scope change request. A second component of this relationship will be establishing standards for development and integration. The SI will come with a set of processes that are likely not to match those that exist in the current IT organisation. The Program Lead and the CIO need to broker an agreement on the ground rules for documentation and IT standards to avoid future contention in this space.
3. Executive Line of Business (LOB) or Geographic Business Leads – For the same exact reason as point #1 above, LOB or Geographic Leaders must agree that a Global Business Process will be implemented and that compromises will likely be required to realise the overall expected benefits associated with standardisation.
4. On-Shore and Off-Shore Delivery Managers – This relationship usually works itself out over time, but if it is bad from the start, then you will see delivery problems on RICEFs (reports, interfaces, conversions, enhancements, and forms). There needs to be a very well-structured protocol for communications and clear expectations on documentation and status reporting. If these two individuals do not share the same vision of delivery or status of the efforts, then productivity assumptions will likely be invalid. This productivity assumption is sometimes planned for within the SI’s bid… but why pay for it if you know that this relationship could be the cause?
5. System Integrator Lead and Software Provider Lead – Complex systems like SAP and Oracle provide a multitude of ways to realise a company’s vision of a business process in their software. There will often be debates regarding the correct solution for your situation. Take the simple situation of meeting the statutory reporting requirements for a foreign entity as an example: your SI might be recommending customer reporting while your software provider is pointing to already developed bolt-ons. It is critical that there is a methodical decision-making process that is agreed and adhered to by all parties in advance.
6. Program Lead and LOB Executives and Functional Executives – There is going to be a significant pull on user resources to deliver training, data cleaning, testing, and deployment activities. This pull will likely create risk for the LOB to meet performance targets during the big pull for resources. Open dialog of communications around the expectations for this pull will help the LOB Executive manage expectations for her/his business performance. If push comes to shove, the LOB will be more inclined to meet their committed business performance targets versus allocating more resources to the program. Program Leads can either expect a scope change request due to the delay, or be forced to add additional resources to cover for the shortfall in user resource delivery expectations.
7. The Program Lead and the System Integrator Lead – After a tough negotiation there will be a tendency by the SI to want to win back what they gave up to get the business. Establishing standards for scope changes and consistently working to reinforce the spirit of the agreements made is often necessary to keep this relationship under control. There is a tendency with SI management to want to switch leadership on the project over the course of the project. Why? They don’t want the SI lead to assimilate and go “native.”
Tactic: take the SI lead out to lunch and treat him/her like a customer. You will be amazed at the response you get.
8. CEO and the Program Lead – If all other relationships are in order, this relationship has diminished value. If not, then this becomes the most vital. CEO’s seldom want to pull rank on their executives to make decisions; it is not healthy for their business. However, if the LOB and Executive Functional Leaders understand that there is a strong relationship/mentorship between the CEO and the Program Lead, then they are less likely to let decisions surface to the CEO level and are more apt to compromise when necessary.
Actionable recommendations for ERP program leads armed with this information:
- Take stock and evaluate each one of these relationships. Make your own assessment regarding the overall quality of the relationships and the ability to have the various parties involved work like a team.
- Introduce the strength of these relationships into your overall evaluation of the probability of the risks in your risk register coming to fruition. The linkage of the relationship to probability should be obvious and the risk converted to expected project contingency budget. This is not easy, but effective in drawing attention to relationships that appear to be broken, and in aligning the parties around a common goal.
John Belden, Project Execution Advisory Services Leader, UpperEdge
Image source: Shutterstock/Mikko Lemola