Thoughts on Enterprise Software implementation and project management methodologies.

Any project managing an ERP implementation, regardless the methodology used or how the phases are labelled, is structured in the same typical way.

And so it has been since at least the last 30 years. When companies started to use ‘Agile’ for projects, (and I know I am taking a short-cut here) it didn’t really change the way things are done, it often just meant that the (detailed design and) development and testing became iterative cycles.

Also when the concept of ‘continuous improvement’ was added, not many organisations had an idea of how this could be embedded in their organisations, especially when the implementation project team gets dissolved.

The structure used to organise an ERP project in the way described in the introduction comes from the correct understanding that a software application platform supports (or should support) an organisation: the strategic goals and objectives of the organisation, the organisational structure, its geographical footprint, its departments, the business processes, the KPIs and all the employees’ requirements with regards to efficient and effective work. This means that the project starts with analysing the business, how it runs today, how it is organised and what the (strategic) requirements and objectives are. This analysis focuses on business requirements, process requirements, the business goals and objectives.  To a lesser degree the analysis is focused on the information technology requirements: it is the business goals and requirements that (should) drive the information technology requirements. The exceptions are for migration and application integration requirements, here the demand comes from the technology itself. 

In short, the methodology used during ERP projects is to analyse the requirements and design the proposed organisation, the (changed and new) processes and applications, build the application platform based on the design and train and proof the new processes and tools. The last step is to go-live and support the organisation and to solve all the issues that the organisation encounters in the first days, weeks or months after go-live.

The question is how successful and effective the implementation methodologies based on the above principles really are. Many of the ERP projects today fail or are at least considered less than successful. What is considered a successful project nowadays is a project that at least covers the functionality to an equal level as the old (replaced) system did and it is considered a win that the technology is updated to today’s standards....

And that is strange, if the project is considered a success when the ‘only’ plus is really the new technology and the organisation in terms of culture, processes, support for goals and objectives has won very little to nothing. The question is why we still stick to the methodology?

The challenges of today’s ERP implementations are best summarised as follows:

1. The organisation is disappointed with the results

2. The project takes longer than expected

3. The project is costing more than budgeted

4. There is frustration between the implementation partner and the customer

When we try to map those frustrations to the way the implementation project is organised or the methodology used, we can say that following areas are main reasons for so-called ERP Implementation failures:

1. Project Management and Governance: Scope Creep, resources allocation and availability issues, and of course Project Managers in-ability to organise the project because of lack of support or because the methodology is not implemented in the organisation and the organisation / leadership does not understand the methodology.

2. Change Management and User Training: Employees resist changes due to unfamiliarity or fear of job displacement or because of lack of adequate training and communication. The amount and depth of training required for users to effectively understand what the project is about are often underestimated. Of course, later in the project training in the use the new system and processes are too little and inefficient.

3. Cultural and Organisational Impact: Departments, stakeholders not sharing a common goal and or vision is a common issue for many projects. Moreover, the project not aligned with the strategic goals of the company and its Executive Management not willing to acknowledge the importance of the project in this area (and hence a dramatic lack of support) is a major factor for failure and frustration.  And further on Change Management: the culture shift required to adapt to new processes and tools is equally underestimated or even ignored again causing reason for disappointment and frustration. Two other important attention points: communication and flexibility. Management only understands the pressure of the project (the change) on the organisation too late and causes a state of panic which reduces the willingness to be flexible, creative and open to adjustment to the project. We also notice that the harder it gets, the more communication to the organisation reduces and is forgotten.

4. Process Re-engineering: As highlighted earlier in this article, understanding and documenting current processes thoroughly before designing new processes or transitioning to the new ERP system is much more complex and time-consuming than expected or what organisations are willing to accept (invest in). Aligning desired business processes with the ERP system’s standard processes without heavy customization can be challenging and can frustrate or demotivate the project team.

Are these the only reasons for frustration and project issues? It is worth noticing that often data migration is mentioned as a challenge for the project. But although it causes in some projects for delays and extra cost, data migration is almost never the reason for disappointment or dissatisfaction with what the project brought to the organisation (the value experienced). Also, difficulties with customisations and integrations development can cause or will almost cause for extra time and cost. But these are never the reason that that after go-live people have a feeling that not all that was wished for or all that is required is delivered. I would even argue that this is the opposite: the only things really measured and controlled is the software delivery. The application functionality, migration, customisations, integrations, reports and so on are basically the ‘easy things’ to manage. 

And when project evaluations show Testing or post-implementation support as challenges, I would say that this relates more to poor project management and / or the organisations motivation to allocate the right (amount of) people and to acknowledge the importance and the impact of the project as referred to earlier.

I believe the reasons as highlighted above are the reasons for project failure and require us to re-think the methodology we use and have us think of the resources and skill we require to manage and execute an ERP project successfully.

It is important to mention that an agile or alternative project deployment methodology is more likely to be successful than the waterfall approach, for reasons of flexibility and adaptability, User Involvement, Risk Mitigation and Enhanced Communication.

It is also important to mention that I believe that after an initial difficult project to implement an ERP system, continuous improvement projects will have a much better chance to be successful and organisations will experience much more value from those projects, of course only if those organisations still allow for those projects and make ‘appetite for change’ a core value of the organisation. It must be said in this regard that Cloud systems have the benefit of being the best tool for continuous improvement.

I would like to see this paper as a discussion paper and the beginning of a discussion in p2-i and among partners and customers, to help us improve our own organisation and our services to:

1. Establish the right methodology

2. Have our PM function organised

3. Hire the people we need to execute according to the methodology

4. Train and continuously train our people to be successful in our methodology

5. Train and organise the sales group to be able to sell our projects

6. Deliver projects successfully

I love to hear your comments and opinions!