One of the key questions asked at the beginning of every ERP project I have taken part in is:
HOW SHALL WE GO ABOUT IT?
Since ERP (or MRP) implementations have been around at least since the early ’70s (and probably before) you would have thought that a best-practice approach has been identified by now and thoroughly documented for all to use, but in my experience this is not the case.
In the last 20+ years, I have seen widely varying approaches to ERP implementation ranging from “make-it-up-as-we-go-along” to minutely specified implementations with detailed plans and rigid change control. The question is: what is the right approach?
In my experience, the right approach has a lot to do with getting the balance right between:
- Planning granularity.
- Effective and efficient communication.
- Risk and flexibility.
In the following, I have shared some of my thoughts on the different approaches I am familiar with.
“WE WANT STANDARD!”
However, before I start getting into the meat of my musings, I would like to say a few words about the “We Want Standard” statement that is being uttered at every kick-off on every ERP project ever undertaken. Obviously, using the standard solution as far as possible makes sense for the following reasons:
- Allows future upgrades.
- Reduces number of defects.
- Reduces implementation time.
So, if everyone agrees that a company should take the standard solution and this approach obviously is the most efficient, why do we need a (sometimes) very lengthy analysis and design activity? Would it not make more sense to get straight into the build phase and start configuring the solution and migrating data?
Firstly, all companies are not the same, so some customisation is required to make any solution fit the business. Period! Secondly, often the ERP solution needs to be integrated with a number of other software packages and this requires bespoke development.
Lastly, analysis and design is not only about customisation and development. Analysis and design, conducted properly, should also bring these additional benefits:
- Give key users a thorough understanding of the solution.
- Allow the company to revisit current practices and processes and design future (and hopefully improved) processes based on the new solution.
- Thoroughly plan for and design data migration and cut over.
In my experience, the value of good analysis and design should not be underestimated.
This is, as many of you know, the classic approach to software implementation and dates back to the ’50s. You can read more about it in this Wikipedia article. I would wager that this is how the majority of ERP implementations are being carried out today. Not necessarily in its purest form, but through some variation on the theme.
The cornerstone of the waterfall methodology is the Requirements Specification (The Spec). The Spec is a document that is supposed to document all functional and non-functional requirements for the solution. With The Spec, the customer and supplier are able to perform a User Acceptance Test (UAT) at the end of the implementation and clearly ascertain whether each requirement has been delivered – to spec.
In theory this is a pure and simple way of implementing software. It lends itself nicely to rigid contracts, even fixed price, because all requirements are there for all to see and evaluate. However, requirements are in reality often vague and ambiguous and difficult to test.
The main problems with ERP implementations and the waterfall method, in my experience, are:
- In its purest form, the waterfall approach requires very thorough documentation of requirements.
- The customer is often not able to clearly express all requirements leaving room for gaps and interpretation in the contracts.
- Since 90% of the ERP solution is a standard package, The Spec will inevitably focus on the gaps and not document fit requirements well.
- If The Spec remains unchanged throughout the implementation, the customer is unlikely to end up with the system they want.
Historically, The Spec has been used as the key document for tenders (ITTs, RFPs and RFQs) allowing potential suppliers to tender for the “same” solution. However, experience tells us that tendering for the same solution based on The Spec may still throw up wildly different proposals and offers from suppliers. This, in my experience, is because any written requirement allows for interpretation and assumptions to be made.
Those familiar with the Dynamics SureStep methodology used by partners to implement Microsoft Dynamics AX will probably recognise that this methodology is a (modified) waterfall approach. Many partners have adapted the model to allow for some flexibility to mitigate the weaknesses of the pure waterfall approach.
So, is the waterfall approach still relevant with all its shortcomings? In my view, yes! If applied sensibly with judicious application of change control and some agile elements (during build), it still makes sense and can be a strong tool to govern the relationship between customer and supplier.
The strength of the waterfall approach is its rigid approach to stage-gating. Basically, you cannot move forward in the implementation cycle without agreement on key deliverables. This is sound practice in an ERP implementation. Building on this strength, the waterfall approach can be improved by making it iterative. With an iterative approach, the customer and supplier can agree to go back and revisit a requirement, if it is deemed to be wrong or no longer relevant. This allows some flexibility and gives the customer a better solution at the end of the day.
Using an iterative approach, however, requires strong change management. Revisiting a requirement should be done under change control to ascertain impact on time and economy. Also, a change to a requirement may impact other requirements and design, so cross-functional coordination is necessary.
Poorly managed iterative implementations tend to become chaotic because anything can be questioned at any time. This should not be allowed.
Prototyping, often referred to as a Conference Room Pilot (CRP), is an approach where the analysis and design phases are replaced by hands-on sessions where users and consultants sit together and walk through the business processes using a mock-up of the solution. The solution mock-up often contains partially migrated (master) data to give the user a more comprehensive experience of the future solution.
In my experience, prototyping can be really efficient and beneficial for small-scale implementations where complexity is low and cross-functional coordination is minimal. However, as complexity grows the need to communicate through written documentation becomes more pronounced and forces prototyping to slip back toward an iterative waterfall approach but without the benefits of genuine stage-gating and change control.
In some implementations, I have seen prototyping used for parts of the analysis and design, but within a waterfall framework. This combination can be very powerful.
To make prototyping successful, though, requires a thorough understanding of the company’s business processes upfront by the consultants to allow them to configure the CRP in a meaningful way. Without this thorough process knowledge, prototyping in my view, carries significant risks.
I will not pretend to be an expert on agile software development. My experience with agile as an approach is based on a number of ERP implementations where agile methods and tools were used. Firstly, I would say that applying agile to the customisation and development processes in an implementation works nicely and should be done unless there some compelling reason not to do it.
However, applying agile to analysis, design and configuration is a slightly different matter. For agile to work, a comprehensive product backlog is required, which can be divided into sprints. For analysis, it is often difficult to produce a comprehensive product backlog upfront because, by definition, the analysis should be used to understand what the implementation must deliver ie. create the product backlog.
During design, as the (build phase) product backlog starts building, it becomes clear that with the complexity of ERP, the cross-functional dependencies are significant. As items in one backlog may depend heavily on items in other backlogs it becomes increasingly difficult to prioritise the sprint backlogs. If items start falling behind schedule, prioritisation in other work streams may ground to a halt.
One compelling reason for applying an agile approach is to be able to deliver tangible results more quickly. ERP with its interwoven processes and dependencies is often difficult to deliver in discrete chunks of functionality. Therefore, agile may just become another way of performing ordinary project activity planning.
Another compelling reason for applying an agile approach to an ERP implementation is the ability for the customer to de-prioritise unimportant features. I have seen this work in practice, but in my view there are some prerequisites that need to be in place:
- The customer is willing to accept the financial risks. They pay for the features they prioritise.
- Strong cross-functional communication and coordination is required.
- Users in the work streams need clear guidance on how items in the backlogs can be prioritised.
Apart from selecting the right methodology and approach, organising the work streams can be another challenge and it is important to get it right. The challenge is to create a work stream organisation with the right level of granularity. Often, work streams are constructed using a traditional swim lane approach such as:
However, this may result in some massive work streams such as Order-to-Cash basically encompassing everything the company does except from finance. If the work streams become too granular and focus on smaller process areas, the cross-functional coordination may become too cumbersome. Striking the right balance is essential and very company-specific, so before constructing the work streams thorough assessment and dialogue is required. In a previous blog post, I wrote about using APQC as a framework for organising work streams.
“NO WORRIES, I HAVE A FIXED PRICE CONTRACT!”
Regardless which approach is being taken, I have heard many project owners over time say that they do not care as long as the price is fixed. Personally, I strongly disagree with this viewpoint. What is the benefit of having a fixed price, if the system does not work as intended, at the end of the day? With a fixed price comes a fixed scope and potentially endless quibbling over scope changes.
All this leads me to the question:
If I was to start a new ERP implementation tomorrow, which approach would I take?
Firstly, I would assess the size and complexity of the implementation. Also, I would ascertain my company’s risk appetite and the maturity of my own organisation.
If the implementation was small with relatively little complexity and my company was happy to accept a certain financial risk, I would choose to conduct a scaled-down analysis and design phase (potentially using prototyping) to fix the scope and build a sensible product backlog. Then I would execute the build and deployment phases with an agile approach.
If, on the other hand, the implementation was large and complex, I would frame an iterative waterfall approach to ensure the proper stage-gating with strong governance. With many stakeholders in a project, I believe this is still the most prudent and effective approach. However, if possible, I would certainly want the development carried out using an agile approach.
Lastly, I would like to emphasise that, in my experience, it is important to have a close dialogue with potential suppliers on this. Suppliers have different levels of experience with these approaches and their contractual frameworks may not be well-aligned to them all. It would not be advisable to force a supplier to use an approach they are not familiar with leveraging a misaligned contractual framework.
So, in my view, it all comes down to striking the right balance and combining the right elements.