By Melanie Mondon.
Last week I finished my post by listing my top picks for the reasons that scope creep occurs in an ERP project. This week I will look at these in detail.
Here are my top picks of the reasons I think scope and cost creep occurs:
Underestimating the complexity
It happens – not only to consultants learning about the business processes for the first time but also to the business stakeholders who work with these processes every day. Too often, it’s not until these processes have to be replicated for User Acceptance Testing, or worse, Go-Live, that the full detail really comes to the fore. Be sure to allow more than adequate time for testing then allow some more. You’ll need time to review and fix the issues, and developers and consultants will need scheduled time away from the testing activities to complete programming and configuration tasks. It might sound overly generous, but I think if you plan to test for one week then plan to review, test and fix for one week. Even better is if you can schedule 1-2 days on and 1-2 days off to allow a breather in between for the testers and administrators and keep the momentum going.
Inadequate Resourcing
I’m not talking about a team of consultants here, I’m talking about Subject Matter Experts, Super Users, Project Managers, all the people who work for the business in a full time capacity and are required to make the project successful. Backfilling these roles doesn’t start soon enough (or doesn’t start at all) and people end up juggling the competing demands of an ERP implementation with their daily priorities. All too often the day-to-day business tasks win out, as they are usually of a more immediate nature and customer affecting. Compare that with a Go-Live date some time in the distant future, and perhaps not fully understanding the requirements of a large scale project, it’s easy to put those tasks on the backburner. Expecting that the business will continue to run without additional resources and without impact on the project or the business – well that’s impossible. Backfill the less skilled roles so that experienced team members can support upwards and create time for the project team members. Cancel travel plans and other business projects for managers and key staff – they’ll need to support decision making and resource coordination. Don’t fall into the trap of thinking that they won’t be required because they’re not directly involved. Support your team early on to dedicate the time to make the project successful. People don’t think well or creatively when they’re under stress – give them the time they need and you’ll be surprised at the results.
Not Involving the Relevant People
Middle and senior managers can often be the ones heavily involved in projects, and the mistake can easily be made of summarising a current process, or scoping the to-be process without the important step of consulting those working at the transactional level. It’s easy as a manager to think you know the processes in your team; the reality is that you might be surprised at the complexity and hours involved if you were to sit down and be trained in the detail yourself. Always include the people that process the transactions. Consult, confer, and collaborate. It will take longer to make a decision, but that’s better than taking even longer to change direction once you realise you’ve scoped incorrectly.
Moving from a Complex System to a Simpler System
Consider how your company compares to the other happy customers of your implementation partner. Were their implementations similar to yours? While the Fenwick team were nothing short of fantastic, we did a pretty good job of challenging and stretching them. Acmeda moved from Microsoft Dynamics AX to NAV, a step towards a simpler system that could still manage our requirements. Had we moved from say MYOB, I’m sure it would have been a very different implementation. The business expectations would not have been as great, and the processes would have been less complex. Making the change to a simpler system sounds like a good step towards streamlining your processes, but make sure you’ve compared “apples with apples”. If the majority of case studies you have looked at are stories of taking a step up from a less advanced system but you are going the other way – you may be stretching the product and the partner, so be prepared.
Anyway, we made it. We hit the final deadline of 1st September, after a few timing and budgetary adjustments, and not without some casualties. The most important thing we can do now is review and extrapolate our learning so that we evolve and do even better next time. We’re excited to be where we are and a little exhausted too. It’s never an easy task to completely overhaul a company’s ERP system, though the challenges and rewards make it worthwhile in the end. Once you’ve gotten far enough away from Go-Live and managed to forget how painful it was, you’re ready to do it all again!
