I had the opportunity this week to work with a potential customer on implementing our asset solution in their organization. The majority of our discussions focused on moving the solution into production – and rightly so! In my two decades of providing automated software solutions, the true measurement of success (in my opinion) is how a solution gets moved into general use – and how it’s used once there.
It seems like the standard approach to evaluating a system or solution starts with reviewing the features of the application. It’s a good start, right? You have to know the system options – especially the specific ones that you’re seeking.
However the irony is that most users only leverage a fraction of application functions. I think in Microsoft Word, the average person uses less than 5% of these. I know I couldn’t tell you what to do with most of the tabs in Word – but I use it daily (guess how this post was written…). But still – you need to know what the system does – so you start there.
The next usual step is to look at the team that would develop and implement the solution and the process that they use. After that, there’s the review of past customer experiences and then the big one – the cost. It’s at this stage that “transition” is on shaky ground.
“Transition” in our world includes testing, training, and delivery. Since these are non-technical activities, they don’t automatically get the respect of development or configuration tasks. Instead, they are frequently viewed as less important – or “nice-to-have” vs. “must-have”. As a result they often get sacrificed in the process of cutting down costs. Or, when they are included, the time they are given frequently gets minimized or eliminated if there are delays in other parts of the project.
Discounting Transition isn’t unusual – for any of us. Think of the last time that you needed to assemble something. Did you read the instructions or toss them aside? Did you watch whatever You Tube video was available or take advantage of the in-store training? Or did you just jump in only returning to those tools once you started the fail/swear/repeat cycle (naturally not admitting to anyone that you had to dig the instructions out of the trash)?
So it’s not really a surprise that these activities aren’t given as much weight when teams look at implementing a solution. But the fact is – they should be weighed very heavily. Most clients we talk with have at least one story about a painful implementation that they eventually struggled their way through to get it working – or worse, they just gave up on that solution all together and shelved it. If your team has to suffer to make it work or they drop it once it’s delivered – then it’s not exactly a glowing story of success.
But I get it. Cost – like the technical side – requires very serious consideration. The challenge is to ensure that a balance is struck between investing in technical requirements – and investing in the services that can get those technical tools smoothly into use in your operations. Because again, the true measure of success is seeing that solution investment effectively working in your environment.
So what does a solid Transition approach look like? While it looks a little different for everyone – the definition begins with understanding the baseline needs for these areas:
Testing: what needs to be exercised to represent how the system will be used in production
Users: what are the needs/limitations/preferences/environment of the users of the system
Ownership: what are the needs of the administrators that will be tasked with owning/managing/expanding the use of the system once it’s in production
The client I was talking to this week has a fairly common situation. They are a subsidiary organization of a central system structure. While they need to follow the requirements of the central system, they have their own team needs too. Further, this subsidiary organization has multiple locations of their own to serve. So the team tasked with implementing their assets solution has to make sure that they meet what corporate requires while providing the tools and support to their distributed team. Now you understand why we talked about Transition in the bulk of our discussion.
In the past, I’ve posted on the need for strong investigation and clear communications with any project – and Transition activities are no exception. Getting Transition right combines multiple dialogs to get a clear picture on environment challenges – people, infrastructure, compliance, etc. It requires mapping our solution into the environmental picture from end-to-end. And finally, it requires taking the time to exercise all of the testing/training/delivery steps to ensure a smooth launch into production use.
The key is to remember that Transition is a “must-have” to truly deliver a successful solution.
What are your Transition successes or horror stories – I’d love to hear both.
