RIP BRD

Does anyone recall the early days of their BA career when Waterfall was the only option in town and writing a long Business Requirements Document (BRD) packed full of text was the de-facto one-size-fits-all standard? 

Typically there was limited discretion in this area as it was a compulsory artefact often mandated by the corporate PMO overlords and template-police enforcers. Basically a BA had no choice but to write, own, publish, edit & re-produce this document using this type of format.

Does anyone still write these types of documents in what is increasingly becoming a disruptive agile world? Well haven’t times changed?

When I first worked as a BA, the standard method was constant pressure to issue massive documents in an unrealistically short timeframe. This pressure originated from Stakeholders to Project Managers, who both didn’t really understand much about the BA role and proposition. The PM imposed aggressive deadlines to get it done in project kick-off meetings – “You’ve got 2 weeks to write this.” No offence intended to PMs – this was my experience, as I was not properly consulted to get an estimate of my effort.

In the rush to quickly write, revise and complete a document while unrealistically trying to capture 100% of all known requirements up to that point and forever after, the actual result was the requirements were constructed without any real shared understanding of the underlying business needs or problems. In effect, the documents were sketchy or poorly constructed.

The whole process backfired as requirements were often written and reverse engineered to suit the solution and, ironically, this consumed a lot of time, scared stakeholders at the very unpleasant prospect of reading these works of art, and by the time they were finished the world had changed and moved on – the requirements were now obsolete. To add to this mix of unpleasant behaviours, senior executives and other stakeholders did not have the appetite, time or attention span to read and scrutinize these documents unless they came with a one-page summary.

---

---

So why bother creating the BRD in the first place? The trick here seemed to be that highly skilled BAs could summarize and roll-up the core requirements (similar to a MMF or a MVP) from the masses of text into a page or two.  So why not skip the document creation and treat everyone as if they were a senior executive?

Why did the BA community do this? It makes no sense to me that valuable time, skills and energy were wasted to this inefficient practice. I think part of this was the BA profession was not recognized for what it is today in terms of a critical role to delivering value and successful outcomes. Also, it was partly because the BA was relegated to the bottom of the Project Delivery food chain and had no say (i.e. influence or authority in the matter).

I remember a former boss giving me some words of wisdom to the effect that the length of this document defends it against being read. I wondered at first what this meant and soon realized that I was creating these lovely War & Peace-like deliverables that were never read thoroughly or in their entirety, nor did they get signed off quickly or easily. It was just an administrative exercise to tick someone’s checklist in the PMO and report a false sense of achievement.

In fact, I would go so far as to say the only person I was eventually writing these documents for was for me, as I felt good that I had produced a great piece of work. Ultimately, the BRD (or whatever term you care to use for a BA document deliverable) was not fit for purpose.

It took a disproportionate amount of my time to get through the elicitation, production, review, updating, feedback and sign-off cycle, which wasn’t always one pass, yet I was often considered as being the bottleneck.

It was like a never-ending Groundhog Day. What a pain – the results were always predictable, lots of rework and no overall improvements.

So I started gradually introducing different content into my documents. This included process and context diagrams, scope models, screen and form mock-ups, and infographics to get the point across quickly, while presenting a more visual representation of the requirements package.

People started to notice and like this, and slowly things improved – as they say less is more. Over time the visual content replaced a lot of the textual narrative and content. The documents became leaner.

You can get your point across quickly and drive group understanding and consensus more effectively with visual models and artefacts. Requirements were also geared around the user journey goals and customer experience with design thinking added to the mix

I’m glad to say that the new paradigm seems to be more focused on creating just in time, short and sharp user stories. It’s reassuring that things are not what they used to be, especially as there is an abundance of mature requirements management offerings with modelling capabilities that have revolutionized the BA role. These now serve as more effective vehicles to manage requirements.

This is not true for every organization, but hopefully the balance will eventually shift as the BA role evolves.

BAs can now spend more time on high value activities geared to meeting strategic goals and successful business outcomes, rather than worrying about the low value manual effort and clerical administration associated with maintaining BRDs.