Yeah, you know there’s a whole mess of ‘unofficial’ systems running your business: all those shadow spreadsheets, all those hand-built Access databases, and all that off the record ‘sort-of’ documentation that’s given to new people when they join.
And you know that that mess doesn’t always produce the same numbers at the same time, even if they’re (theoretically) working from the same data.
And you know too that part of that mess is because you’ve got at least a half a dozen copies of the same ‘master’ data floating around out there: just how many different customer information sources do you have?
Your end users don’t know how to find their own answers to day-to-day cost and revenue questions (Quick! Call someone in Finance!)
You can’t consolidate and close your financials quickly enough for your execs.
And you shudder when the CEO talks about acquiring companies and 'folding them in quickly'.
Yes, you’re growing, and that’s good, but you know that your patchwork of systems and data just won’t be able to keep up with that growth.
Let’s not forget that your exec’s understanding of how to put in a new system really isn't very deep, and they really don’t know a gold configuration from their elbow.
On the up side, they do understand - in general, at least - that ‘customizing’ a replacement system is a bad thing to do in general, and that ‘customizations’ must be avoided at all costs (unless we’re talking about the unlikely case where they’ll provide you with competitive advantage - but who gets a competitive advantage from their Finance system?).
The project team gets it: right now there’s a poster hung outside our War Room: it’s a picture of a kitten sitting under a menacing anvil, above dark black letters that say: “For every customization, a kitten dies..."
No you can’t have everything you want at the start, but you’ve got a sort of understanding, sort of supportive executive team.
What you do have is agreement that you’ve outgrown what you have now, a sort-of supportive set of the business case numbers, (even if many of them are a little soft and squishy) for a new system, and an expectation that the new solution should probably be some version of what is generally called (what a terrible name) an ERP.
OK - now what?
Try to push back into the recesses of your mind the ERP horror stories you’ve heard, swallow hard, and call one of the expert ERP implementation partners, right? That’s where you start with these things, don't you?
Nope. At least not yet.
That first call to an implementation partner at the wrong time is one of the big reasons why ERP failure rates are so high.
No, it’s not wrong to be calling an implementation partner (you’re probably going to need one at some point) but it is wrong to call them before you’ve done your homework. And there’s a lot more of that homework to be done than you might think.
Let’s be clear about this: your big project most definitely does not start the day you sign with a partner, and it's the most amateur of amateur mistakes to believe that it does.
Your implementation partner will not - and most definitely should not - be doing everything for you: you don’t want a project like this done for you, and you most certainly don't want it done to you.
There’s much work to be done before you even place a call to a potential partner: much by your organization, and some by the experts that know all the things you have to do and prepare before an implementation partner steps through your door.
Your end goal: to be an excellent, effective, and well-prepared partner to an excellent, effective and well-prepared implementation partner - and if you haven’t done a lot of prep work first, you certainly won’t be, and they probably won’t be either.
No, I’m not suggesting that you need to run through a long and expensive RFP process (if you’re comfortable with a partner and you’ve checked their references thoroughly - note - always, always check references - then save yourself some time and go with them), and I’m certainly not suggesting that you run an expensive comparison of all the options you have for ERPs out there - that’s also complete waste of your time and money.
Let me digress: Oracle? Microsoft? SAP? Fact is you can succeed or fail with any of them, and whether you’re successful or not has very little to do with the software you choose: they’re all good if managed well, they can all be expensive money pits if they aren’t. It really is that simple.
Digression over: back to getting ready to call a potential partner: you have weeks and weeks (and weeks and weeks - we’re talking a good three or four months here) of work to do before an implementation partner arrives.
To start: ask yourself: do you really understand what you’re looking for out of the project ahead of you? Can you list the (objective, measurable) criteria by which you’ll measure success when you’re done? Even if you can, does everyone in your organization agree? Asking and answering these questions can’t wait: Stephen Covey said “start with the end in mind”, and that definitely applies to your project - you should have a very clear idea of what that end looks like before you ask an implementation partner to help you get there.
Here’s a test: do you have the right name for your project (no, not the ‘ERP project’, and no, not ‘the D365 Project’). Does your project name clearly communicate, in business terms, (no technical jargon, no acronyms, no product names) what it is that you really want it to achieve?
So what are the (tangible, objective) measures of success for the project you really don't have a clear and descriptive name for yet? Just how will you know that you’ve been successful? Tough questions that your implementation partner won’t - and shouldn’t be expected to - answer for you.
And what about this whole ‘organizational change management’ thing: have you considered the impact of the changes you anticipate with the project? Have you asked people what they think about your current systems before you start designing a solutions that’ll change them? Are your people ready and wanting a change from your current systems and processes? Finding this stuff out is your job, and it needs to start well before you sign up a partner.
Any potential implementation partner will, of course, be able to provide or recommend someone who knows OCM if you ask them (probably someone from their own organization, or someone who will subcontract to them), but don't ask them: this is a role you almost always want to hire directly and independently: you need the viewpoint of someone who’s not on an implementation partner payroll.
Something else you need to put in place before you sign up a partner: a working governance structure. Have you met with your (very aligned, right?) group of project Accountable Executives (no, not Sponsors - that’s a worthless word), and has your Program Advisory Group (no, not Steering Committee) met and agreed on measures of success already? Have they agreed on how you’re going to be making decisions before your partner comes in and starts asking you to make them?
What about the expected sequence of events for your project, which functionality do you want/need first, and therefore which modules, in what order? Have you run the heat map to figure out where your functional priorities are? You do know that you’re going to have to do some Finance work before anything else, don’t you, regardless of what the heat map says, keeping in mind that just about everything drives a financial transaction, and that all financial transactions lead back to the general ledger...
When he or she arrives, your partner will be on a tight budget that you’ve squeezed them down to (fixed price, I’ll bet, because you think that’s the best way to do these things. Another digression: it probably isn’t), and they can’t afford to wait while you figure out who gets to make what decisions when. And if you take too long figuring it out, they’ll send in a change request for more money, since you caused the delay...
Thinking about money and the cost of delays, let’s talk about the contracts and budget for your project in general, and your implementation partner contract in particular: do you want to negotiate that one on your own? Probably not a good idea...
Remember that your potential partner has probably negotiated dozens of these deals with dozens of clients before you: how many have you negotiated? How many of these deals have your in-house legal people negotiated prior to this one? Probably not very many, since ERPs certainly aren’t your core business. Do your people really know the ins and out and pitfalls of these complex agreements? Do they know as much as your potential partner does? If not, you’re at a disadvantage.
And - as above - what kind of agreement are you negotiating for anyways? Time and material - there are risks and opportunities there, mostly risk on you as the ‘owner’. Fixed Price? Tempting but overly simplistic, and probably not the best answer if you want to get the best result for the best price: what if your potential partner bids low to win the work, but then can’t deliver at the price? What if they ‘fix price’ high to factor in the risk they’re taking? Just how much risk are they factoring in? Do you know how to find out?
Have you considered a risk sharing agreement with your partner? Do you know how a risk sharing agreement could work?
Back to your organizations: what about your staff backfilling plan?
And how are you going to be accounting for costs - the internal (‘brown’ dollars) as well as money out the door (‘green dollars’) that are going to pay for the thing? Has your exec agreed to your approach, and are you set up to track and report accordingly?
So much to do...and so much that needs to be done before you call a partner.
If you’re not quite ready to go (warning: self serving advertisement ahead), I suggest that you call someone to help you get ready - preferably someone who doesn’t have ‘skin in the game’ i.e. won’t profit from your choice of technology solutions or partners, someone who isn’t paid by your potential implementation partner, and someone who doesn’t “just happen to have the team of people you need to implement” standing by...
You need someone independent of an implementation partner, and to some extent, independent of you - someone who should be able to ‘push back’ and tell you what you need to do (and not do) without fear of losing out on your implementation contract.
Bottom line: you need to do a lot of prep work well before you bring in an implementation partner, so that you can be a successful partner in the long run: don’t try to get started before you’re ready to begin.
Ken Hanley M. Eng. (Project Management) does this kind of stuff for a living.
