Thoughtful requirements drive your project’s success

How to recognize what’s optional

Nothing determines the success or failure of a project more than the quality of the requirements you develop at the beginning.

It really pays to invest time getting them right.

There is something reassuringly certain and fixed about the term “requirements.”  But real life shatters that illusion pretty quickly. Minds change and new information emerges, so you have to adapt the requirements.

The term “requirements” then is a bit of a misnomer – it might be more accurate to call them “desirements” to clearly acknowledge that almost everything is optional.

So how do you recognize what’s necessary versus just nice-to-have, and whether a desirable feature is worth building? Here’s the approach we have developed over many years enabling businesses to make data-driven decisions.

 

What are the goals and options?

In our work with clients, we view all requirements as negotiable. Experience tells us that by probing into our client’s goals, we might identify better versions of them. That might be because they didn’t crystalize exactly what they wanted, or because there’s a much better way to achieve something close to their desires.

With more flexibility in the organization’s goals, we can often uncover even better ways to achieve them. Businesses often focus on a single goal at the expense of all others. Taking a slightly broader view we may find other goals that have substantial low-hanging-fruit available.

Exploring the options often unlocks new opportunities. Different individuals will see different ways to improve organizational goals. Each method may have different strengths and weaknesses that you must compare to see how they could impact the goals if implemented.

Any worthwhile requirements gathering process involves taking the time to do a broad analysis of the goals and options to improve them. However, there are further steps before you know clearly what the project should accomplish.

The impact of the unknown

If we knew exactly what all the options were and how they would impact the goals, it would be relatively straightforward to hone the requirements for a project. Unfortunately, projects are not that certain.

Each desired feature will have an uncertain cost and an uncertain benefit. If the ratio between the return and investment stays above some cutoff, the feature should be considered a must-have. If that ROI flips below the threshold though, it should be removed from the scope of the project.

However, contracts and dependencies often cloud the picture. If you have a fixed price project which will deliver a set of requirements, the investment at least stays stable regardless of any new complexities that arise. The return however can still change as you learn more.

If your contractor has to build in the cost of the unknown, you end up locked into paying for features that might not be valuable enough to justify the investment.

Prototyping strategically

When working on a project with many dependencies and interfaces, we usually have to accept a more requirement-driven view of the scope. Otherwise, you end up building a system that doesn’t do what it needs to.

But when you are faced with large uncertainties about the costs and benefits of any particular feature, you need a more flexible strategy.

To navigate these tradeoffs, you should always consider two phases of a project: desirement analysis followed by requirements definition. In the first phase we ask people what they want, and we analyze what it would take to deliver those desires, what the true upside is, and what trade-offs will have to be made. In the second phase we create a comprehensive view of the project based on what’s desired and the unknown costs to pull it off.

And for parts of the project which don’t have dependencies and interfaces? Stick to a more flexible desirement model so you can update your plan as you learn.