RFx Mistakes, and How Not to Make Them
People can be rather careless when they are spending other people’s money rather than their own – a fact that is one of the key justifications for Software Asset Management. (A quick online search for the term ‘shelfware’ indicates that the problem is endemic across all sectors and all types of software, and the concept of ‘shelfware as a service’ linked to SaaS has been around since at least 2009). When selecting a SAM tool, it is important to develop clear requirements to ensure the implementation of an effective SAM solution.
Effective business cases depend on carefully researchedrequirements
This carelessness with employer funds (“it’s in the budget, so I need to spend it, otherwise I won’t get as much next year”) is reflected in many of the business cases and requirements documents I have seen during my career. Much of what I’ve seen submitted was ‘creative’. The benefits were generally unsubstantiated, and often the same ones as those claimed by other people in other business cases – or ones that had been (repeatedly) claimed in previous years.
My role in the process was to work with end-users to understand the outcomes they were trying to achieve, understand the true business benefits, work out the best solution to the problem and help them to build a valid business case and deliver a successful project. While initially I may not have won any popularity contests, this approach certainly saved the business a lot of wasted effort, time and money – and ended up helping it deliver projects that had real value.
Many of these business cases were flawed from the outset – business requirements were poorly researched and articulated which resulted in solutions being poorly specified and inaccurately costed. And yet the people who submitted the funding requests were insistent that they ‘needed’ these solutions, and that ‘management’ (and accountants) didn’t understand their business.
Management’s view was that the business wants a Rolls-Royce but actually just needs a new Chevy to get them from A to B but were unable to define those needs and were therefore describing what they thought the solution looked like. Time spent helping business users to articulate the required outcomes and making sure that they were clearly understood by the people tasked with coming up with solutions was well-spent in terms of ensuring expectations were aligned. And as people started to see not only success in getting business cases approved, but aslso success in the delivery of the projects, the benefits of taking this approach started to be appreciated.
Somewhat ironically, given that ITAM is concerned with the elimination of waste and driving value from organizational technology investments, many of the RFIs and RFPs I have reviewed as an IT asset manager and then as an analyst suffer from the same problem. This seems to be because people are unclear as to what these documents are supposed to achieve. Poor RFx documents aren’t good for either customers or vendors – customers rarely get what they need when vendors are trying to second-guess what they really want. It also makes the selection process difficult when customers cannot clearly articulate their own needs and hence are unable to compare like with like due to their unstructured approach and over-reliance on vendor sales and marketing information.
Vendors have a responsibility here as well. They need to push back when customers provide them with poor requirements and badly structured response forms and ask for clarification and additional information to allow them to provide a comprehensive response. Responding to, and winning business based on poor quality RFPs can result in poor customer relationships and brand damage when the solution doesn’t live up to customer expectations.
common mistakes
These include:
- Laundry list approach – Ask everyone in the organization who might be interested in the solution what they want from it, stick them in the same document and send it off. I’ve seen at least one of these where the same question was asked six times. I’m amazed any vendors read it to the end, let alone responded.
- Vendor help in compiling the RFP – Getting the vendor whose sales person you like/ marketing appeals most/ has the nicest pens/ buys you the best lunch to ‘help’ you write the requirements or RFX document. There is only one likely outcome of this.
- Not including a template and guidelines for responses – You’ll get responses in different formats, often cut and pasted from marketing material and it will be impossible to compare one proposal with another.
- Failing to mention any prequalification criteria (e.g. financial parameters, certifications etc) that vendors need to meet – You may find your winning/ preferred bid turns out to be disqualified and you end up having to start the selection process again
- Focusing on technology rather than business outcomes – Although some technical detail is necessary, specifying exactly how a solution should work is unhelpful. HOW it works isn’t your concern – the fact that it does (in the context of your environment and desired outcomes) is the important thing. With a service, the focus is even more on outcomes (although it’s a good idea to make sure that there is appropriate technology supporting the service).
- Implementation – Ignoring the fact that implementation, configuration and population of data into a solution are necessary for it to function (and yes, I’ve been in situations where people have complained about a SAM solution not working only to find that it hasn’t been fully implemented let alone configured – and in more than one case no data had been put into it). Most SAM solution RFPs focus primarily on the technical specification, with less than 5% of the content directed at implementation – yet the main reason for dissatisfaction is due to poor implementation and lack of time and effort put into configuration and training.
- Administration – Forgetting to consider the internal resources required to administer the tool and support the processes and activities associated with it. Many organizations develop a SAM solution RFP where they would be better off sourcing a managed service. In some instances, I have spoken to people in organizations who believe they have bought a service when they have only purchased a solution – it is startling how often this happens.
- Context – Solution purchases need to be considered in the context of governance, process and people – there’s no magic solution.
So how do you avoid getting it wrong?
My top tips for an effective SAM solution or service RFP include:
- Business outcomes – Focus on business outcomes and understand what you are trying to achieve. Engage with stakeholders to understand their requirements but keep them focused on outcomes and not on technology.
- Business requirements – Collate all the information and spend time building detailed and coherent business requirements and use these to determine whether you need a tool or a service or a combination of the two. Customers should spend time on requirements so that an RFI or RFP reflects their business needs (difference between service & solutions RFP is that the former is more outcome-oriented and should contain a lot less in terms of technical specifications, just what is needed for a vendor to specify an appropriate solution). Consider these requirements within the overall ITAM capability.
- Sourcing – Engage with people in your organisation who have carried out successful tool and services sourcing activities in the past – speak to your PMO and sourcing teams to help identify people who can provide insight into how to get this right
- Standardize sourcing and selection – Identify any templates your organization uses to standardize its sourcing and selection process and ensure that you understand how to leverage them to get an effective result. Identify where they may need adapting to maximise the chances of a successful outcome.
- Pre-screening – Use pre-screening questions to ensure that all respondents meet any organizationally-prescribed criteria or obtain formal sign-off for variation to standard requirements before issuing any documentation.
- Engage specialists – If you don’t have a sourcing function that can help with development of the RFx documentation, or one that lacks skills and experience in this area, talk to your professional advisors or engage a specialist to help you build your requirements and create the documentation and scoring mechanism needed to select the right solution.
- Meet prospective vendors face-to-face – don’t rely purely on written responses. Engage with vendors early in the process to ensure that they have understood your requirements clearly and are able to respond effectively. Consider whether further face-to-face meetings should be built into your process to help with clarification and understanding how the ongoing relationship will be built.
- Set expectations – Include an appropriate level of detail to cover expectations about tool implementation and configuration, and any professional services needed to get the solution up and running.
Investing time in building detailed requirements, a well-structured RFP document and an effective scoring mechanism will increase the chances of procuring the right SAM solution for your organization’s needs.