When you’re implementing an enterprise resource planning solution for the first time, it often leads to a realisation of the power and potential of the system in your environment which perhaps wasn’t obvious at the outset. In turn, this can lead to requests to add more functions and features than were initially agreed and signed off at the start of the project. Why not, after all, since you’re busy with the implementation anyway?
Plenty of reasons.
Scope creep is almost always a bad idea for everyone involved. It can derail the project, lead to arguments around cost and deliverables and even become a major cause of failure. And that’s something everyone wants to avoid, as ERP project failure is ugly. And expensive (for all concerned).
It is also why, at Verde, we have a Project Management Office, an assurance of price, scope and definitions, and a commitment to clear communication as part of our customer intimate approach.
This, it must be pointed out, is not to say that variances are out of the question; with complex projects, ‘seeing the future’ is impossible and a variance isn’t the same thing as altered scope.
Let’s have a quick look at the causes for scope creep. The major ones are poor requirements analysis, a failure to involve users early enough, an underestimation of complexity, and a lack of change control.
Quite frankly, when dealing with an experienced ERP solution provider, none of these issues should crop up, because as a partner, it is our duty to make sure you are aware of, and together we have taken care of, these potential issues.
The one which is most likely to rear its head is sometimes called ‘gold plating’. This can come from your implementation partner or it can come from your own people’s enthusiasm as you increasingly realise what the ERP system is capable of. Add some imagination, and you might start to see multiple new possibilities for business improvement, process acceleration or even digitisation of previously manual tasks.
A bunch of additional new features and functions start making their way into the project plan in the belief it can add value or improve the agreed-upon deliverables in the initial project plan.
Right now, we’ll say don’t dampen that enthusiasm. And don’t let go of those ideas. But do discuss them with us, and if agreed, expect them to be reflected in formal changes to the original scope, which will have cost and time implications.
As experienced implementers, we’ll advise you on what is and what isn’t possible. We’ll also advise you of the increased risks (there will almost always be increased risks), costs and timeframes. We’ll even, in some cases, advise you not to make any changes to the present scope, and to consider implementing any ideas or additional developments at a later stage as a separate project. After all, you need to walk before you can run, and too much too soon can trip you up.
And, through our PMO, we’ll be sure that there will be no gold plating from our side, but a strict adherence to the project deliverables.
Combating scope creep is great example of why an ERP project is a partnership. There are responsibilities on both sides and one of those responsibilities is vigilance that the agreed project plan is adhered to, that any changes, updates or variances are clearly discussed and agreed upon, and that the scope doesn’t change unless there is very good reason for it.
