Author: Ron Purba


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 atten