Those of us working in the sports industry know that rights owners often must operate with very lean teams – this is certainly true of national governing bodies, some international federations, clubs that sit lower down in their respective leagues, and any organisation in a niche sport.
This often results in people doing more than one job or taking on tasks outside their traditional domain and, particularly when it comes to IT, you won’t find many rights owners that have Gartner’s recommended ratio of 5% of full-time employees as a percentage of total employees.
This often leads to an absence of procurement process best practice when it comes to sourcing software and, as a result, it’s an area Winners is often hired to manage for our clients.
Why do I need a procurement process?
The number one reason I recommend a procurement process is it will ensure you buy what you need and want, and prevent you from buying what a salesman is presenting. Specifically, in our field of CRM and data, I come across many people who’ve licensed software because someone they know uses it because their ticketing system integrates with it because the vendor is giving a discount to all customers in March, or any one of several different reasons. And this is the main reason we constantly hear that “80% of CRM implementations fail”.
What I really want to hear someone say is they bought xyz software because they were the vendor that could meet most of their requirements at the best price, with the right terms, and who fitted their culture. And that they liked them – we shouldn’t forget that even with processes, we still buy from people we like.
While we love running procurement processes because it allows us to stay abreast of different offerings in the market, I thought I’d share our approach with you. If lack of time is your challenge you can still call us in to support, but if it’s because you’re not quite certain how to start, you can follow our 5-step guide.
Step 1- Gather your requirements
Perhaps the most important step in our process is to gather the requirements you have for the software you need to purchase – in other words, what you want it to do for you. The way we do this is to gather all the stakeholders – or as many of them as possible – in a room (or on a Zoom call in our COVID world) and go around asking:
- What do you need this software to do?
- What functions would make your job easier?
- What do you like about your current system?
- What would you like to do with your current system but can’t?
What we’re aiming to get here is as long a list as possible and, while it’s quite a time-consuming process, it really does deserve full attention. Our approach is to invite the stakeholders to shout anything out, or as many things as possible, and then we discuss two things among the group:
1) Is it a requirement, or just something someone shouted out?
2) What level of priority should we apply to that requirement? We use the MoSCoW method when applying a priority – Must have, Should have, Could have, Would have.
The result is a matrix presented in excel, with a list of the requirements – translated from the shout-outs in our workshops into more technical language – grouped into functional or non-functional areas, with the relevant M, S, C, or W status. A vendor is then asked to confirm if their system supports a requirement, doesn’t support it, or doesn’t support it currently but has it on the roadmap. We then apply a score to a vendor’s response to each requirement, so we end up with a numeric foundation to easily identify the difference in functional capability between one platform and another.
For some clients, we then apply another level of weighting because a vendor might support 96% of functional requirements but cost three times more than a vendor that only support 92%, but for this client, pricing might have more influence than the functionality of the system. Similarly, a vendor that supports the most requirements and is even the most cost-effective, might not fit the culture of our clients and this could be a major factor in the decision.
Step 2 – Invite your target vendors to participate
We like to invite as wide a group of vendors as possible to participate – firstly because it ensures our clients get a fair assessment of the market, and secondly because we like to use the opportunity to learn about vendor products. However, we’re also highly aware of how valuable everyone’s time is so we would never invite anyone into the process that doesn’t have a reasonable expectation they could be short-listed.
Step 3 – Issue the RFP (request for proposal) to participating vendors
The RFP is issued under an NDA to ensure the identity of our client is protected from the general market and includes information we need from the participants that we don’t call out in the requirements matrix. This includes:
– information about the company (history, size, organisational strength, capacity, experience in sports, team members, etc.)
– project approach (client onboarding, implementation, training, project governance, etc.)
– commercial terms (license fees, set up costs, cost of integrations, any other services, break clauses, etc.)
– service level agreement (guaranteed uptime, service desk, escalation process, etc.)
Our process includes a period for participating vendors to ask questions that arise from reading the RFP. We collate all the questions, ensure they’re anonymised, and then distribute them with the answers to all parties to ensure everyone has the same information when they submit their proposals.
Step 4 – Vendor shortlist
Winners review all incoming proposals and present a summary of each to our clients. From this we’ll work with our clients will create a shortlist, usually of three to five companies, for a presentation and product demo. When we do this, we always ask the vendors to skip the part where they tell us about them and their clients – we secured that information in their proposals and like to use our time with them to focus specifically on the product demonstration and addressing our client’s challenges and opportunities.
Step 5 – Vendor appointment and contract
Our role in the process is to collate, analyse, and present the information our clients need to make an informed decision – once this has occurred, we usually step back although some clients will ask us to negotiate the contract as well. One key thing to do when it comes to contract stage is to ensure the requirements matrix produced at step 1 is included as an addendum to represent the scope of work/contractual deliverables. If the vendor said they can do it during the sell-in, they must be held accountable to deliver it.
The requirements matrix
The requirements matrix can also be used at the implementation stage – each requirement can be “ticked off” as the vendor demonstrates its functionality – and then again in the training process to provide a guide of the requirements that need to be shared with the user. So back to my original statement that it’s perhaps the most important step and while it’s time-consuming, it’s well worth the focus as it’s used in multiple ways.
Good luck with your own IT procurement process – I hope this has been of help but if you’d like further guidance in this area please feel free to get in touch.
