ERP Deployment Transitions Are Crucial – 3 Things I’ve Learned

ERP deployments are rarely implemented in a “big bang” fashion because the risk of putting the entire corporation in jeopardy at once is simply too great. Therefore, a general practice is to implement the ERP system in waves with several planned go-lives. Each go-live becomes a unique project within the larger implementation program – with a major go-live marking the end of one project and a ceremonial kick-off meeting marking the start of the next.

These lulls in deployment waves are not, however, times during which your team should tune out. Here are 3 essential things I learned, from experience, about deployment transitions.

1. Post deployment depression is real. The bigger the project, the bigger the lull when it is over. I think this happens because, while running on pure adrenaline during a go-live, you don’t even register that your energy has evaporated. When the go-live wave is finally complete, your brain and body beg you to take it easy and prevent you from starting any new, high intensity projects right away by sending the post deployment blues your way. You can’t avoid hitting this slump after reaching a peak, but recognizing that the feeling is real will help you and your core ERP team move past it.

Some ways to deal with this condition quickly include:

• Switch up the roles on your team – a change of job or role will create a natural energy flow.
• Build in a staff holiday to get your launch team out of the office for a week to recharge.
• Inject some new talent into the mix. New teammates equal new energy.

2. Your program brand is essential. Successful program transformation leaders understand that, because people want to associate themselves with a winner, branding their project is critical. After a major go-live, hundreds of problems will arise that will need to be dealt with and the business will likely suffer a bit. Most people don’t like to hurt, so you need to be proactive to ensure pain is not their primary association with your program.

To protect the project brand, work the following into your organization change management effort:

• Start your communication strategy for your future deployment three months before the launch. You need to ensure initial messaging is positive.
• Provide senior executives with talking points detailing that some pain is necessary for gain. Have these senior executives publicly recognize your team’s good work (remember that everybody wants to be associated with a winner).
• Take initiative by publicly explaining how you handle major issues that arise. This will build confidence in users of the next deployment that you are going to take care of them when it is their turn to work with you.
• Don’t leave a mess. Leaving a big problem for a support team to handle will eventually bite you in the butt when business performance starts to flag, prompting senior management to question the overall value of your program.

3. Program budgets are also vulnerable between deployments. You should not be surprised that your implementation consultant will be looking for every opportunity to make an additional buck from the relationship they have built with your team, especially between deployments. Their classic tactic is to say “you have built so much knowledge about your company into our consultants; you should find something for them to do in between waves so you don’t waste this knowledge”. Don’t forget that the consultants working on your current deployment often do not possess the skills and/or talents you will require for the next wave. You will likely be solving different business problems and rolling out already established solutions. Remember it is your job to know how your company works, not your consultant’s.

To avoid unnecessarily lining the pockets of your consultants and blowing your program budget out of control, ensure that you:

• Insist on team and technique productivity gains from your consultants between waves. Teams should consider the ability to leverage already built code, higher off-shore content, and delegating tasks to internal or lower cost local talent.
• Build your staffing model for the next deployment 5-6 months before the next deployment begins. This will help your team avoid getting sentimental about retaining certain consultants and ensure they know when it is time to say goodbye to Accenture, Deloitte, IBM or KPMG. Plan ahead to ensure you know beforehand how many consultants you will need at every step in the implementation.
• Tear the project staffing down to the bone and then rebuild. Retaining a bare minimum of your consultant’s staff will allow you to find potentially lower cost resources and hire experts in the unique problems you will face during your next deployment.

Transitions are just as critical to the success of an ERP program as the high intensity deployment waves that hundreds of books have already been written about. Be sure to stay vigilant in between go-lives by working with an ERP Program Oversight Advisor for analysis on how the project is running and guidance for improving it. In particular, keep an eye out for post deployment wave depression, positive program branding, and covetous consultants to ensure your project lulls do not rock your entire program to sleep.