Navigating treacherous reefs at night without the guidance of radar or a lighthouse can mean the demise of a ship at sea. Similarly, trying to navigate an ERP initiative without proper guidance can lead to a failed implementation. Navigating with a lighthouse, however, makes that treacherous journey possible.
Here is an all-too-common scenario: Your organization has invested thousands of hours and dollars in the initial assessment and vendor selection phases common to all ERP and enterprise-class software projects. You conducted business process mapping workshops, stakeholder interviews, site visits, surveys, RFI/RFP preparation, distribution, analysis, software vendor demonstrations, and final solution selection. Final contract negotiations for software, maintenance, and implementation services were completed and you’ve held the Kick-off meeting to determine estimated hours, costs, and time frame for the implementation project.
Management is happy there is a selected vendor, as well as some tangible ideas as to schedule and costs. The vendor(s) selected are happy because they have a new client and project to execute.
Unfortunately, reality soon creeps in. According to a study conducted by the Gartner Group, 70 percent of all ERP projects fail to be fully implemented even after three years. Many are not even “live” after that amount of time.
Many ERP implementation projects fail or take much longer than budgeted for because the client companies believe they can supervise the project, coordinate the vendor activities, manage the implementation partner’s staff, as well as manage their own internal staff all without help. Despite best intentions, the typical mid-market company simply does not have the right person(s) with the skills, knowledge, experience, or even the bandwidth to effectively manage a modern ERP project. Like the boat trying to reach its destination with the crew shining flashlights into the ocean through a channel they have never sailed before, there is a reasonable chance of failure.
Therein lies the benefit of utilizing a proven, experienced, independent third-party consulting team to manage your project. The value provided goes far beyond what most would consider “project management”. It is the concept of “active project management”, which places considerable effort into managing risk, forecasting changes, and initiating changes before problems occur.
1. Lack of cooperation (alignment) – Are the core functional and technical teams working in cooperation with one another? Do they communicate effectively and efficiently? Do they coordinate decisions and actions, and share responsibilities for identifying and resolving issues as they arise?
2. Management team members are late for, not participating in, or absent from meetings – In the beginning, did the management team pledge their support, but now you find they often do not participate in key meetings? Are the company leadership team and the project sponsor still engaged on a weekly basis, or has their involvement slid back to only monthly or semi-monthly update meetings? Are the once regularly scheduled management update meetings moved around often to accommodate management because there always seems to be other priorities? Is there productive dialogue, or is it simply a presentation from the front of the room?
3. Team members become reassigned to other projects – Has the management team reassigned several core team members since the inception of the project? Is the core team the same size as when the project began or has it been reduced significantly? Has the number of full-time project members been reduced?
4. Core team members failing to achieve their project commitments on time (or at all) – Are the various functional and technical team leads and other core team members held accountable for missed deadlines? Are missed commitments taken seriously and handled immediately to get the project back on schedule? Are due dates assigned to critical decisions? How are team members held accountable for program schedules?
5. Excessive functionality allocated to “phase 2” – Is the project team finding that more of what used to be required functionality in Phase 1 is being pushed to later phases because they will not be complete in time for Phase 1 Go-Live? Is the team constantly asking what they can delay to later phases? What is the knock-on effect of pushing functionality into Phase 2?
6. Fluctuating project priorities by management – Are the scope and/or go-live requirements being changed regularly by management? What was the original or intended scope? Are priorities being changed that make sense, or are they actually causing the team to lose efficiency and effectiveness? Is it not always clear what the priorities are?
7. Mission creep – Has the scope increased significantly from the original kickoff meeting? Does each change in scope get prioritized and approved by the leadership team? Does each functional and technical team get to add whatever they see fit without any review as to impact on the other teams? Has the team identified two or more “code modifications” that will affect future software release updates? What has caused the change in scope, is it a newly identified business initiative, or a result of workarounds?
8. Ongoing schedule delays – Has the go-live date been delayed two or more times already? Has the team decided on new go-live dates based on an analysis of what needs to be done to make it happen, or simply picked the new date based on “calendar convenience”? Has an honest assessment of go-live capability been established?
9. Vague project status reporting – Does the current project reporting provide a clear picture of scope, status, and schedule? Does each functional and technical team provide detailed information, or is it very general? Is the senior leadership team only asking for very general information without really understanding the impacts of what they are being told? Is the reporting consistent and easily digestible, according to critical dates and milestones?
10. Non-availability of the accurate plan-versus-actual budget – Do the monthly and/or weekly meetings include a review of current costs and schedule impacts? Is the overall project being reported against standard performance metrics like Schedule Performance Index (SPI) and Cost Performance Index (CPI)?
Your implementation assessment team should be able to recognize these signs of a failing project and flush out and address the underlying root causes. In our next post, we will dive deeper into some of the root causes of failure that surface through these ten initial assessment questions.
In the meantime, if you are sensing issues in your current project, it could very well need a “rescue” plan. Reach out for help sooner than later. The normal tendency is to continue, and “hope” that the project issues will somehow resolve themselves – often while looking for whom to blame. Unfortunately, “hope” is not a strategy!
Thank you for reading, and please give KnowledgePath a call if you would like to discuss ideas further on how you can navigate your current or pending ERP initiative.