How to buy software

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:

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:

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

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

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

User onboarding

Access control

User tasks

Reports

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:

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

*concurrent = the number of people actively using the system at the same time

Scalability

Availability

Security

See the Due Diligence questionnaire below for more detailed questions to ask the suppliers.

Usability

Maintainability

Environmental impact

Regulatory compliance

Integration requirements

Integration means different things in different contexts:

Look and feel

Single sign on

User provisioning

Data transfer

Reports

Reporting requirements

Pricing model

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:

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:

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:

  1. 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.
  2. 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:

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:

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!

Posted: 06 May 2024

Tags: Solutions architecture Supplier selection Project management

Related articles

Learning Technology Connections newsletter

Sign up now for information, ideas, tools and techniques - sent monthly