Requirements are the key to getting a good solution, whether in procurement or just choosing between options. Most people get their requirements wrong, largely because they haven’t drawn this connection.
Common Mistakes with Requirements
This list isn’t exhaustive, I’m sure there are many more ways that requirements can go wrong.
- having too many requirements
- not prioritising requirements
- not engaging end users to develop requirements that meet their needs
- just throwing everything in that users ask for, without analysis of necessity (the big stapler approach)
- having requirements that constrain options to a specific solution (e.g. “we need to upgrade Oracle” rather than “we need a database”).
I’ve spent years as an analyst, and leading teams of business analysts, coming up with requirements from small projects to those with £1 billion business cases. What I have observed from my personal experience is that less is definitely more; desired outcomes beat other kinds of requirements; and not all requirements carry equal weight.
The requirements you set out determine your solution, and how many options you have to choose from. The more exacting you are the fewer choices you have, and the risk of a suboptimal solution soars.
Getting Great Requirements
1. Think about Outcomes
The first step is making sure you are looking at outcomes. The suppliers/developer will offer solutions based on their understanding of the outcomes you need. Don’t do their job for them. If you do then you are getting in the way if innovation. Innovation is a good thing.
Speak to as many end users as you can. This includes their managers and stakeholders too. What exactly is the purpose of the thing we want to build or buy?
2. Write Requirements as User Stories
Once you’ve collected the data you need to write it down in a form that lets you trace it back to why it is a requirement. This will come in handy at later stages when you need to test the requirements (and also solutions).
Write things in the form “As a [user] I need [a feature] so that I can achieve [an outcome]”. This will enable you to understand why you want things.
3. Prioritise
Not all outcomes are equally useful or desirable. So you need to prioritise them. The most useful framework I’ve come across is MoSCoW. In decreasing order of importance these are Must, Should, Could, Would. If you use it then it is worth putting this in the preamble of your requirements set so that the developers or suppliers understand.
Must = this is a deal breaker if not present
Should = we’d pay extra to get this but expect it to be included, price accordingly
Could = good if it does this, but we won’t be paying extra for it to be included, or to remove the capability
Would = it would be nice, but really we don’t expect it to happen (useful for things stakeholders insist are in the requirements but really aren’t needed)
Use this process to winnow out as many requirements as you can. Keep only what you can test and are necessary.
4. Explain Requirements to Suppliers
Once you’ve been through the prioritisation take the list of requirements to the people developing your solution. Talk to them about feasibility and price/effort of your musts and shoulds. Listen carefully and challenge assumptions, yours and theirs.
5. Iterate
Use feedback from testers, users, developers to iterate the requirements until they are done.
Once you use the requirements to start procurement, then stop iterating. That’s when change control comes in.