By Melanie Mondon.

Let me introduce myself. My name is Melanie Mondon and I work with Acmeda, a family business and market leader in high quality window furnishings supplying a global market of manufacturers, distributors and wholesalers.

My current role is Business Systems Analyst and Implementation Project Manager. We have been working closely with Fenwick for several months now, backed by a strong team of consultants working hard to successfully implement our new Microsoft Dynamics system.

I must admit I was a little excited when Fenwick asked me to contribute an article. Not only because it would be my first published work, and Fenwick’s first ever customer article, but also because of the opportunity it represents to write about an implementation from the customer’s side.

The key takeaways

One of the biggest lessons I think I’ve learned is how easy it can be to underestimate the complexity of business processes and requirements. I’ve worked on four ERP implementations now, and of those four, only one was delivered on time and under budget – and that business was dealing with the consequences of a rapid implementation for several years to come. Two of the four were SAP (large and complex in comparison to NAV) and both required several changes to the Go-Live date along with substantial adjustments to the budget. One of them even ran for seven years! NAV hasn’t been quite to that scale although I’ve found several similarities between them.

It seems to be, that the further you progress through an implementation, the more detail and complexity arises. Of course this is a logical progression, though it raises the question – how can this be addressed to avoid timeline and budget creep?

For a business model that should be relatively simple, we at Acmeda seem to have a lot of processes that are complex. In the simplest terms – we buy and sell product. A small amount is manufactured or subcontracted locally; the majority is purchased and distributed. Sounds pretty straightforward right?

It seems the challenge is how to adequately scope and workshop the business requirements thoroughly enough to not only be confident that the budget and timeline are suitable, but also that the business needs will be adequately met by Go-Live. The very nature of many projects requires that cost and timeframe be agreed before any work can start.

The classic case of “scope creep”

At the start of a project, consultants meet with business representatives and discuss the overarching principles to reach agreement around what can be delivered, when, and at what cost. Of course this is necessary for both parties to decide whether a partnership can be forged, whether work can continue, or even whether a different implementation partner needs to be sought.

With the detailed process of workshops and system design documentation following some time after the initial agreement is made, it’s no surprise that many details arise after the fact. Even in the most detailed requirements gathering process there will inevitably be pieces missed – maybe not entire processes but definitely the lower volume complex scenarios that are not often used. They tend to fly under the radar but will take up a disproportionate amount of time to manage.

Perhaps the answer is to build scope into the project for creep to occur. There are statistics that estimate that only 30 – 40% of large scale IT projects are delivered on time and within budget. If there’s a 60 – 70 % chance that something will occur then you should plan for it…right? Surprisingly, none of the projects I’ve worked on have considered this a factor. If I were to be completely honest about the reasons I think are behind the cost creep, the following would be my top picks:

  • Underestimating complexity
  • Inadaquate Resourcing
  • Not Involving the Relevant People
  • Scaling Down from a Complex System to a Simpler One

Next week I’ll look at these in detail and the importance of comparing “apples with apples” when you look at the experiences of other companies that have enjoyed successful implementations. I’ll also tell you how Acmeda fared.

Why does “scope creep”occur?

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 (now Business Central), 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.

Going live

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!