The real difference between Support and Implementation.

There have been numerous times over the past few weeks where I've been discussing that there are differing capabilities required dependent upon whether you are acting in the Implementation space or the top end Support space. Let me clarify a little, I'm referring to the difference between your Implementation Solution Architect and Support Level 4. Addressing the issue which has worked it's way up through the support process and tends to land back at the Vendor.

You could state that there is little difference between the ability to resolve an issue within an implementation as compared to within support and to some degree that is true. Although there are a few differences which can be quite fundamental. For example, as a consultant how do you become aware of the issue's existence. When you're within the implementation issues will tend to be driven by the testing cycle, they'll be created as the result of a failed test script and they'll be listed out as defects or bugs, prioritised and assessed for resolution or whether they even need to be resolved at all.

Whereas within the support space issues are much more ad-hoc in nature, they'll not be created via the execution of a script, in fact the method to get to the point of issue may not even be prescribed prior to the issue being discovered. It's not unheard of for an issue to be discovered by a user who hasn't followed the defined business process, they may not even recall how they broke it in the first place or even better you don't have the issue every time the exact same process is executed. You may even find yourself in a position where the issue is deemed not big enough to fix and we'll just continue to perform the cleanup whenever it happens, they're only IT resources after all. If those had have come up during implementation you know they would have been addressed, but not now.

So we now have our issues, be it a list or an incident in isolation. It would be safe to assume that from here on in the approach to issue resolution is identical. To a degree it is but with some key differences which specifically relate to these three items (resources, time and money). While those three items are also quite important to an implementation, within the world of support they are often treated a little differently.

Starting with resources, during an implementation you (should) have access to a project team. Subject matter experts, domain expertise, generally the same team which functionally worked with the customer to put their requirements together. Technically the team who provided the recommendations regarding structure and setup. The key here is that you will generally have a team at your disposal who are currently living and breathing your solution. Your path to root cause and resolution should be greatly enhanced by this as you have all the knowledge you require to hand.

Now let's look at Support. You may, or may not, have been involved in the implementation. Assuming not, you'll start with having to get up to speed. Then we have the team, assuming there is one, that'll be the support team. (Before I go on, having run a few of these teams over the years, love you all dearly). As a general rule ERP Support tends to be a stepping stone into the consulting world, a place to earn your stripes and get to know the product before being cut loose on implementations. As a consequence the support team will also tend to be quite junior with limited customer exposure and often will be quite siloed in their role at this career stage. As a consequence of this the Level 4 Support incident will tend to fall to one, maybe two senior implementation consultants who may or may not have seen the customer before. A little different from getting the team together to assess the issue and it's impact.

Then we move onto time. In an implementation project defect resolution has time allocated to it. Quick note, if you're a Project Manager doing an implementation at the moment and you haven't allowed time for defect resolution then I suggest you rectify that post haste. To put this in perspective I was on an implementation a number of years ago where the day we hit 5,000 defects out of the testing we all went out for team drinks to celebrate. No joke, admittedly it was a very green product and a very large customer but the key here is it shows that the solution is being tested (thoroughly). Never be afraid of finding issues in testing and be really afraid when you don't. Now where was I, oh that's it, within an implementation there is project time allocated to the resolution of defects. Time is only an issue if you cannot work out what the problem is. But even then, depending upon severity, you can have the 'do you really need this to go live' conversation.

Now let's put this in a Support context. Depending upon the type of issue, what is the time allowed for resolution. We're now in the realm of not only SLA's but also of the customer's expectations. Let me explain, one of my recent customers was an international manufacturing and distribution company and it was deemed that if their largest site was out of action for one hour that would cost the business upwards of $100k. Exactly how much do you think they cared about what the SLA was? Here's the real answer about the time allowance difference, often there is none. You need to work at speed and potentially rebuild the engine while the plane is in flight. Meaning the simple answer to the allowable time question is that compared to an allocated amount you tend to have either none or if you're really lucky some, often it's a cost impact conversation. The higher the cost impact of the issue the greater the required speed to resolution.

That's a sweet segue, if I do say so myself. Let's talk about money. What is the monetary impact of a defect discovered in the testing cycle for which the potential of finding defects in the testing cycle has been planned for? Simple answer is not overly high, as it has been planned for and you have budget to cover the investigation and resolution. Now let's look at support, as seen above the monetary cost can be quite substantial, so how does that flow downstream. Assuming you cannot 'prove' it's a bug in the product and keeping in mind that proving this will take time and the clock is ticking. Always remember every hour is $100k and it works quite exponentially from there. So I'm going with, it's a bug and it's frantic, manager calling manager, CEO to CEO. We must assemble a team and investigate this. But we have no time to assemble a team, and a team costs money, which project do we take them from, how long can we afford them to be off that project? Wait a minute, we have a resource, they pick up concepts at speed, rapid resolution, really it's a point in a process why do you need to know the whole thing, it's about a point solution. Oh and there's the broad knowledge base, database, application, client, more than enough to be really dangerous. Not to mention code awareness, in fact that's probably key as this often constitutes all you receive as initial visibility of an issue, a snippet of a debug log or an error log reference.

Now we can return to the original question, Is there a difference between an Implementation Consultant and a BAU Consultant (aka. Level 4)? I believe there is and hope that I've outlined some of those differences above. Is that to say that an Implementation Consultant cannot do Level 4, of course not there is a lot of crossover. In the same vein a Level 4 expert can also implement. The real key differences can be found within solution coverage and the speed they can operate at.

Thank you for reading, until next time.