Challenge

Most of you have probably been through an ERP implementation. Do you still wake up in a cold sweat thinking about it? I have heard it likened to a “corporate root canal” – nobody enjoys it at the time, but it should make life less painful in the long run.

I want to give you some insight into a recent successful implementation and one key learning from the project. Maybe your next time “in the chair” will involve less nightmares than previous experiences.

This ERP project was for a biotech company transitioning from clinical to commercial stage. We were asked to take the lead halfway through the project, since the Steering Committee had serious concerns about how it had been managed to date. 

We were able to get the project back on track, and at the end of the project we were asked  to perform a ““lessons learned” exercise to identify reasons that the project had been continuously delayed versus the original baseline dates (see table below)

As you can see from the table, the significant delays to the project did not occur until the “build” phase.

The reason for this is that deliverables that were supposed to be completed in the discovery and design phases were not truly completed. You can hide the impact of the incomplete deliverables in the earlier phases of the project, but in the build phase, if a solid foundation hasn’t been designed, this is when delays will become visible.

For example, business processes must be defined and have cross-functional alignment early in the design phase. In addition, the functional subject matter experts (SME’s) should all be proficient with their transactions and be capable enough to pass a hands-on test before the build phase begins.

For this project, that was not the case at all. In fact, even at the end of the design phase, business processes had not yet been defined, and SME’s were still lacking a basic understanding of the their transactions. In other words, the build phase began with a very weak foundation – ill-defined business processes and untrained SME’s.

Solution

The way we turned this project around was by increasing the focus on the deliverables. In my opinion, deliverables are the most important section of the project charter. It translates the project objectives into something tangible, and it is the basis for creating the timeline. 

Here are key questions about the deliverables that should be asked before you start your next project:

• Is it clear what “done” looks like? 

We found lots of rework and frustration were created by a lack of clarity in this area. If it is not clearly defined, then it is easy to fool yourself and others that a deliverable is complete when it really is not. 

• Do you know the phase in which the deliverable must be completed? 

When reviewing the status of deliverables at the end of each project phase, unless it is clearly understood what should have been completed, and what completed means, then it is very easy to mistakenly allow the project to pass through the phase-gate. 

• Are deliverables aligned with project objectives?

If you waved a magic wand and all the deliverables were suddenly available, would the project realize its intended benefits, or would something else still me missing. Conversely, are there deliverables not contributing to the project objectives, and so can be removed from the scope.

Results

Immediately after taking charge of the project, we made the following changes:

Clarified requirements for each deliverable to reduce frustration, rework and delays. QA had very specific and rigorous requirements, which were often not understood. It wasn’t until the deliverable got close to the due date, did it become clear that there was misalignment. We changed the process, so that the team had these conversations further upstream before work started on each deliverable.

Held a series of cross functional workshops for each business process such as: Receive to QA Release, internal production control, Item and BOM management etc. The purpose of these workshops was to obtain alignment on the business process design. In addition, they increased accountability and visibility for SME’s, since we frequently performed informal Conference Room Pilots, in which the team was responsible for performing their transactions in sequence.

Removed finished goods supply chain planning from project scope since the company only had 2 active finished goods. The complexity and training required to create an accurate ERP generated finished goods supply chain plan was more than it was worth. The plan could easily continue to be generated in Excel, and then transitioned to ERP in the future. This scope reduction meant that the supply chain team would be ready on time, so it was a critical change.

These changes had an immediate positive impact. Even though accountability was now much higher, team morale improved significantly, because progress had increased exponentially, and everyone appreciated the structure.

When the ERP system was eventually implemented, even though it was late, it was launched with very few hitches, and generally acclaimed by senior executives within the organization, especially the CFO – the project sponsor.