Shaking IT Up: Just When You Thought It Was Safe to Use Your New Software

by Kevin Vandever

You're live! You did it! All the hard work, long hours, and short tempers of the past few months or years are behind you. The high-fives, appreciation dinners, and story telling can commence. It's time to sit back and watch your new system hum and to prepare for the high praise from the user community about how you made their jobs more efficient and enabled the company to turn higher profits. From now on it's easy street, right?

Wrong.

Now the business has to actually use the software to run the business and IT has to support it. The real fun is about to start. No more testing and simulation. The safety net is gone and the hard concrete slab that was always under it stares up at you. This is where you find out what training went on and who really understood that training.

It's much like a couple when they bring their first child into the world. At the hospital, with support from hospital staff, things (often) go rather smoothly. The baby is fed, Mother gets some sleep, and Father is . . . well, who knows what Father is doing, to be honest. At any rate, when the happy family returns home for go-live, all you-know-what hits the proverbial fan. Baby won't sleep, so Mother can't sleep, which all makes Mother tired and maybe just a wee bit cranky. Father has forgotten everything he learned in training and is running around at three in the morning screaming, "Why can't I put together the @#$%ing disposable bottle?" (Hypothetically speaking, of course.) What seemed to run so smoothly at the hospital is utter chaos in the real world.

And so goes many large software implementation projects. And that's what I'm talking about, large implementations. I don't mean an enhancement to a report or the modification of a screen--which can also create turmoil. I am talking about a complete renewal of the primary software package, or packages, that run your business. I have heard it compared to a heart transplant and although I won't pretend a software implementation is as dramatic, and serious, as a heart transplant, I will say that in both cases, a primary portion of what keeps an entity functioning, whether that be a body or a business, is replaced and now has to work together with all the other parts. If not done properly, the results in either case can be death.

That's where the similarities between a heart transplant and a software implementation end. While I'm no expert on heart transplants, I believe that there is only so much one can do to prepare the body for, and support, the transplant. Much of the success is based on the overall health of the body and how well the surgeon performs the surgery. That's not the case with a software implementation. There are plenty of methods to properly prepare the business for the new system and just as many ways to build a support structure to handle even the worst implementations. Because of this, there is more room for error during the implementation. If the business is properly prepared and the support structure is solid, a lousy implementation, although painful, might not hurt the business. On the other hand, if the business is not properly prepared and has not created the appropriate support structure, an average implementation could cripple the business.

Sounds simple enough, eh? Be prepared and craft a solid support structure. Well, that's not the case. The problem is that many times the support and preparation are not taken seriously or, in the worst case, not thought about at all.

The general notion is that if IT support functioned properly before the implementation, it will do so afterward. This philosophy is neither sound nor valid, but nevertheless, it creeps its way into most software implementation projects and starts very early in the project, usually when the first look at implementation consultants is underway.

The primary issue is that the consulting company is dying for the business and the potential client wants to save as much money as possible. The client may say that they want the best consulting company possible, but it's funny that when it gets down to it, the decision is based more on price than on quality and experience. It seems that long-term costs as well as those costs that will develop when the implementation is unsuccessful, are not taken into consideration during the negotiations--everyone's an optimist.

Anyway, during the negotiations, when the consulting costs are hammered out, often what falls through the cracks in order to make the price right are preparation and support. Even then, after everyone realizes the timeline to implement the project is unreachable, certain deliverables magically become "out of scope," which pushes preparation and support even farther down the list--if they were even on the list in the first place. The focus then becomes delivering whatever can be slammed in to make the date and not necessarily the quality of the system or post implementation aftermath.

This may sound crazy, but I've lived it on more than one occasion. The irony is that the very aspects that were ignored during contract negotiations or implementation are the very things that would have eased tensions and ultimately aided greatly in the success of the project.

It may sound as if I am only blaming the consulting companies, but that is not the case. I blame the clients, too. A good negotiator might take advantage of an eager consulting company and parlay a great deal. Later on, the consulting company will feel this pinch and start to show resentment. They will then do whatever they can to wrap up the project as soon as possible so that they can move on to the next under-bid project, leaving the client to fend for themselves or, because the client/consultant relationship has soured so much, negotiate a new agreement with a different consulting company.

So, in fact, it is simple. Prepare the business and craft a solid support structure and you will be fine. But how? Well, you need to train the users and IT department, but training comes in two flavors: Training of the technical folks and business users on the specifics of the new system, and training on how the new system will affect each individual's job. The former is pretty straight-forward and understood but is sometimes underestimated and under-budgeted. The latter crosses over into change management, which is another very important ingredient in a successful implementation. It's not enough to teach the tangible aspects of the system, you have to manage the change in how the company operates. The new system may bring about new responsibilities, remove old responsibilities, or change the current responsibilities. The new system might require more interaction among departments that aren't used to interacting. The point is that there is a lot more to think about than simply training users how to use the new system. You have to train them on how the company will now function. Training and preparing your business is not just a "nice-to-have" item, it is vital and should not be left out of any contract nor should it ever be dismissed as out-of-scope when the project deadlines are in jeopardy.

Post go-live support also falls into the vital category. It can be the in-home hospital for the company with a new system. It can make a good implementation even better and protect a poor implementation from crippling the company. If you have a prepared IT support team, the undocumented features, lack of training, and change management issues are handled more effectively and the business can recover unscathed, or only mildly scathed, on the back end. If you have a support team that is untrained, unprepared, or unmotivated, then turn out the lights, baby, because the party's over.

The good news is that many of the same activities that take place in the preparation phase will also help to prepare your support staff for post implementation. They must be trained on the new system, but they have to receive more training than the user community. It is very frustrating to a user who calls for support only to find out that the support person is just as in the dark as the user. The support staff must also understand the overall effects the system has on the business. They need to understand the change management that took place so they are in line with the business direction. The support team must also understand what was removed from the original scope as well as if and when it will be implemented--which reminds me of a story of a consulting company that claimed that they brought in 100 percent of their projects on time and was selected partially due to this statement.

Well, we made our date alright, but during the project, when things were getting rough and the hours long, a couple of major enhancements were removed from the scope. So, yes, we went live on the original date, but not with what was promised. OK, I digress. A solid support staff should do more than answer questions, perform research, debug and fix issues; they must keep things together when all seems lost. I remember plenty of 3 a.m. phone calls from my team to some lonely person in a manufacturing plant who had no idea what to do and was about to lose his mind only to have things smoothed over by the tired, but calming, voice of someone in IT who knew what to do.

A system implementation is extremely complex and stressful endeavor. Even the successful ones put a major strain on a business and its customers. There is no silver bullet to solving all implementation issues, but proper preparation and the creation of an effective support structure will aid greatly in keeping the werewolf of failure away from your business and increase the odds of you getting some high-fives from the users and attending that appreciation dinner after all.