Business Requirement Documents are just no good and should be abolished from the world of creating software
I had hoped the
world could have wholeheartedly rejected Business Requirement documents by
now. For too long I’ve seen the repeated scenario of only commencing the
creation of a new initiative with a requirements document. Unfortunately most organisations that have
teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile
approaches maturing and customer-centric modes of design emerging, requirements
documents still persist.
If you work in
an organisation that doesn’t use business requirement documents any more, read
no further. You are lucky; sense has prevailed at your place however in my
experience, you are still the minority.
Let's face it; addressing
this issue is not always the point you want to start your improvement work when
there's much that could be dysfunctional with how a team is delivering
software. But now, I find myself as mad as hell, and I'm not going to take business
requirement documents anymore. I want to capture why I believe business requirement documents (henceforth referred to as BRDs) are just no good and should be
abolished from the world of creating software.
Why are they flawed?
• No one wants to read a BRD, least of all
the developers who are expected to divine critical functional aspects from
these dull and uninspiring tomes. Usually long and boring, more worryingly, they
are often not read at all. You can test this quite easily. Many years ago, a
mischievous college embedded a ‘Bacon workflow’ flow chart into his BRD; essentially
all paths lead to Bacon. This was missed by the dozens of named stakeholders
supposedly reviewing the document. We even logged the Bacon workflow addition
into the change log table at the start of the document, this passed review
without comment.
• A BRD closes down options for solving
business problems, as they pre-suppose solutions rather than describing the intent of the functionality that is
wanted. It’s common to read in a BRD a series of ‘The system must [perform
functionality X and Y]’ statements. Worse, the stated key business problem or
reason is given little credence. And worse still, alternative options are
spoken of briefly and swiftly ruled out at the start of the document. You get
the impression the document is telling you “Just build exactly this. And get it
done quickly please!”.
• BRDs constrain ideas, solutions and
creativity. How can you know that something is 'Required' if you haven’t spoken
to a customer of the software yet? Have you showed them some working code and
elicited their feedback? Have you spoken to the development team to see what
might be possible? Ideas, solutions and creativity to solve whatever business
problem needs software, can only be explored by interacting with the team that
will build the system, using collaborative discussion. A requirements document
will narrow down options and ideas, and may be materially harming the business
you are building for. Is the potential for great engaging solutions being left
on the table?
·
A BRD
creates a delay, or negates conversations, that should be happening at the very
start of your new initiative. Waiting for a BRD to be produced means precious
time and opportunity is lost, when instead, the team could be exploring the problems
that need solving.
• BRDs are a poor representation of what is
needed. What do I mean by this? It’s simply not possible to represent the
beautiful organic, changeable and dynamic nature of a software program in
something so serial and static as a written document. As both a former
developer and business analyst, I can attest that replicating every consequence
of every path that may be chosen in a software program, with a document, would
result in a document as large as the code you need to write. Which begs the question;
why not just write the code itself?
·
A BRD
copes poorly with change, they are fixed at a point in time and then forever
more, change must be 'controlled'. This factor then becomes a barrier to
changing. Change becomes labor-some and more effort is needed to reflect a
change. What if a change is something wonderful that a customer might love and
might make the organisation money? Too bad, the change will cost you extra in
documentation overhead. BRDs imply change is a bad thing.
·
Because
a BRD copes poorly with change, it creates the need for inflexible central
document repositories with version control. If you have experienced the pain,
dread and helplessness of trawling through document versions trying to
determine a static point in history then you will agree that document
repositories should also go the way of the BRD.
·
Documentation
is open to interpretation. The English language is colourful and descriptive.
Even when using terminology of precision, the interpretation of the
written word is in the eye of the reader. If you want to test this it's easily
done: provide the same written instructions for drawing a simple diagram to 3
different people. No two people will draw the same drawing. Programming is a
creative activity. A developer makes an interpretation of what is required; expecting
to leave them alone with a BRD to convey what is required will result in a
deviation from expectations.
But perhaps more serious than the purely practical
reasons stated, there are a number of cultural problems with the use of BRDs in
software.
A BRD perpetuates a lack of trust between people who
are supposed to be working together to create something. Sections such as
'Sign-off', 'Out of Scope' and 'Authored by' signify the same sinister nature. I.e.:
‘Who is responsible for agreeing to this?’
‘Who can I blame for getting it wrong?’
‘Someone agreed to this and I will prove it to them
later.’
‘I won't start until you authorise me to.’
’I don't believe your spoken word can be trusted.’
‘I need to prove you can't blame me if this goes
wrong later.’
‘If you change your mind you will pay.’
Such an absence of trust is a dysfunctional
atmosphere in which to expect anything but pedestrian software can be created.
The nature of a BRD with such sections and stamps of authority is a signal that
trust is missing between the individuals of the organisation. Such an
organisation cannot support the collaborative teamwork required for truly
outstanding software.
A BRD becomes a barrier between team and customer. In
the worst examples it represents an attempt to translate the needs of a
non-technical business to a team of people who can only speak 'techno-bable',
which is somehow insulting to both parties. Any person or document placed between
the people that want some software and team that build it, delays the relationship
building between team and business. Efforts should be made instead to get team
and business working effectively together and this requires that they know each
other on a more human level than via a document.
So if we
abolish requirements documents, what else can we use as tools of communication
between business and team? Good question! There are many answers and options,
but the first thing to do is to ask that good question. “What else can we
use?”. I commit to asking this question early and often, instead of accepting
that a BRD must be the default thing that is created. I hope you will stand up for #NoRequirementsDocuments as well.
For many
alternatives to BRDs for capturing requirements, as well as compelling answers
and ideas to put forth in face of organisations with mandatory BRDs, stay tuned
for my next blog : ‘Completely removing Business Requirement Documents from
your organisation.’
Comments
Point-for-point rebuttal:
* I want to read a good BRD. It tells me:
- who wants the thing I'm about to build
- why do they want it, in business terms. I can shift the technology, as long as it aligns with the stated business goals
* A good BRD does not even descibe the intent of functionality (and stays really far from solutions), it 'just' tells you the problem your client is having. This actually is the hard part, getting people not to think in solutions.
* Business people can tell you what they require, because they pay their bills (or they should). Therefore they can tell if they are spending a lot on e.g. correcting mistakes in some process. Their business requirement is bringing that cost down. It's up to others (you?) to find a solution to that problem. If your solution entails skipping the entire step that is causing the problems because you found you don't really need the input, good on you!
* A good BRD creates a delay by starting conversations. In writing the BRD the team is exploring the problems that need solving.
* A good BRD is not a representation of software. It's a representation of business requirements (hence the name)
* A good BRD does not need to cope with change. It is the reason you're building what you're building. That reason may change, in which case you need to stop what you're doing en re-evaluate the whole situation.
* Documentation is most certainly open to interpretation. But I know of no other way of sharing these ideas with a group of people. More communication is obviously better and talking helps. No need to leave the developer alone with the BRD. But, as a developer, it's nice to have it as a reference after it's been talked through.
Maybe I've been lucky in the BRDs I've encountered, but I find that if I hold them to these standard they are extremely usefull to me.
Groeten,
Friso
Cheers
A BRD is a thinking tool. Yes, there is some closing down and constraining that goes on, but actually every human communication of any sort (oral or written) does that. Alberto's point about sunk cost points up a common misconception. So many people fail to realise that it's the process of writing the document that's valuable, not so much the document itself.
Nick, Thanks for commenting but I couldn't agree less with the sunk cost misconception. I've looked into the sunk cost fallacy at length. These days there are so many ways to speed up requirements elicitation and therefore delivery - and then therefore customer value, that I just can't stomach the waste associated with laborious documentation any more; the waste coming from the lack of value they create for the creators of software. Hence I wanted to write this blog, so I didn't have to have the same conversation every time I do any work with clients on requirements elicitation. As a prior software developer I find them so wasteful it's worthy of 'software crime' in my opinion :) Feel free to get in touch if you want some tips on alternatives.