Love me Tender
- Patrick Bolger
- Jan 22, 2019
Although Elvis Presley and Vera Matson were given the credit, the principal writer of “Love me tender” was Ken Darby. At the time, Elvis’ publishing deal demanded that writers concede 50% of the credit for the song if they wanted Presley to record it. When asked why he credited his wife, Vera Matson as the co-writer, Darby responded… “because she didn’t write it either.”
This blog was inspired by a post from James Gander on the Back2ITSM Facebook group. James’ original post was making a different point; that vendors sometimes don’t make it easy for people to invite them to bid in a selection process. The post took on a life of its own, with some insightful comments explaining that tender documents are often poorly constructed. My (rather long) comment in response to this post on Back2 ITSM is copied below …
Over the last twenty years, I have personally seen hundreds of PQQ’s, RFI’s and RFP’s. On at least a dozen occasions, I’ve seen the same tender document from different organizations, where the name has been changed, but the content is the same. On the one hand, it’s a relief to know that the response won’t be hard work, but on the other, there’s a sense of real disappointment, because vendors want to understand the challenges that organizations are facing and whether our solutions can make a difference. If that information is missing from the tender, vendors must go through the motions and reply to the tender, in the hope that we can tease out the information we need, should we get through to the next phase in the selection process.
Responding to tenders is resource-intensive, time-consuming and expensive exercise, so if the tender looks like it’s been written with a specific vendor in mind (which happens frequently), it may make commercial sense to withdraw early. Although few vendors will complain about the quantity of RFP’s they receive, they will justifiably moan about the quality.
In my experience, the most common mistake is that most tender documents focus extensively on ITIL® process adoption. They describe the IT infrastructure, the support organization structure, and page after page of process requirements. However, they fail to explain the challenges the IT organization is facing, or the outcomes that are needed to deliver value to their customers.
Vendors want to sell you software, but it’s not just about making the sale, because bad business is expensive. If the RFP has not helped the vendor to understand real challenges, they will struggle to deliver, the customer won’t be happy, and the vendors reputation suffers. If the vendor can identify, early on, that they can’t provide a good match for your requirements, they will walk away. A well-crafted tender document allows both parties to recognize this, and part company, before everyone wastes time and money.
Occasionally, a tender document sticks out like a sore thumb, because it fully describes the current state of service management within the organization, provides real clarity about the business challenges that need to be addressed, and describes the desired outcomes from implementing a new tool. They reek of a service management team that understands their customers and the improvements that must be made to deliver value to them. These tender documents are as rare, but when you find them, they're a pleasure to respond to. I feel a blog coming on…
ITIL® all end in tears
Although tools vary in the ways they deliver functionality to support ITIL® I would go as far as to say that modern ITSM tools deliver more ITIL® capabilities that the average IT organization will deploy in a lifetime. Buying for the future is not a sensible justification for specifying the need to support 15 ITIL® processes if your organization is struggling to cope with 5. A tool will not change the culture of your organization, and unless you set realistic expectations about what can be achieved, within a sensible timeframe, you will end up with a tool that is overly-complex, expensive to maintain, and with lots of functionality that never gets used.
A tools ability to support ITIL®, or any other framework, provides no guarantee that it will improve service quality or deliver value to customers. In fact, it frequently has the opposite effect. Too much emphasis on IT process adoption draws attention away from the customer experience and the issues that have an impact on the business. This isn’t good for the service management organization, its customers, or for the vendor.
Some time ago I wrote a Smart Insight Guide “Essential considerations before selecting your next service desk tool” which delves into this topic in more detail. It has been downloaded more times than any other Smart Guide on our website, so hopefully the message will eventually get through. Sadly though, we still see far too many IT organizations determining their shortlists based on where a vendor dot appears on a Magic Quadrant.
Put the effort in up front
Regardless of the sources you use to do your research, or which vendors make your shortlist, there is no better way to mitigate risk than by trialling the tool in your environment, with your data and processes. This approach works because the IT organization gets to use the tool - for real - while developing an understanding of what the vendor will be like as a partner. It works for the vendor too, as requirements become crystal clear (in a way that cannot be specified within a tender document) when the tool is being trialled.
I could write volumes about the issues with tenders and RFP’s as procurement tools, but the IT Skeptic, Rob England (inspired by the same post on the Back2ITSM Facebook group) has saved me the trouble, by capturing the main issues on his blog. Rob says, “RFPs are easy to mock as a procurement tool. They are an inefficient and ineffective way to buy anything.”
As I explained above, well-crafted tenders are a pleasure to respond to, but they’re rare. Crafting such a document takes significant work, but if your procurement rules demand a formal selection process, it’s worth the effort. If you use a tender template created by someone else, you will fail to communicate the challenges you need to solve and will end up choosing a tool based on features. When the new tool is implemented, the initial focus on service improvement will make things better, but only for a short time. Once the tool has bedded in, the focus on improvement usually stops. Mediocrity takes over, the tool gets blamed and the whole cycle is repeated, without any attention paid to the lessons learned from the previous experience.
Consider the advice in the Smart Guide, put the effort in up front, and trial the tool. It’s the best way to ensure that you’ll get a tool that’s right for your organization, and a vendor that you’ll be happy with as a partner.