Are you about to derail your ERP project?
Uppdaterat: 19 nov 2020
Our company is founded on the strong belief we have the competence to support companies in doing successful ERP implementations. We have our own proprietary methodology, Ready. Set. Go! which is designed to fight all shortcomings we have seen in earlier projects. We pealed back the onion to find the true root causes of failings in ERP projects. We ended up with three factors:
Weak management team ERP change experience
Weak project team ERP experience
Weak anchoring of project goals
Every problem we have ever seen flows from these three root causes. Nowhere do we blame vendors although in specific cases they may have misled clients, but we think those cases are not very common.
So, we decided to design a tool to measure the status for each future ERP project. Regardless if the project is about to begin or have been running for a while. The biggest benefit of using the tool is that you get clear indications of where your weak spots are so you can take action. That is how we use the tool ourselves in our engagements.
The Startklar tool is available free of charge as we want all ERP implementations to avoid the risks we have identified. You find it here. (only in Swedish)
Before you dive in, this article is not your regular easy to digest "Tips of how to..." as we tend to share, this one covers much more but in short form.
Ok, so now what?
If you have downloaded the Startklar tool already you have found some guidance as to how you are supposed to use it. In this article, we spend a little more time on the way you are supposed to interpret the subsection questions in the tool.
Before we get into the subsections you should know that the questions that you are answering about your project are of three different types:
If a property of your project setup is missing you miss a point
If a negative property is present you miss a point
If a property that significantly complicates your project is present you miss a point.
A comment to item 3 above; a complex item is not in itself a bad thing, we just say it creates a more complex project and complex project are more prone to failures.
Startklar main section “Project scope”
Ok, so in this main section we dive into the subsections of goals and other governing decision taken by executive management early on in a project.
Project goals – investigates if goals are achievable and measureable and can be used to steer the project. Vague project goals, just to cover your bases, is like no goals since the project team cannot infer what to do, neither will the vendor. It is like going to the car dealer asking to have light colored car of any make and horse power while you have a specific car in mind. Say which one!
Project exclusions – asks if it is clear what “de-selections” that have been made, it says as much about the goals as the goals themselves and helps keep the project on target.
Prioritization model - extremely important factor in ERP projects as the number of stakeholders are many and expectations are all over the place. The solution scope can only be controlled if the prioritization model is crystal clear. This is usually the most important explanation of failing projects since failure to clearly present the targeted solution promotes misunderstanding and disappointment which equals failure to many. It is all in the eyes of the beholder.
Solution procurement – Being relaxed vs the vendor and expecting the vendor to be a mind-reader and sell you exactly what you want is extremely naïve in an ERP context. This is big ticket items and the vendors many times do anything to win your business. To no surprise the number of cases where ERP buyers sue the vendor for cheating them are many! But it is you as buyer who should assume the responsibility to be professional and do your homework properly. That is what we ask about in this section.
So, with those kind of strategic steering principles covered we move over to see if the project has the right structure in place to function properly throughout its life cycle.
Startklar main section “Project model”
This section is here to validate that the project setup is well designed and appropriate for the client. Most of the time the vendor will provide their proprietary model which is “one size fits all” and not adopted to the culture, organization and competency of the client. Hence, following it blindly will lead to frustration and disappointment. Most clients have not done ERPs before and therefore trust the vendor to provide all the answers…but they do not!
Project phases – the most important aspect of project phases is that you have clearly defined decision gates in which quality of delivery is accepted or rejected. This is a key role for the steering committee to fulfil – to be the guardian of a certain quality level delivered to the business from the project. Decision to accept a subpar quality level needs to be taken with full understanding of the consequences so it can be brought to the attention of line management by the steering committee members.
Project organization – of course, to carry out a complex ERP implementation requires skilled project members. To be able to judge the members competence, role descriptions and required past experience must be clearly stated to identify if there are any risks arising from assigning a specific team onto the project.
Project tools – the tools in themselves are not that important, a good team will devise the tools they need. But the absence of tools, documentation and plans are a giveaway of a poorly functioning project.
Quality management – quality means to meet the decided goals. Since ERP projects are prone to continuous development as the project proceeds, especially adapting the vendor solution to the technical landscape at the client, it is notoriously hard to at all times present what the solution contains. But, with a strict and well managed change process and decision logging, this is achievable. The absence of such quality management is disastrous for ERP projects.
So, with good points for project model you can rest assure you have a structure in place which can be built upon. And most of the shortcomings in this section can be remedied pretty straightforward.
Startklar main section “Change management”
“Since you as project manager really only must manage the plan you are expected to do the change management as well” – ask any ERP project manager and they can testify to the previous statement. However, a large ERP project normally requires the PM to spend 100% managing all normal project processes. And underestimating the time needed for change management by the project sponsor is a sure giveaway of too little experience from ERP projects.
Management/sponsor – measures whether the management team in their dedication to change management has revealed their understanding of the need for structured change management.
Change Project management – measures if the understanding of the need of change management is manifested in a proper role for driving change as well as structure and tools and a way-of-working with such matters in the organization.
Employee understanding of change management – measures how well anchored the change management project is with different stakeholder groups.
Earlier experience with CM – investigates how “normal” it is for the company to manage change with dedicated resources and tools.
So, I think it is clear that if you get low scores in this section you are leaving the tracks, you will sooner or later derail your project. If your response to this is “how hard can it be?” you have clearly not had enough exposure to complex ERP projects.
Startklar main section “Project competence”
So, in this section it is more an investigation into the way the organization is used to, if at all, running projects and in particular internal development projects. If this is the normal way of operating there is usually a large crowd in the company that gets it.
Project experience – investigates to what extent the general employee population is used to managing projects in general
Requirements experience – investigates to what extent the company is good at system procurement and system design specific to ERP situations
ERP project experience – basically asks about how many actually have done ERP projects before, a low number of such employees is a strong warning signal
Process development experience – since ERP projects cannot be done without processes designed to fit the way of working with the system setup it is key to have sufficient knowledge in the company of these type of efforts.
With high scores in this area you have a solid base of competency and experience to build from. Of course, experience on paper needs to be translated into effective project deliverables which is another matter for to the PM. It is inherent in Startklar tool that proper management understanding of the nature of an ERP project leads to the assignment of a strong and experienced ERP project manager.
Startklar main section “IT competency”
For this section I want to point out that some of the questions asked more means that the competency has been acquired, be it internal or provided by an external party. Only large companies with a substantial IT department would otherwise score high in this section.
Development – measures the existence of a software development capacity and process
Infrastructure – investigates the company platform management and policies
Maintenance – investigates how well developed the IT department is in terms of standard maintenance processes and organization
Technical project management – investigates the existence of established processes and organization for technical project management.
If the above items are not in place at the outset of an ERP project you will not get far before you have to fix these. Of course, going for a cloud based model allows you to outsource most of it, that is a good reason for smaller businesses to handle their shortcomings in IT competency by buying all of it.
I wrote this article as an explanation of our model and to highlight the breadth of topics to consider at the outset of an ERP project. Usually we see that clients jump into the engaging topic of designing detailed requirements in the strong belief that they are about to design the final solution and then buy it – how hard can it be? This way of reasoning will put you in the deep end of the pool. Instead, address the aspects in the Startklar tool, then worry about designing the solution and implementing it in a way that ensures you will reap the benefits you have built your business case on.