The huge hidden cost of software implementation
The scenario is sadly common. After extensive research, testing, and comparison shopping, a company decides on a new enterprise-level software implementation. It will be a game-changer once they are past the initial cost, time, and resources involved in bringing it onboard. It will change, on a fundamental basis, the way core internal processes are done, managed, and enhanced. A game-changer, easily worth the six figure, or more, investment; once they are past the three month implementation period.
Or, it fails.
Was it the wrong choice? Was the job botched or the training and support inadequate? Was it simply a matter of underestimating time and resources required? It could be any of the above. Or it could be underestimating cultural barriers to adoption.
Human beings will fiercely defend the familiar, the status quo, the way things have always been done. It’s our nature. The failure to understand the depth of this as a blocker to new technology adoption is a common cause for failure, missed deadlines, and wildly underestimated costs. You can’t ignore the existing culture.
In fact, you should probably start with the culture, the way things are done, and the people who do them and manage them. Long before you begin product research or hire consultants.
Never start with technology, always start with people
When I say people I mean users, trainers, IT teams, and migration teams. In other words, the hands-on people who will be using this thing daily, whose jobs may even live within its interfaces. They have to be engaged from day one, which is that point when a problem has been identified that is significant enough to require action.
Properly identifying the problem usually starts with a big picture, something like ‘our ability to manage documentation is out of control and it is affecting our ability to ship product’. This one gets management attention because it hits revenue directly. The problem here is that this is too broad a definition of the underlying issue. Why is it out of control? When did this become an issue? What have we done to try to control it?
Now let’s imagine I go to a creator of this unruly documentation and ask them these questions. And they think a bit and tell me one thing: we have too many versions and it spirals out of control every time we make a change. The underlying issue has appeared, in this example, version control. That’s a start.
Understand the magnitude of the change
The question about ‘what have we done to fix this’ is where the magnitude of the problem is identified because it says the present solution can’t solve the problem. If every reasonable workaround has been tried, then it may be time to change things. But this logic has to be shared and discussed with those who are used to the current solution. They have to be onboard with the fact that a problem exists and the current solution is not working.
We get used to tools and learn their pluses and minuses and then we create workarounds. It’s normal to try to work with the familiar way things have been done. Change, which is what this entire article is about, is hard work. But a lot of the hard work is front-loaded. Everyone will have to hustle, learn, practice, make mistakes, and share their experiences with co-workers. The key is to create an expectation that we are all going to work hard and get frustrated but when the dust clears, life will be better.
It’s the beginning of creating a change team mentality.
Create internal champions
This is key. Management, consultants, and the software vendor need to identify early adopters and bring them into the decision process. They will become internal champions, helping their reluctant co-workers get on board. You may find these people in unexpected places. They could be entry level and not yet reliant on the old ways. They could be a talent that has not found their way yet. Look for those whose questions identify a stronger understanding of the problem you are trying to resolve.
Deal with objections
Great salespeople love objections. Why? Because they identify unseen problems, which can then be addressed. The sales pro takes those objections and either shows how they are resolved or works to determine if they are dealbreakers. Your implementation team must do the same, not treating user objections as negative and unhelpful feedback. This is where using an outside integrator to manage the process may be worthwhile. It is critical that these integrators be independent of the software purchasing process (preferably not a reseller or VAR, because they have a vested interest in the sale, not necessarily the long term success).
Objections should be treated like items on a To Do list. In other words as things to work through, not just attempts to derail the process. If they are attempts to block things, then you have identified another issue: those who simply cannot accept change. It has to be made clear that they need to get onboard or make a very strong case why they will not. If they make that strong case, listen- they may have identified a reason the new solution is not the best choice. Then engage them in finding that best choice. If they just object, to object, you have to deal with it.
Don’t underestimate training requirements and costs
A great training plan and a great training team are key to successful adoption of the new solution. When you assess solutions, their support and training materials are as important as their software. If they have limited resources then they should be able to recommend a third party integrator who can take on the in-person and online team training aspects of the implementation. Yes, this can be expensive, but relative to a failure to succeed overall, they may be worth it.
Plan, plan, plan
Your solution plan should include these major components:
- Buying research, negotiations, and cost decisions. Cost should include all external required resources like training, integrators, required technology, etc.
- User engagement. Subject of this article.
- Migration. Migration of existing data and digital assets to a new system can be the biggest headache you’ll face and is most often underestimated. There are companies whose entire business is managing migrations. Your software vendor may have recommended partners for this.
- Transition period. This is seldom a ‘turn off old system, turn on new system’ situation. You need to build in a redundancy plan to keep business processes running while you transition.
- Post-implementation assessment and improvement plan. You will not get everything right the first time around. As people use the new system there will be bumps on the road and possibly a few washed-out bridges. Be ready to go in and do a second update on all of this, periodically.
Test your migration plan
Software runs data and data runs most businesses these days. Moving your existing data can be incredibly hard, especially when it exists in legacy systems whose file formats and limitations mean information cannot be reformatted in usable ways. I have seen more than one business decide their migration plan was to gradually build an entire new data set while gradually retiring the old data.
In one example, all the company’s technical documentation was in Word docs, many quite old, and their new system had a completely different model for managing information files (DITA). The decision was made to redo and update all their documentation in the new system rather than migrate, because the gains outweighed the work involved. As you may guess, this was an unexpected cost of new software adoption, but one that needs to be considered while planning. Test the migration to identify the issues.
Have success/fail metrics
When you first identified the need for a software change, you identified the fundamental problems that were driving that decision. These become your success/fail metrics. Revisit and update them on a regular basis. These processes are a part of fine-tuning any business.
Worst case scenario: Dump all the work, sink the costs, learn from the experience, and find the right solution
Uh-oh, really? Yes, really. Failure to understand these cultural and business process issues can mean throwing an entire process out the window and moving on. Sometimes users hate a system so much that they ultimately vote by simply working around it. Just make sure this is not just a few irate users creating this problem. If you have to change direction, don’t cling to failure and make sure everyone understands that sunk costs are not recoupable investments.
And a warning about IT departments. Virtually all new enterprise software these days is cloud-based, meaning no servers on-premises. There are very strong reasons why this is far better than managing servers and security issues in-house, however that is not the focus of this article. But you may run into a turf war with existing IT managers who see their control moving out of the business and into the cloud. I have seen this situation cripple companies ability to move forward because an internal expert felt threatened. The best solution is to get them involved early and to make a strong case for why their world must change. Empower them to become part of the implementation team, rather than the man behind the curtain.
Changing the fundamental ways things are done is a big undertaking. Adopting new software is exactly that and underestimating the cultural challenges can be expensive in the long run. Look at the problem from the human perspective and get the humans involved. It can make all the difference.