You may think I would have a somewhat biased view on the factors behind a successful deployment of software, but 25 years has given me a good sample to consider and reflect on what ingredients go into that smooth and calm roll out. A quick count up makes 40 full core system implementations.
I believe a successful deployment is made up of a number of key ingredients:
- Leadership
- Engagement
- Flexibility
- Pragmatism
- Diligence
and each must be demonstrated by all parties.
The Vendor knows their software and the Client knows their business. No matter how much pre-sales investigation there is, the nuances and particular traits of the Stakeholder and User teams will only unveil themselves fully when you are up to your eyeballs and in full flow.
The Client knows their team but has little idea of the innerworkings of your software, no matter how many demonstrations and workshops you provide there are assumptions made by the audience which the vendor could never have predicted (in their wildest dreams in some cases!) "you mean you have to put the data in yourself?"
On both sides a collaborative Leadership team is vital, both with the same single goal... "this is going to work". The key word here is collaborative. Gannt charts at the ready will still not provide for the Rumsfeld's unknown unknowns.
In truth, the Vendor has probably done this before, granted a different team, perhaps different scale, different challenges but the milestones are the same and the methodology follows the similar path. The Client might install new software once every 5-8 years maybe longer, persuading the client to follow your lead, respond with information by return, provide everything asked for, when its asked for, and be proactive in learning all they can, is a good position to take as a Client. Oh, and not changing the goal posts without accepting the resulting amendments to budget and time-frame.
I believe a Vendor will know, very early on, whether it is going to be a smooth good deployment, purely by the early style of the engagement. Core systems in the Insurance Industry are not the same as rolling out the latest version of MS Office. They all require careful and tailored set up and configuration. Despite market practitioners belief that they all work the same, or they are "just like any other Broker", or the best of all.... "just want the standard reports" each of the 40 or so deployments I have done, I have found that the Client has operated quite differently from all the others.
This is where flexibility comes in, not just of the Project team but if possible the software too. In a changing market with products presenting new challenges, an excellent weapon in the armoury is a flexible solution that can adapt as the Client needs to adapt. If your software is flexible it helps you as a Vendor to be flexible - "No" is a valid answer, but its great if you can limit its use!
That said there is greater 3rd Party integration and interoperability than ever before. This is where some flexibility gets controlled by outside forces - If you are a London Broker or Lloyd's Coverholder you may be considering the various TOM initiatives. If so there may be standard codes required. You may not be able to have any class of business but only the ones that the central platforms will recognise. Can your software allow you to still have your own list and then map these to a the centrally restricted list?
There will always be one (hopefully not more) fly in the ointment - a disrupter, and not of the positive kind. As a Vendor the last thing you want is to appear a tattletale; going to the Principle and sneaking on the one that isn't pulling their weight, or worse still appears to be proactively de-railing everyone else's best efforts. But deploying all the charm and inclusion tactics in the world can still fall short if someone is really set on causing an issue. There are some big bucks at stake and in some cases people's careers. If someone needs to be put back in line, then alas it can fall to the Vendor to dish the dirt!
But what if that disrupter is one of the stakeholders? Then the Vendor needs those diplomacy skills that Trump's cabinet would treasure! The hearts and minds are a fundamental part of the process. No matter how good you believe your solution, and your team are, you have to earn the trust of the Client and that starts after you have been handed the signed contract.
Pragmatism is needed to consider the features that are needed on day one. After all as a client you decided to engage based on what you saw and investigated the software included. There may be a statement of agreed works to be included at the Live Date, and others for a future date. Often, many items Users want are best revisited once they have got used to the software; once they see the structure of the data and what features the software includes - perhaps a query screen can replace the need for that bespoke report you thought you needed because you had it in your old software.
Another key is not a five-legged camel. Often "engagement" is translated as "inclusion" of all teams. this has thus far not been a factor in my top 10 implementations. What is common is a single or duo team that understand what the Users want, selects what they need and get down and dirty in the software to understand how it works. My two top deployments, one in a State Insurance Company in Africa and one in a mid-sized Lloyd's Broker both had the same common element, a strong owner of the project who stated how it was and what was needed, on both sides a single vessel of communication and coordination, with whom we mirrored an individual for them to partner with.
Now this tactic may not work on large Government, Civil Service or Military Projects, our deployments have ranged from 3 to 200 Users and there are obvious adaptations to make, particularly around training the various teams, but in essence the components remain unchanged. Gone are the days where the ITT/RPI/RFP is the best tool to establish software's potential and suitability for a Client's ambitions - to date I have not read a really good one. It should be far more focused on the Client and supplier teams and the approaches of both parties, how well they are matched and their preparedness to collaborate.
Whatever is being installed, whoever makes up the team, a strong collaborative leadership team with pragmatic and flexible approach within the plan, careful and in depth learning on both sides and a "can do" attitude is definitely my recipe.
