The last two weeks, we’ve been talking about our approach to creating solutions for our clients. (If you missed the posts, you can find them here and here) As I’d mentioned, a key portion of what we do is to create an IT system – in our case an Asset Management or Supply Chain system. But that is only one part of our “Solution”. When we’re talking about solutions, we’re talking about creating a result that solves our client’s problems.
I know it sounds a little corny, but our experience has shown us that there are other parts of the Solution that will make or break its success. Those parts are the Definition and Transition efforts of our Solutions.
- Definition: You need to understand the problem to effectively create a solution.
- Transition: A Solution will never solve any problems unless it is successfully transitioned into productive use.
Last week, we focused on Definition. This week, we’ll focus on the Transition side.
Transition is all about preparing for a strong finish. Everything in your project could have been done thoroughly and perfectly. All of that effort could have produced the best IT system possible. But it will all be wasted if Transition is cut short – or worse, skipped.
Transition is all about education and ownership and it starts during the Definition work of the Solution. During Definition, you’re not only capturing information from a system perspective – but you’re also looking at the people side. Who is going to be using the system (when/where/how)? Who will “own” the system (update/troubleshoot/maintain)? These are the two main camps of Users that will determine how successful your Solution really is. Because if they don’t use the system the way it is intended – or at all – the overall Solution will fail.
The general approach for both groups of users is pretty much the same – and it all surrounds communication (what doesn’t, really?).
First, we crawl…
Like I said earlier, Transition really starts during the Definition work while we’re learning about the Users and Owners of the anticipated system. Transition also continues during the development process through communication.
One of the most common traits we all come across is resistance to change. Resistances – or even fear – with change can, at the very least interfere with solution success. If Users or Owners take their resistance to the point of sabotage – your solution success will be crushed.
So we start early. Beginning in Definition and throughout Development, we start communicating with the Users as to what will be coming. We start soliciting opinions, concerns, ideas – so the teams can start feeling some influence and ownership. This all takes extra time. But if it will enable a more smooth system launch – it is definitely worth it.
Then we walk….
Depending on the roles, their processes, and the Users/Owners themselves, we start tailoring training. Because we’ve been implementing systems for such a long time, we’ve got some standard approaches (classroom, web-based, 1:1) – but they all come down to delivering the training content in a way that will be best received by the student.
Our content follows the Talk-Demo-Do-Repeat formula. Not revolutionary, but effective.
- Talk – Tell the students about a function, why it was built that way, how they will use it
- Demo – Show them how it’s done
- Do – Have them perform the function in an environment that is as close as possible to what production will look like
- Repeat – Go through it again….and again….and again….until you can see they understand
Many times, we’ll take some of these students, especially those that have been identified to be leads, and fold them into the testing process so that they really get to know the system. Taking the time to make sure that they are familiar with the system is an investment. It does take people away from their jobs for a little while. But a well-trained staff can make all the difference when a system is implemented.
Then we run….
Go live: two words that can simultaneously strike fear and excitement in the heart of any system administrator or owner. Once everyone is trained, everything is tested – we go live into production use. But effective transition can’t stop there. Seriously – when was the last time that you turned ANYTHING on and it worked flawlessly from the start?
Everything needs to be maintained. Users will forget things. Scenarios will come up that only occur once every X years that no one remembered to talk about during Definition. This is just reality. So Transition also needs to address what happens after go-live.
At this stage, our focus is making sure that the Owners of the solution have everything that they need in order to maintain the system and support their users. So in addition to training, we create a battery of reference materials that they can go to when they need help. Some of these are detailed guides for those Once-in-a-While problems. Some are Cheat Sheets. Some are online references.
The other thing that we do is make sure that we’ve constructed a support plan with the client. This starts with creating the procedures about how to handle issues as they happen, how to escalate them internally and when to contact us. If we’ve done Transition right, you’ll be able to run your system on your own. But everyone needs a little backup sometimes – and that’s where your support plan should come in.
Finally, the results….
Like the Definition work I talked about last week, this may seem like a lot of time and effort in the overall scope of a solution. But the cost of a failed implementation starts with additional time and resources needed to get everything on course. Then are likely costs on missed production work. And finally, there are the negative experiences of the Users that need to be overcome – which can take months – and slow recovery.
Again, the whole goal in creating a Solution is to ultimately solve a problem. The ripple effect from that is a happy, reference-able client, who we’ll hopefully maintain a relationship with for years to come. We get push-back all the time about the investment that is needed for a successful Definition and Transition effort. But the money saved and the frustration and headaches avoided will always make those investments worth it in the end.
Trust me.
What has your experience been in Transitions? Or any part of your Solution approach? I’d love to hear what you’ve experienced.
