Enterprise Software Implementations – Some Common Missing Links

After many years of leading many enterprise software implementations, I have seen some common missing links from the implementation process that prevent companies from achieving full value quickly. Often times, the focus is on the cost and when a system can Go Live (timeline). In fact, the better area to focus upon is when will the organization be functional on the new software and the capabilities it brings to the organization to achieve full value for their investment. The intent here is not to provide an exhaustive list but hit on three of the most common missing links that can have the biggest impacts.

The photo above is a picture of Turkey Ball, a game you will find in many youth camps. Like an enterprise software project, the ball is bigger than one person can handle on their own. It’s only if the team works together that they can keep the ball from hitting the ground. The game consists of four teams, each of which is trying to keep the ball from hitting the ground in their area and getting it to hit the ground in another team’s area. If that sounds like your enterprise software projects, read on.

System Ownership
Accepting system ownership sooner rather than later will improve your time to value. System ownership translates to engagement for the goals of the effort. Most times, clients see system ownership starting once the implementation is complete and the system goes live. Up to that point, the most recurring view is that the client is a stakeholder but not owner. However, clients that embrace ownership once the project begins will have a much quicker time to value.

While there was more than one client that showed system ownership early in the process over the years, one really stands out to me. Even in the planning stages, their project lead showed exceptional ownership and engagement which traversed across their team under his leadership. I remember sitting in some requirements sessions to assist with developing the evolving solution vision and being impressed with their level of ownership of the solution. It was a complete bi-directional exchange of information and ideas between the people. From ensuring their support staff was engaged in the project so that once they went live they would be well equipped to get immediate value, looking for other groups they could help by utilizing the software capabilities, and teaming with the solution consultants, they showed exceptional ownership and engagement at all times. I was talking 1:1 with the project lead after that and remarked that their level of ownership was beyond what is normally seen. He gave me a confused look and said something like, we already bought the software and own it, why wouldn’t we act like an owner of it. While he was right, so many implementations miss the mark in this area and so many projects miss hitting the ownership stage early on.

This contrasts with clients that wait on exhibiting system ownership once the system goes live. The most common themes in these engagements are longer cycles for: requirements, design, and UAT because delivering the solution is not ‘their’ problem, it is the problem of the provider. What is typically seen is in these type of engagements is that problems manifest during UAT. Significant problems can trigger requirements updates, re-design, re-configuration/development which all mean longer time to value. That is significant re-work to fix problems that could have been prevented with proper ownership and engagement earlier in the process not to mention additional costs via change orders which can make your previously looking ‘cheap’ project start looking much more expensive quickly.

“Coming together is a beginning; keeping together is progress; working together is success.”
- Henry Ford

Change Management
I would venture to guess this is the most often missed element to implementing enterprise software. If I had to put a number to it, I would say that 75% of implementations miss the mark here. While we always discussed it, it never seemed to garner enough attention to get much action.

To be truly effective, change management has to have strong internal support. Having outside forces coming in saying things are going to be great, this software is the best, etc. don’t always have the level of credibility as internal champions. I recall one instance talking to a future user that shared, “You are the third company that has come in to attempt to deploy a solution.” While we did successfully deploy and stick, that information was vital. It conveyed that there were challenges to deploying at that company, and we came in with little credibility because the expectation was that we would be the third failure.

One of the best examples from that 25% that got change management right was with a very large technology firm. They didn’t want the system to be quietly deployed, they wanted to go out to the users loud and proud to get them ready for the change. Using their internal social media platform, they did the following steps:
1) Rebranding of the system – They held a contest to name the system. They chose to not use our name but THEIR name. They owned it and started transferring some of that ownership to the users by getting them engaged in naming the system.
2) Regular updates on the project progress – They let the users know how things were going with the project. This is a scary thing. Good or bad, you’ve got to let the future users know how things are progressing.
3) Updates from the CMO – This was important because it laid out the vision of what business problem was being solved for the users and the vision for the company with the solution. Executive support is a great thing when done correctly. They can convey purpose and goals in a credible manner and ensure accountability for what the users should expect from the system and what the users need to do with the system once it is deployed.

“The world hates change, yet it is the only thing that has brought progress.”
- Charles Kettering

End User Adoption
The first two missing links can contribute to the success or failure of user adoption, but there can be more factors involved. It’s a basic premise to begin with the end in mind. For enterprise software deployments, the end is user adoption. Without it, regardless of how perfectly the project went, such as on-time and on-budget, etc., the project fails.

The focus of enterprise software project tends to center around: cost (definitely important to both parties), timeline (no doubt, it’s important to understand the ‘when’), and resources (yes, you may have to delay some other initiatives depending on your resource level). All important things to consider, but in the end, if user adoption is non-existent, lagging, or spotty, then the investment will have a much longer window for the return on investment if at all.

Both of the previous examples drove user adoption. In the ownership example, the users were hearing from their teammates what was coming and what could be. Those directly involved with the project worked to understand the capabilities of the software and how it could fulfill the immediate need as well as future needs. In the change management example, the users heard from multiple sources including the CMO how they were going to evolve from today to tomorrow. The common theme was regardless of whether or not the users were immediately involved with the project, they were being prepared for what was coming, why it was important, and how it would help the business move forward. That is, the why for the greater good.

I would be remiss if I didn’t mention training when discussing end user adoption. Everyone knows how vital it is to train people on new technology, yet, some still lag. There are a myriad of options now when it comes to training, and, in the end, it sometimes depends on the client culture for what will be the most effective. The important thing in this context is to ensure that you execute training according to a plan tailored for your environment and that you look at that plan early in the process rather than after UAT when you are fast approaching the system Go Live. I’ll leave more detailed conversations regarding training to my colleagues that practice in that area.

“The first step toward change is awareness. The second step is acceptance.”
- Nathaniel Branden

Summary
As you went through the three missing links of system ownership, change management, and end user adoption, you will probably thinking they are fairly obvious. I don’t disagree, but in context of the whole effort, we suffer from the shiny object syndrome. The shiny objects for an enterprise software project are cost, time, and resource needs. These all denote aversions to negative things such as too much money, too much time, and too many resources. If we flip that around to focus on the time to value and truly understand what the value is of the solution, then we can frame the effort into a benefit realization and attainment versus minimizing cost, time, and resources. We are seeing some movement to this mentality as methodologies such as agile start gaining traction.  That is, incremental benefits and value over time versus one big bang.

In the end, we are human and will always want things better, faster, and cheaper; however, if we don’t honestly evaluate a situation and look at the most pragmatic paths to get to the end goals while holistically looking at what is needed to get there, we could be creating a difficult situation. It’s like the sign I saw outside of a CPA’s office one time. Taxes done here! CHEAP, FAST, ACCURATE. Pick any two.