The article below was the basis for a professional development guide: How to Buy Software.
The guide contains more detail and templates for people working through the software buying process.
The first 100 people to use the link below will receive the guide for free.
This guide is designed for those who buy software, particularly multi-user SaaS* products, for organisations.
*SaaS = Software as a Service, usually accessed through a browser over the internet.
For smaller projects, if you’re the only person involved in the buying process, you might be able to merge some of these steps together. For example, steps 1-5 can work well as an iterative process - but you’ll still need to cover all the bases described here, even if it’s just in your head.
Step 1: Identify the problem
You probably have a rough idea of what you’re trying to achieve, or the problem you’re trying to solve. It’s worth spending a short time writing this down. You’ll need it when you engage with suppliers.
Make sure you can answer these questions:
- What are you trying to improve? Generally software can be helpful to increase efficiency, to reduce risk or to maintain consistent quality. Which of these apply to your situation?
- How big is the problem? What will happen if nothing changes? Will you lose money? Will you be fined? Will your competitors do things better, faster or to higher quality for the same price?
- What are you measuring that indicates the size of the problem? You might want to consider metrics of time, quantity, complaints or incidents. The exact measurements will depend very much on your industry and particular context.
- What would you like to achieve in terms of those performance metrics?
Step 2: Identify possible solutions
You’ve probably already started doing this. You’ll have seen marketing materials, or stands at conferences, or maybe you’ve been cold-called by a product representative.
But let’s take a small step back.
Consider these questions to help in your thinking and your future conversations with potential suppliers:
- What have you tried so far? Do you have a cobbled-together solution built on Excel or something similar?
- What has worked? What doesn’t work? What characteristics would you like to keep from the existing solutions?
- What have you learnt in the process? What needs to improve from your current solution? Perhaps consider things like robustness, reliability, multiple users with multiple roles, version control etc… These will depend very much on your context.
- What are your competitors or partners doing in this space? How are they solving similar problems?
- What does your current “landscape” look like? In terms of other software, your IT infrastructure, current regulations and standards, your culture, your finances, and your organisation’s existing capabilities. What will your new solution need to fit into?
- What types of solutions seem to fit your problem? Is there a specific genre of off-the-shelf software that you’re looking for? Can you filter that genre into sub-groups. For example: You might want a system to help manage learning experiences, but you’re working for a training company. That immediately narrows the field.
- What is your vision for the future? Consider changes that may be happening in society, technology, your organisation, your customers etc.
- How agile can you be? Are you able to manage continuous change well? Do you want something that works out-of-the-box? Or do you need something that is highly configurable or even bespoke? Or do you want software you can customise?
- Do you want an all-in-one solution, or a combination of different best-of-breed providers? Do you have the skills to join them together?
Step 3: Make a long list
Now you have an idea of the sort of thing you’re looking for. So you can start to look for potential suppliers.
Where to look
- Search engine adverts: Type in the name of one, major supplier and you’ll be given adverts for a whole host of competitors
- Search engine generic search: Type in the genre of software you’re looking for. Don’t forget to also include "open source" if you’re looking for free or customizable software. They don’t have the marketing budget to compete with the commercial vendors.
- Comparison sites: Places like G2, Capterra and Alternative To can be useful starting points
- Analysts: Different industries have their own specialist analysts. For learning technology, you could look at Fosway’s 9 grids or Craig Weiss’ Find An LMS
- Blog posts: If you’re looking for something with mass appeal (like project management software), you’ll find dozen of blog posts comparing different systems. Look at the comparison factors that they identify. Be warned, many are written by suppliers trying to make their software sound the best…
Start to identify the key differences between the suppliers. It’s like looking for a house - you’ll gradually start to pick out the things that are important to you.
Things to consider
- Features - does it do what you think you’re looking for?
- Pricing models - are they even available? If not, then are you big enough for that supplier to deal with?
- Support & training - can you see any documentation? Is there free training available online to give you a feel for what’s on offer?
- Usability - can you get a feel for how easy the software is to use?
- Accessibility - do the suppliers even mention this?
Step 4: Create user scenarios
As part of your selection process, you’ll need to test out the software. Scenarios will help ensure a fair test across multiple products. They’ll also help the suppliers to quickly assess whether their software will meet your needs.
The scenarios should describe the experience you expect for your users. Pick 3 or 4 key areas that you want to test out. Try to pick some that are unique to your particular context and needs.
Users and organisations
- Who will be the key user groups? Eg. End user, Client administrator, Client managers, Site Administrator. You might want to do a scenario for each type of user.
- Are all the users going to be from one organisation? If not, will you need to keep the data for each organisation separate?
- Will you need to break down the users into further sub-groups? For what reasons?
User onboarding
- How will your users be brought into the system?
- How will they receive their login details?
- Will you be connecting into one or more Identity Providers (like Microsoft, Google, Facebook etc)?
- Will users self-register?
- Will users pay for their own access? How?
- Will users pay on behalf of other users? How?
Access control
- Will some users have access to some parts of the system, whilst other users have access to other parts?
- Who will need to see data about users from the organisation(s)?
User tasks
- What will prompt users to login? How will they receive that prompt?
- Once a user is logged in, what do you expect them to be able to see and do?
- How they will know what they need to do?
- How will they see what they’ve done?
- Will their journeys be linear (following a standard path)?
- Will users be able to choose their route? How will they be guided?
- Will all users follow the same route?
Reports
- What reports do you need to be able to see?
- What reports do your users need to be able to see?
Now turn all that into a set of short narratives, like the example below:
We sell online learning products to other businesses. The products are created in an elearning authoring tool. When a company buys into our service, we bring them onboard quickly - setting up access routes and licenses purchased. They will buy, say, 100 licenses. Any employee in the customer’s company should be able to access the content easily, through single-sign on. When all the licenses are used up, additional employees will see a message informing them to request further licenses. Our platform administrator runs a report each month detailing the number of licenses purchased and used by each customer company.
Step 5: List the requirements - first draft
Now that you’ve examined what software is available, and have developed your scenarios, you can come up with your list of requirements. Try to be as specific and descriptive as possible. A list of features on its own can be pretty meaningless. They gain more meaning when you say how you expect the feature to work for you, and why they are important.
This is the first pass. It will change when you’ve tested the requirements against what is available on the market.
I recommend marking each requirement with a priority, perhaps using the MoSCoW model:
- M = Must have when you first launch
- S = Should have when you first launch, but can defer to the next iteration if necessary
- C = Could have when you first launch. They will add value, but are not essential
- W = Won’t have when you first launch, but it would be good to see it on the roadmap
Each of the categories below contains a series of questions to help your thinking. Some may not be relevant to your needs, so use with at your discretion.
Non-functional requirements
Performance
- What is the maximum expected response time (eg. pages should load within 7 seconds on a 4g connection)
- How many concurrent* users will the application need to support? (eg. support at least 2,000 concurrent users). For many types of system under voluntary use, this would average out at less than 10% of the total number of users. When usage is compulsory and there are deadlines in place, this concurrency level will increase sharply.
*concurrent = the number of people actively using the system at the same time
Scalability
- How do you need the application to respond to unforeseen peak demands? Are you happy for it to gradually stop working? Should it put users in a queue? Should it scale automatically to allow everyone to access with no degradation of service? (Give examples of what might happen to cause peaks in usage - such as deadlines or marketing campaigns.)
Availability
- What is your expected minimum uptime percentage (eg. 99.99% availability). Does that measure include scheduled maintenance times?
- How quickly do you need to recover the system should something fail? (Recovery Time Objective)
- How much data can you afford to lose should the system fail? (Recovery Point Objective)
Security
- How frequently should the application be tested for vulnerabilities?
- Do you require compliance with standards like PCI-DSS, ISO 27001 or Cyber Essentials
See the Due Diligence questionnaire below for more detailed questions to ask the suppliers.
Usability
- Do you require a responsive interface for both end users and administrators?
- What level of accessibility standards do you expect? Consider the W3C Web Content Accessibility Guidelines and their levels A, AA and AAA.
- Do you need the application to have been tested for accessibility by a third party such as Shaw Trust
- Do you require the application to work in multiple languages? Which?
- Do you need the application to be able to handle content that you enter in multiple languages?
Maintainability
- Will you want to see evidence that the software is continuously maintained and kept secure?
- What sort of evidence would you accept? Consider things like issue reporting mechanisms, security announcements, git commit history, software roadmaps, and live system status reports.
Environmental impact
- Will you need suppliers to provide evidence that they are minimising their environment impact?
- What types of evidence would you accept? Consider things like travel policies, and datacentre Power Usage Effectiveness (PUE) and Data Center infrastructure Efficiency (DCiE) measurements.
Regulatory compliance
- Does your industry have specific regulations around things like data immutability (often seen in finance applications), accessibility, or data transfer standards. You’ll need to note them here.
Integration requirements
Integration means different things in different contexts:
Look and feel
- Does the new software need to fit your organisation’s design patterns? This is especially important in public-facing applications, like ecommerce, training or content management.
Single sign on
- Does the supplier need to support single-sign on against your preferred identity provider (IdP), for example Microsoft, Google, Facebook, Octa, Auth0?
- What standards should the supplier support?
User provisioning
- Should the software allow automatic provisioning through systems such as Active Directory?
- Or must the software connect to your HR or CRM system?
- Should this be automatic and continuous, or in batches overnight, weekly or monthly?
Data transfer
- Will the software need to communicate transactions to your finance system?
- Will it need to send records back to your HR or CRM system?
- How often should the data be passed across?
- What will you need to import to or export from the system? In what formats?
Reports
- Will the supplier need to make data available to your data warehouse / data lake / analytics toolkit?
- Will the users of the analytics accept data that is 24 hours old, or does it need to be “live”?
- Are there any standards you expect to comply with (eg. xAPI in the learning field)?
Reporting requirements
- What reports will users need to see? For themselves, for their teams, about their customers, about their organisation?
- Consider the key metrics you identified earlier. Do you expect the new software to help you generate those?
Pricing model
- Are you looking for a supplier with a transparent pricing model? Or do you have enough potential users that you’re OK to go with an “enterprise” supplier, with whom you’ll negotiate a price?
- Does your budget look like it will be enough to cover the costs?
Functional requirements
This is where you need to list out the most important things for you, along with why you need them, and how you expect them to work.
Many companies simply create a huge shopping list, which is of little use to the supplier or the customer.
Instead, go back to your scenarios, and consider the functional areas that you’re interested in. They’ll vary depending on the type of software you’re looking for. Let’s take the example of project management software. In this case you might have functional areas like:
- Planning
- Collaboration
- Financial management
- Project visualisation
- Project reports
For each one of those describe your expectations.
Step 6: Make the short list
Now you’re going to need to go through your long list and assess each supplier against your requirements.
Go through the Must haves first and remove the suppliers that fail on any one of these.
With those that are left, then go through the Should haves and remove the suppliers that fail on the higher priority items.
Then do the same with the Could haves, until you end up with about 5-7 potential suppliers.
It’s not always quite as scientific as the previous statements might lead you to believe… If you really understand the requirements then you’ll be able to do a lot of this on gut feel - based on what you can see from the suppliers’ websites. If you’re involving more people in the process, then you’ll need the more rigorous and formal approach.
Step 7: Competitive dialogue
Now comes the point at which you start to engage with the suppliers. Take your shortlist and arrange an initial meeting with the sales representative. During this call they should be asking you questions. If they simply do a presentation or demonstration then you might want to consider dropping them, unless they’re already near the top of the list.
Ideally, during the initial call, you’ll have a chance to explain what you’re looking for, and what’s got you to this point. That’s steps 1 and 2 of the process you’ve followed so far.
You’ll also need to set out to them what will happen next. This is the process of competitive dialogue.
There are people that will do a procurement exercise based on a single Request for Proposal (RFP) and the suppliers’ responses. I’ve always found that to be less than satisfactory. Both parties are making guesses and huge assumptions that will only be uncovered once implementation begins.
Competitive dialogue allows you to tease out those assumptions beforehand. Yes, it takes longer, and may, therefore, be more expensive. But the end results are more reliable.
The competitive dialogue takes the form of at least two iterations. The higher the stakes, the more iterations you’ll need. At the end of each iteration, you’ll disqualify at least one of the suppliers. As the process goes on, the remaining suppliers become more invested, and you can ask them to contribute more effort.
Iteration A
Provide the suppliers with a document containing:
- The problem defined in step 1
- The types of solutions you’ve considered in step 2
- The scenarios developed in step 4
- A description of the competitive dialogue process, including stages, key dates and what will be required from the suppliers at each stage
Provide a separate document containing the draft non-functional and functional requirements, listed with their rationale and prioritizations. Note that this may change before they receive the final list.
Ask the suppliers to prepare a demonstration of their software addressing each of the scenarios you’ve described. Maybe give them a week or two to get this ready. A good sales team will ask for a pre-meet to go through any questions they have about the scenarios.
Use the demonstrations as an opportunity to dig into assumptions you’re making. Hopefully the suppliers will be doing the same!
You’ll probably find you can easily remove a couple of suppliers from the list pretty quickly at this point. Especially those that just give a standard demonstration without addressing your scenarios…
Iteration B, C, D etc
You might want to ask for more demonstrations on specific functionality or conversations about the non-functional requirements where you or the suppliers have questions.
Don’t be afraid to edit the requirements as you work through the process and understand more about what you need.
Aim to whittle the suppliers down to a list of three at most.
Final iteration
This is when you do two things:
- Send out the Request for Proposal (RFP). This is a formal, legal document, that will need to comply with your IT procurement policies. The suppliers will be expected to provide a formal response, including their prices.
- Begin a 4 week deep dive into the software, to try to give it a real-life test. You’re unlikely to cover everything, but try to make it do the end-to-end process (eg. planning, collaborating and reporting on a project portfolio, or creating a training programme that leads to a certificate)
The RFP should contain, at a minimum:
- A formal invitation for a proposal
- Instructions to the bidders - about the process, the timeline, and any conditions and how you need the proposal submitted
- A description of the problem you’re trying to solve
- The final functional and non-functional requirements
- A pricing template, so you can compare like with like
- A security and data protection questionnaire (speak to your IT security specialist)
- How the proposals will be evaluated
Be realistic in your timescales - for yourselves and for the suppliers.
Once the proposals are in, you should be able to evaluate them against your criteria and then narrow the field to one, preferred supplier.
Step 8: Negotiation
Then it’s a matter of coming to a deal. There are whole books written on this by far more qualified people than me. So I won’t go into detail.
The aim is to get to a point where both parties feel like they’re getting value from each other, and neither feels hard done by.
You might find points of negotiation, such as:
- Numbers of users
- Whether licenses can be recycled, or whether they are tied to individuals
- When the users will start to use the licenses
- Sweeteners like additional functionality, professional services or access to content (if applicable)
- The length of the contract
- Break clauses, allowing both parties to walk away without penalties mid-contract
When you’re at a point where you can both sign the contract then it’s time to have a party, and get ready for the implementation. Hopefully with no surprises waiting for you around the corner!
If you'd like to discuss this article, or how I can help you, get in touch.
Posted: 06 May 2024
Tags: Solution design Supplier selection Project management