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.

Requirements analysis is the first stage in th...
Requirements analysis is the first stage in the systems engineering process and software development process. Systems Engineering Fundamentals Defense Acquisition University Press, 2001 (Photo credit: Wikipedia)

Common Mistakes

This list isn’t exhaustive, I’m sure there are many more ways that requirements can go wrong.

  • having too many
  • not prioritising
  • 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 them 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 them (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. It should also let you know who to go back to with decisions around compromises.

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 on 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.

When you start procurement, then stop iterating. That’s when change control comes in.

 

Related articles

Related Posts: