As consultants who assist clients day in and day out with their ERP implementation projects, we are often asked for our views on good practice on projects and what can be improved. There are many moving parts and varying opinions on this topic and on the ingredients to a successful implementation.
This article is not aimed at simplifying the key implementation considerations and challenges in these types of endeavours, rather it is our opinion on the common themes that lead to project success. This opinion is shaped by our experience with our clients – past and present – and consists of the experience we possess in our organisation.
1. The Importance of Process Mapping & Defining Requirements Upfront
As momentum gathers towards the cloud, Vendors are continuously morphing their methodologies into a rapid style of implementation. However, this needs to be balanced with some key principles for ERP project success. These being: a clear definition of what you want and how you want it (via business processes and requirements), evaluating the potential solutions that may meet that desired state (via a thorough system selection process), preparing for the implementation (via detailed Implementation Planning and Readiness) and then following through and tracking your progress (via sound implementation practices and guiding principles).
This all starts with adequate process mapping and requirements definition which provides the foundation layer for your project success. Done well, this provides you with a clear and consistent point of reference as you go through the project life-cycle.
Making compromises at this stage may significantly impact all future project phases and increases the risk of experiencing problems during the implementation. Not to mention that this exercise has a tremendous impact on building momentum and bringing everyone in the organisation along on the journey – this is instrumental in your success.
One recent example…
A recent example of where this didn’t go as planned was on a scoping exercise conducted by the Vendor for a WA based disability services provider. After several scoping sessions were conducted by the Vendor with no client definition as a base, the Vendor produced a business requirements document which did not reflect the client’s requirements and the challenges they faced. Three of the key areas that were not reflected were the changing funding landscape of NDIS, the organisation’s attempt to reinvent itself and the ever-increasing competitive landscape of the industry.
The vendor consequently commenced the solution build, utilising the business requirements document produced, without clear alignment to overall business objectives. With our assistance, the project was reset. We introduced a formal process mapping exercise to formalise the desired could-be business processes, highlighting key gaps in how the solution was able to meet these requirements. This ultimately led to the project being put on hold until the selected solution could be adequately reassessed, and expectations could be better aligned.
In hindsight, an upfront effort of process mapping and requirements definition would have resulted in clear expectations and an appropriate baseline for the scoping stage. This would have increased confidence in the solution, as well as extending the project and avoiding re-work.
2. The Right Implementation Approach for an ERP Project
As mentioned previously in this article, there is a sizeable momentum shift towards cloud-based / hybrid (cloud and on-premise) solutions. Associated with this market trend is also the notion of a more rapid style of solution deployment.
We acknowledge that many cloud-based solutions have been designed and built to provide a lighter implementation footprint by offering tools, techniques and approaches to implement faster and more efficiently. This may be by way of predefined solutions that promote less customisation or by introducing functionality to end users directly, enabling them to control aspects of the solution where developers may have been required previously (e.g. personalisation, adding new fields to screens, writing reports, creating useful data grids, etc).
However, in our view, what has not changed is the legitimacy of client’s business requirements and the need to evaluate solutions based on these. There needs to be a continued, solid and common understanding between the client and implementation partner of the requirements throughout the life of the project.
The key point to consider is that while more tools are available for disposal, the fundamentals of implementing an ERP solution have not really changed. Most of what has been replaced by these accelerator tools are the technical overheads associated with the traditional pure on-premise solutions.
Discussion on whether Agile / Rapid / Templated approaches are more appropriate than more traditional waterfall methodologies, must always be considered in light of the following key questions:
- Are the business requirements clear and agreed upfront?
- Are there checkpoints built into the project to validate that the solution is being built in an integrated manner to achieve the right people and process outcomes on go live?
- Is there a positive working, constructive relationship among the parties?
- Are all parties on the same page, at all times, about the final solution to be implemented?
If any methodology being proposed does not adequately satisfy these key questions, then the circumstances and the methodology may not be suitable to proceed.
One recent example…
In a recent project, an implementation partner for a cloud-based ERP solution was promoting a rapid / agile approach as their prime implementation methodology. However, on completion of a planning and scoping exercise it became evident this approach was not going to be appropriate for this project. The planning and scoping exercise took twice the time to complete due to various misunderstandings relating to the client’s key business requirements. This resulted in numerous iterations of the scoping and requirements document by the implementation partner until everyone was on the same page.
It was quickly realised the implementation partner that was preaching the rapid / agile approach, could not effectively demonstrate their understanding of the client’s key requirements. In some cases, the partner could not even discuss how their solution could address some of the challenges. To acknowledge the client’s concerns, we assisted by re-working the implementation phases, using a waterfall style delivery approach, with clear documentation of requirements, clear solution design documented and agreed, and all subsequent project phases having the right context to deliver a fully integrated ERP solution for go-live.
3. Strong Project Management / Leadership from the Implementation Partner is a Must
ERP implementation partners are not unlike a visit to your GP, where you expect to get an expert in diagnosis, who provides you with clear recommendations, and consistently tracks your progress. Clearly, the GP does not expect you to be an expert in all things medical and thus educates / guides you on your recovery journey.
It is not unreasonable to expect implementation partners to be experts in the art of implementing their own solutions and have a sound understanding of the good practices and good techniques relating to project management. They are not necessarily the solution experts from a technical point of view but should demonstrate high level of accountability and leadership for the project.
One recent example…
On a recent client project, the implementation partner’s project manager was not adequately versed with the requirements of a project manager, placing a large amount of reliance on the client-side project manager to lead the project. This included being mentored by the client-side project manager on good practice implementation approaches and how to deal with project challenges as they occurred. All the while the client is footing the bill. While there is nothing wrong with this as a personal development exercise, the client should not be paying towards the self-improvement for implementation partners. In essence, the client was paying for the implementation partner’s project management role twice.
This contrasts with projects where the implementation partner project manager provides effective leadership during the project by directing and guiding the client-side team, so the client can remain focused on ensuring adequate client resourcing and on meeting the client-side obligations for the project.
4. Data Migration is Never Easy and Should Not be Underestimated
This is one very critical activity in every ERP project that at times gets little planning attention. The scope of this work is not often understood upfront and thus becomes a resource drain and critical path impediment to the success of any project.
The level of support / involvement of implementation partners is often mixed and the full responsibility (and risk) is passed onto the client with only token level of assistance provided from the implementation partner. It is also often not defined where the partner’s effort will be directed in the data migration activities.
The Data Migration journey should start during the planning and scoping phase of any project. Often, this is only covered at a high level with no clear agreement on the overall data migration approach, clarity on roles and responsibilities or understanding of the likely ‘true’ work effort required. As this is a critical path project activity, more rigour is required during planning and scoping, as it needs to be factored into a Project Plan that has a sound base from Day 1.
One recent example…
This was done very successfully on a recent implementation project for an organisation in the real estate industry. In advance of engaging the implementation partner for the planning and scoping phase, the client completed a discovery exercise to understand their full data requirements and what needed to be migrated to the new solution. This involved some effort to collate the information on the relevant data elements, their respective sources and priority to the business for go live.
This level of analysis assisted the planning and scoping sessions greatly with the implementation partner as it provided them full visibility of the data migration requirements of the project. From this, they worked more closely with the client to plan and agree the data migration approach (i.e. what was being migrated and when, and everyone’s roles and responsibilities) having a more realistic view of the data migration requirements for the project and thus a project plan could be developed with a realistic baseline. During this exercise, the role and responsibilities of the implementation partner (and associated effort) were planned down to the data element level to provide confidence that the project budget for data migration was sufficient and could be justified.
5. Adequate Client Resourcing for the Project is Crucial
In a world of limited resources, the key to setting up a project for success is to involve the right client resources for the right amount of time. Who, how much and when are all questions that should be answered during an upfront planning and scoping phase. IT projects don’t just implement themselves and to get the benefits realisation from the project, the business needs to consider putting the best available personnel onto the project. This is particularly true for subject matter experts, who represent the requirements of the business and are able to participate during requirements definition, solution design, solution build verification, testing and possibly even the training of the end users. Providing the right resources and continuity throughout the project is crucial to its success.
The right resourcing from the client side is just as important (if not more so) as the implementation partners resources, and both need to be equally optimal. Specifically, the key client-based resources need to be well versed with not only the current state of the business, but also the intended future state on which the solution will be built. Particularly those resources that are deemed to be the subject matter experts. The personnel assigned also need to have sound base competencies for the role they are performing in the project. If this is a very analytical and spreadsheet-based role (for example, data preparation for migration) then the resource needs to have the appropriate base skills to be effective. Finally, personnel assigned to projects should be suitably motivated and want to be on the project, so the on-boarding process needs to ensure this is a key factor considered when filling roles.
One recent example…
On a recent project that we were involved with, the resources put on the project were not necessarily the subject matter experts from an operational point of view and the level of capability of some did not meet the project role requirements.
The personnel that were the best subject matter experts where either not available due to their operational roles and could not be back-filled, or they held senior positions in the company and for similar reasons could not be assigned to the project for the duration required. This resulted in key processes not being adequately defined to meet the intended future state of the business and thus failed user acceptance during subsequent phases of the project.
In regard to personnel being appropriate for project roles, one of the resources that was being performance managed by the client was assigned to the project to fill a critical role. As it turned out the performance issues continued in the project with impacts to various project activities, including aspects of the live data migration process which resulted in erroneous customer data that needed to be addressed post live.
Conclusion
Often the pressure to “just get on with it”, be it from the company leadership team or vendors / implementation partners positioning more rapid deployment approaches. Or simply to gain competitive advantage over the competition. Sometimes, it can be a combination of all of the above. However, this also tends to inherently mean that project planning and risk mitigation is done on an “as you go” basis.
We draw the analogy to building a new house. Much time is spent upfront ensuring the architecture plans outline what we desire, from which the building companies can then agree on cost and time to build. The engineering drawings are then used to guide the build process to meet the overall architectural requirements. The building is done in a structured way as certain tasks are done before others.
The implementation of ERP solutions, due to their integrated nature, are not too dissimilar, but have a much more significant impact to the business operations and people involved if not done right.
All the above-mentioned implementation considerations should be considered upfront for any ERP project so that all parties involved are comfortable that everything is in place to have a successful ERP implementation project.