Capturing Software Project Requirements is a Waste of Time

• Requirements gathering burns a third of your budget—and delivers near-zero value.

• Real users can't predict what works; let them test real features, not sign fake documents.

• Success comes from solving for outcomes, not documenting assumptions.

For the past 50 years, "user requirements" have been at the centre of building new software solutions, including web and mobile ones.

This paradigm is common between traditional "waterfall" methodology and the newer "agile" techniques, though the way they approach documentation is different.

There have been plenty of tweaks to the way we approach this, including a plethora of new tools and formats—but it's rare to see anyone questioning the practice itself.

On face value, the idea seems straightforward enough.

The business knows what it needs—we just need to ask them, write it down, build it, and they'll be happy, right?

But even in this simple sentence, there are ambiguities and assumptions which just don't hold true.

What Business?

Firstly, there's "the business."

In most projects, this ends up being a dozen or so people in a variety of roles.

In some rare cases, it does actually involve a person who will be using the new solution for close to 100% of their day (the real user).

This is rare because users typically have an operational workload that already takes up 110% of their day, so managers are unwilling to have them involved in requirements gathering. The whole point of the new solution is to open up space, right?

Even when we do get an actual user involved, we're often admonished for taking down what they say as a "requirement," because that will just propagate today's mess.

So we end up taking down our requirements from a bunch of people who won't be using the system for their main day job.

These people have different perspectives and will unavoidably have conflicting views on the correct requirements to write down.

This is compounded by the fact that different people will have a different view of the "type" of requirement we're trying to capture.

Which Requirement?

There's also a difference between "what I need to do my job" and "what is needed to deliver the business outcome."

Given our job is to deliver a business outcome (the reason we've been given the funding), there is only one correct answer to this question.

Yet I've never met a business analyst who has made this distinction when talking to business folks. Nor have I met a businessperson at the coal face who can articulate the business outcome the sponsor has promised to deliver, or who has the training and experience required to convert this outcome into a set of requests for the team.

I find this an unreasonable expectation to foist upon business people, actually. These people are usually (quite reasonably) uncomfortable with the responsibility placed upon their shoulders. They know that if they make a mistake, they and their peers are going to be stuck with it for years. We don't even give them training to support them in this role.

Everything's in Scope

Are all requirements equal? Should all requirements fall within the purview (scope) of the new solution?

These are questions rarely asked at a nuts-and-bolts level. If we're asking someone about "order taking," then it is assumed all "order taking" requirements are in-scope.

Even in the early days of my career this seemed a bit wrong, but I couldn't articulate why—I just did what I was told.

I noticed business analysts often use the term "the business" in the same way a parent eventually resorts to "just because!" when confronted with 20 "whys" in a row from a toddler. When the team pushes back on the usefulness of a requirement, the business analyst will say, "the business asked for it."

Back in the day, I would outlaw this phrase. All requirements had to have an individual's name against them so we understood the context for the request.

Writing It Down

There is no perfect way to write down requirements. They are all very, very poor cousins to a working solution because there's no way to interact with a document.

Even if we went to the expensive extreme of building "clickable wireframes" or other visualisation techniques (aka functional specifications), they don't convey 1% of the behaviour. In reality, the behaviour is a flow backwards and forwards through these "user interface" snapshots based on a real-world event.

Writing down requirements is what's known as a "lossy" process. You lose a huge amount of information between the user's internal visualisation, their description to you, and then the final written word.

This is why it's so hard to get participants to "sign off" old-school requirements in a traditional waterfall project. Not only are the requirements seen as a poor cousin of what they had in their mind, but they also know what they had in their mind might not be what they—and the rest of the team—will actually find useful, until they actually use it.

In my early days, I noticed a huge amount of anxiety and resistance at this phase of traditional waterfall projects, with many requests to amend seemingly insignificant details. In hindsight, this was just masking a subconscious aversion to using a document to represent a working system.

I've noticed exactly the same thing in agile projects, too. It's just that the behaviours bubble up throughout the project rather than at just one point. Sprint planning and story or card definitions are typically these activities.

The Cost

Keep in mind that requirement-capture activities in most waterfall and agile software projects make up a quarter to a third of the budget.

In a median corporate project these days, that's around $250k for a six-month project.

That's a big chunk of change.

The Alternative

I haven't captured user requirements for over a decade now, and yet I've delivered 300 projects for 70 clients—many of them turnarounds or rescues.

I can share, for example, that it's possible to run a $4 million, 18-month project to redevelop a call centre without writing down requirements.

The hint to this secret is in the title above: "Which requirement?"

In my world, the project team doesn't start work until we're clear about the "why" of the project—the business outcome we're trying to achieve.

That's not "replace the call centre system"; it's "cut call times in half for 80% of calls." (That's the topic of another article.)

Because the team can articulate, in a short sentence, what the finish line looks like, they can take on the responsibility of translating that into features and functions that will deliver the outcome.

Of course, they need real users for this—but we're asking them a totally different set of questions. We're asking about the things that are standing in their way to reduce call time. We're not asking them to suggest what that should look like—that's our job. And we're not asking them to sign anything off; we're just asking their opinion: "If we build xyz, do you think it would have a big impact (on call time)?"

We never go longer than a few days between talking about a feature and building it, so there's no need to write down any significant details because everyone's got the same picture in their head.

Users have the ability to interact with their requirements to actually do their job—then they can give us real corrections, and we can work on those too.

The bedrock of this frugal approach is the integration of continuous build with continuous rollout. This means the first release to a user or a few in the first month, then new releases every few days for the rest of the project. As the solution and integrations get more sophisticated, we can roll out to larger groups of users until we're done.

Doing this big bang or even in phases injects too much time between discussion and experience—which breaks it.

This is the third way.

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.