What does “fit for use” mean? BusinessDictionary.com defines “fitness for use” as “the effectiveness of a design, manufacturing method, and support process employed in delivering a good, system, or service that fits a customer’s defined purpose, under anticipated or specified operational conditions.” Whereas, ITIL defines “fit for use” as warranty, or “an assurance that a product or service will meet its agreed requirements.”
But who defines those requirements? Who specifies the operational conditions? More often than not, it’s departmental managers defining solution requirements and operational conditions – not the people (who IT typically calls “end users”) that are doing the work.
Defining requirements and “fit for use”
Often the solutions designed and delivered by IT look fantastic – on paper. Defined testing went well, and the solution delivers the results that the business (departmental managers) wanted.
Except that no one included the users. No one asked the users. No one considered the impact of the solution on the users.
Do users even matter? Well, yes. Users do matter.
Users have to use the solutions provided by IT. And users have a job to do. Users have to get things done in the most practical way possible. It’s these people that are often forgotten or overlooked when IT develops a new solution.
But, at the end of the day, isn’t it the user that actually determines “fit for use”?
A story of a (CEO) user
At a recent IT service management (ITSM) conference, I happened to meet John, the CEO of a small group of franchised fast-casual restaurants.
Our meeting was not the result of a networking event during the conference. Our meeting was a result of my having an empty seat beside me in the crowded in-hotel coffee shop, and John asking if he could join me. After learning that I was in an IT-related profession, John began to share with me some of his frustrations being a user of solutions provided by a corporate IT organization.
The fast-casual restaurant business is a highly competitive environment. There is a growing emphasis on become “more digital.” Customers are demanding that restaurants have a digital presence. But John soon learned that digital presence comes with a price. For example, John shared that digitally-based delivery services want commissions of 25-30% on each sale. This presents a challenge. According to John, the margins in the fast-casual restaurant sector are typically 5 – 15%, which doesn’t leave much room to pay for delivery commissions.
The corporate organization recognized the need to digitize to drive efficiencies and provide a better customer experience. But as a franchisee, John complained that his restaurants are expected to just implement and use solutions provided by the corporate IT organization yet had no voice in what those solutions were and them being “fit for use.” Too often, those solutions from “corporate” were too expensive for the value delivered. And those solutions took too long to get from conception to implementation. Plus, they often “missed the target.”
John shared a couple of recent examples when those “corporate solutions” were not solutions for the user:
- WiFi for restaurant customers. A new WiFi solution, complete with a couple of wireless access points, was sent by corporate to each of his restaurants. But the access points were too difficult to configure, nor did they provide adequate coverage within his restaurants in many cases. Never mind that John’s restaurants were expected to arrange for and bear the cost of their own internet service, which was not being provided by the corporate organization. John scrapped the corporate-provided WiFi solution and implemented some simple-to-configure, easy-to-install wireless access points – which provided a better service and saved money.
- Cooler monitors. To ensure the safe storage of foods used by the restaurants, corporate decided upon a standardized cooler monitoring system. This system would provide alerts to restaurant managers via their smartphones should a cooler’s temperature exceed a defined threshold. The solution required the use of sensors that cost $350 each – the cost of which each restaurant was expected to bear. John found functionally-equivalent sensors that cost only $35 each. The only downside to the less expensive sensors? He would have to replace the sensors every 12-18 months. “So what if I have to throw them away after 12 months?” asked John. “I can buy 10 of them for the cost of one of the sensors dictated by corporate.”
The importance of “fit for use”
John’s story only reinforces that while a solution may be technically-sound and “fit for purpose,” value cannot be realized if those solutions are not also “fit for use.”
Value is really a perception – and whether a solution is “fit for use” is the foremost part of that perception. Furthermore, I would argue that it is the user that is the ultimate judge of “fit for use.” If a solution is too expensive, or too difficult to use, or just doesn’t deliver a complete solution, the perception of the user will be that the solution does not provide value. If the solution doesn’t help make the user’s job easier or protect the user from harm, the user will perceive that there is no value in the solution.
And the user will look elsewhere for solutions.
Four things that ensure “fit for use”
Don’t overlook the “fit for use” side of the value equation. Here are four things that will ensure your solution is “fit for use”:
- Prior to designing the solution, capture the Voice of the Customer (VoC). One Lean IT definition of “customer” is the recipient of the outcome from a solution (or in the context of this article, the “user”). Capture the VoC before developing the solution so you can deliver solutions that work for both the business (from a cost perspective) as well as the user (from a usability perspective). There’s two other benefits of capturing the user “voice” as well: users will feel that they’ve contributed to the solution and will work to make the solution a success.
- Go to the Gemba – before and after. In Lean terms, the “Gemba” is the place where work occurs. By visiting the Gemba before developing a solution, you can fully appreciate and understand the actual situation and challenges. After implementing the solution, visit the Gemba again to understand if the solution actually addressed those challenges. Visiting the Gemba also builds mutual respect and trust.
- Take an Agile approach to solution delivery. Taking an Agile approach to solution delivery means that you break complex or longer duration projects into smaller units of work, and potentially release those units of work more frequently. By taking an Agile approach, not only will you reduce the complexity of testing and validation, but you can uncover errors and issues sooner and be able to “course correct” – which saves money and results in a solution more “fit for use.”
- Solutions must include training and communication. Training and communication are often overlooked or underdelivered as part of solution (process and tool) implementation. But training and communication are critical, “last mile” deliverables that make a huge difference in how the user perceives the value of a solution. Provide appropriate and relevant training and communication as part of solution delivery so the user understands the business need behind the solution as well as develops the confidence needed to successfully use the solution.
The impact of the user perspective cannot be overstated when it comes to the success or failure of a solution. When developing solutions, don’t limit your engagement to those that are defining business requirements and funding the development of the solution. Get the people that will actually use the solution to ensure that business value is truly realized by ensuring “fit for use.”
Doug Tedder
Doug Tedder is the principal of Tedder Consulting LLC, and is an accomplished and recognized leader who is equally adept in interactions from senior leadership to day-to-day practitioners.
Doug holds numerous industry certifications in disciplines ranging from ITIL, COBIT, Lean IT, DevOps, and Organizational Change Management. An active volunteer within the IT Service Management community, Doug is a frequent speaker and contributor at local industry user group meetings, webinars, and national conventions. Doug is also a member, former president, and current board member for itSMF USA as well a member of HDI.
