Meeting Today's ITSM Challenges
Revamping the Federal IT Ecosystem
Accelerating the Digital Transformation with Cloud Computing
Revitalizing IT with Strategic Planning
Collaboration: The Key to Progression
Cletis Earle, CIO, Kaleida Health
ITSM Article - Why ITIL?
Fred Geerken, Senior Director Of It/Ciso, Leprino Foods
Improve Service - Know your business to increase value
Paul Norton, Group Chief Technology Officer, Onesavings Bank
ITSM - The Most Important Acronym in the IT Organization
Mark Szkudlarek, Vice President Information Technology, Novelis
Thank you for Subscribing to CIO Applications Weekly Brief
Lessons Learned in 30 Day Trials of IT Services
Jeff Cann, Chief Strategist and CIO, Encore Electric, Inc
Gartner defines “IT services” as the “application of business and technical expertise to enable organizations … access to information and business processes.” This makes sense to me as a purchaser of IT services over the past 20 years. The challenge is that many suppliers of business software are focused only the technical expertise. In this article, we’ll examine the consequences of this narrow focus and what a purchaser of IT service can do to avoid problems.
We needed a technology-enabled solution
At my company, we are in the process of improving a business process that if we meet our target to improve will save a substantial amount of time and money. In the process of working with a variety of business software suppliers, it is clear that they are not listening carefully enough to our needs.
After our business case was approved, we identified 25 potential suppliers and asked them to participate in our RFI process. We invited them to provide solutions based on our needs identified in the RFI. We attempted to avoid being too directive in our approach, instead hoping that the market would respond with interesting solutions.
Trial by fire
Prior to the RFI, we were clear with each supplier that we would not purchase solely off demonstrations of their solution. Rather, we would conduct a 30 day trial of their solution by a group our employees, configured for our environment. We paid for the time it took for the supplier to configure their IT service so we would have a meaningful trial of our employees using their solution.
A 30 day trial is unusual for most business software suppliers, compared to single-use cloud or SaaS applications, where most offer a free trial. Neither of the two finalists were enthusiastic to provide additional resources to the possibility that they would not land a sale. We countered that our company has never purchased this type of software (and based on prior experiences) we needed our employees use their solutions in real-world situations. We identified a low bar of 5 user stories for the trials.
A 30 day trial is unusual for most business software suppliers, compared to single-use cloud or SaaS applications, where most offer a free trial
This effort proved valuable as the top two suppliers (based on RFI answers and demonstrations) failed in the 30 day trials. Had we purchased either one based solely off a series of demonstrations, we would be stuck – either abandoning the software or trying to “make it work” at the expense of our expected ROI.
Why did the trials fail?
The project team identified 3 pages of lessons learned from failed pilots with the two suppliers. There are three key points that could help both software suppliers understand what customers of IT services expect.
(1) Selling on pain: The account executives of both software suppliers assured us that their solution could be molded to our specific needs within our industry. They were credible in their demonstrations and both are well-established suppliers with many customers.
Sales professionals are taught to identify the pain points of the customer and then demonstrate that their solution solves these pain points. This approach is reasonable but sales professionals are not business analysts. The sales professional rarely has the skills or experiences to ensure that their solution does not introduce unforeseen pain points during implementation.
(2) Close the gap: Selling on pain points creates a gap in understanding for the supplier and the customer. The supplier does not understand the customer’s workflows in detail and nuances of the existing business process. The customer does not understand the supplier’s business software enough to identify gaps.
Neither of these experienced companies identified the gaps for the customer. They did not ask for enough information to understand our current state, our desired end-state and so did not spend much time looking for potential points of friction.
As we tripped across friction points, the suppliers offered work-arounds. Workarounds are usually necessary and acceptable until they lead the solution away from its intended benefits, measured by the ROI. Unfortunately in this case, the workarounds were at the expense of usability by our employees.
(3) Help the customer on board: Both vendors took a similar approach to the configuration of their software solutions. They assigned capable configuration engineers to setup our 30 day trial environments. The approach of the engineers was to understand the basic needs of information and configuration settings. They worked at a most detailed level and did the minimum required to ensure the solution was available for work.
Not only was this inefficient and time-consuming, there was no one from the vendor who could help keep an eye on the overall experience of the employees who would use the solution.
Hopefully, sharing our experience will help both business software suppliers and customers consider our suggestions so that promised benefits of IT services are delivered effectively.