If you have worked any amount of time in operations, I'm sure you have witnessed an old problem:
Teams buying new applications to solve process problems, thinking that all they have to do is turn on the application without any additional configuration, and their problems will be solved. Only to find out it doesn't and the application is only used for 10% of its capabilities.
- I've even seen this in many of the ServiceNow deployments I have worked upon, the Out-of-Box configuration was turned on with some light configuration and users grumble that it is not performing how they hoped.
The first step in avoiding being trapped into a new application is:
Understand the outcomes one is trying to achieve?
Why the outcomes can't be achieved with the current method?
How will we evaluate options for improving our methods?
Who are the stakeholders that need the problems with the existing method fixed?
Once you understand the problem, then the solution will come much more easily.
With understanding of the desired future outcomes an architecture review board which asks the following questions can save huge amounts of time and money:
Can the problem be resolved by improving our processes or adding some additional tasks, instead of buying the new application?
Do we already have an application that has the same or similar functionality that could solve our problem or even 80% of our problem, even if we have to do additional configuration work?
Would we only be using a small portion of the new applications functionality?
If the answers to any of the above are Yes, then that should trigger a more in depth Return-on-Investment (ROI) investigation, to determine if the value is really there in the new application to acquire.
The investigation should also focus on if the new application might let you consolidate toolsets and let one retire old applications, and save on licensing costs. The results of the investigation might show one a low return in time and money saved for a high investment, at which point it is time to look for other less expensive solutions.
Even if the results of the ROI investigation are that it makes sense to acquire the new application, the next step before acquisition is to evaluate your processes and problems and determine what the expectations are for the new application and determine what success criteria looks like for all of the stakeholders.
Focus on:
- What Processes need to be updated or retired as the new application launches? How do we remove the "We've always done it this way" resistance to the new software.
- Which teams will be providing operational support to the new application and do they have the training and documentation they need to successfully keep the service running with in the Service Uptime Expectations?
- What are Service Uptime Expecations?
- What training and communication do I need to send to the future users to prepare the organization for the change and let them know how their work is changing.
- How will we measure the burndown of the problem we are trying to fix and also see performance metrics for how much time and money the new application is saving us over the old method.
Steps before a new Application Purchase:
Define the current methods problem
Define what the future method needs to look like to be acceptable
Evaluate existing solution already purchased for solutions
If the purchase is still valuable, evaluate what can be retired by consolidation into the new application.
Operate Lean and mean, with efficient and effective Method analysis!
John Barber
Streamliner Consulting
www.streamlinerconsulting.expert
To be notified about future block posts please follow us on LinkedIn