[Originally posted on my HiveTechHR blog here]
One thing I’ve learned in 20+ years of systems work is that implementations tend to suck…for everyone involved. There’s no sense in sugar-coating it for those about to embark on one – that just sets them up for months of dashed dreams. However…so as not to present all doom and gloom, you may want to read on to find out the best way to mitigate the forecast of a high chance of pain.
Before we go there, of course there are exceptions to horrible implementations. A ridiculously amazing project manager supported by a super diligent team can get through them on time and on budget…sometimes.
And why does it even matter other than the obvious time/budget impact? Because fully or even partially failed implementations can lead to:
- Turnover, both voluntary and involuntary, of those who suffer through the process
- Poor system adoption, because typically change management is the first thing to be sacrificed when an implementation starts to go off the rails
- Damaged reputation of the system vendor, which in turn damages the internal reputation of the purchasing company
So, now that I’ve presented how things can get royally screwed up, what can be done about it?
First, let’s introduce a player into the mix.
The client partner sits smack dab in the middle of the project. Their role can cover the various aspects of project management and product expertise. They can be one or several people.
Here are specific examples I’ve seen over the years of when client implementations were challenged by either not having a client partner, not having the right client partner or not having the right balance of all 3 players. These may challenge your attention span, so skip ahead if they don’t interest you.
- No third party client partner: A company in Westchester County, NY, didn’t have a client partner. They also had a propensity to ask for customizations instead of adapting their current processes to the software. They had nobody to explain the risks of massive customization, and it seemed to be in the vendor’s interest to take their money for the customizations. Several years and a lawsuit later, it was clear that there needed to be an experienced 3rd party in the middle helping them with decision-making (witnessed as an implementation resource on the vendor’s team)
- Bad third party client partner: Many third parties are more than happy to drive a wedge between the client and the vendor, thereby creating more work for themselves. At one NYC insurance company, one particular third party began that process from the very beginning of the implementation. By the midpoint they had the client battling the vendor. By the end – which took months longer than planned – and the third party consultant was eventually removed from the project and identified as the main source of the delays and overruns (witnessed as the vendor PM).
- No third party, “successful” implementation: So many implementations are successful in terms of getting to the finish line and having a finished product. Where they are not successful is in all ways that meaningfully impact the client project team. One client on the West half of the country locked themselves in a “war room” literally for over a year, eventually losing several team members as a result. Another team in New Jersey was so burned out by the Go Live that they didn’t have the energy to focus on user adoption and the product took 6 months before it achieved any kind of usage by managers and employees.
- No third party, no interfaces, incomplete or incorrect data: A manufacturing company in TX, who we started working with post-implementation, hadn’t included a single interface in their implementation because “the vendor didn’t seem to think it was a priority for them.” Interfaces are example of those hard things in an implementation that take a ton of expertise and effort by the client to bring them to fruition. You have to push the vendor and the carrier/provider. You have to test. You have to remind everyone of the pain of doing this work manually post go-live. In regards to data, the client hadn’t brought in much of the ancillary data they wanted, for example performance review information. They had also identified an alarming amount of errors in their benefits data, which we were tasked to clean up (witnessed as the client partner brought in after the implementation had “finished”).
What you’ll see above is that the first key to success is having a client partner, but that alone doesn’t solve things. They need certain intangibles, namely to:
- Be experts
- Be impartial
- Be a consistent positive influence on the project
That last bit is underlined because it’s a role that nobody wants, and human nature is to complain and drive a wedge between people and entities.
The net result of including the right client partner in your process is the protection of the investment you are making in:
- the new software
- the money you’re spending on vendor implementation services, and
- the time your internal resources would have spent on the process (and away from their day jobs)
It’s a value-add that I’ve recognized over time, and have begun to offer as a service through my company. Whether you use my firm or another, if you’re embarking on an implementation I highly suggest you look into the role. Otherwise the chance of pain might go to 95%.