Skip to main content

Author: Ron Purba

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.


Advertisement

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. 

Business Analysis Triple Constraint & Value Chain

Most of us are familiar with the Triple-Constraint model from the world of Project Management where three variables, Time, Cost & Quality (Scope) are continually competing with each other under the watch and control of the Project Manager.
Basically, if any one of these dimensions is changed it has a consequential effect to the other two remaining dimensions or vice versa.

Ok so what? Let’s hold that thought …….Is there such an equivalent model within the field of Business Analysis?

I’d like to share some thoughts and while I can’t propose a like-for-like model using the same logic as the PM model, I think I’ve come up with a rudimentary Business Analysis Triple Constraint (BATC) using three key metrics or points of scale which govern how a product &/or service is brought to market & assessed for success.

These are essentially Quality, Utility & Value, all three constituent pillars required to form a successful Product for the consumer.

Before we examine this in more depth let’s revisit what we understand by these terms.

  • PRODUCT – The definition in this context is extensible & interchangeable to include:
    • A new service (B2B or B2C)
    • A new solution / software (B2B or B2C)
    • A new or optimised process

Business Analysis activities are primarily geared around delivery of a PRODUCT that is:

    • Fit-for-purpose
    • Adds or creates business value
    • Addresses a specific business need(s) and/or resolves a business problem(s)
    • Delivers the right capabilities with benefits and meets customer expectations.
  • QUALITY – The scale / ability of something to perform satisfactorily in service, suitable for its intended purpose & function. A degree of excellence and high-grade.
  • UTILITY (UTILISATION) – The scale of being useful, utilised, profitable or beneficial. Utility is a measure of the happiness or satisfaction gained from a good or service.
  • VALUE – The regard that something is held to deserve; the importance, worth, or usefulness of something
  • CONSUMER – A type of customer, user, purchaser of a Product

So some observations come to mind:

  • In the optimal scenario, if a product has high quality then there is likely to be higher usage or adoption i.e. high utility and an overall higher value to the consumer.
  • In the sub-optimal scenario, if the product has low quality then there is likely to be lower utility and hence lower derived value.
    Therefore to calculate the Product Rating the formula broadly must possess the following attributes / values. The higher the value of Value (no pun intended) the more successfully rated the product becomes.
  • Product Rating = (Scale of Quality + Scale of Utility = Scale of Value ) or P = (Q + U = V)

What about some other scenarios:

  • Can there be a product which has high quality and high utility but low value?
  • Can there be a product which has low quality & low utility but high value?
    • Given the real world I can’t envisage any legitimate examples where these scenarios exist (I could be wrong!)
  • Can there be a product which has high quality & low utility and hence reduced or average value?
  • Can there be a product which has low quality & high utility and hence reduced or average value?
    • Perhaps these scenarios are possible.

I could attempt to list more permutations, but the point I’m making here is that it is not as easy to replicate the same logic used by the PM Triple Constraint and apply this to the BA version.
The BA version is more like a sliding-scale where it is possible to go forward and backward incrementally across the three parameters in terms of low to high Quality, low to high Utility, & low to high Value. The aggregated scores are used to derive an overall Product rating.

Whereas the target focus for Project Managers has been geared around Time, Budget and Scope for a successful delivery, the Business Analysis discipline calibrates its efforts around Quality, Utility and Value to deliver the right product.

Business Analysts exist to ensure the product / solution is what was ordered (once the lid on the box is opened – see diagram). That there is the right solution for the right problem. This is opposite to the right solution to the wrong problem or wrong solution to the right problem. That business value is created by resolving business needs and delivering perceived benefits and new capabilities. By ensuring that the product / solution works & does what it’s supposed to do effectively (utility)

Some organisations are more aggressively focused on jumping and fast-tracking to design and delivery mode because of the bias to the traditional Project Management Triple Constraint.

They run the risk that without equal diligence to the Requirements Definition and Management process this will lead to short cuts & costly re-work (something we could discuss & debate for hours but a subject for another time & article.)
In the new business paradigm if these two models co-exist in equilibrium, and are used intelligently in alliance, the result is a more efficient Project Delivery environment achieving higher success rates. If used as mechanisms to compete / conflict with each other, this creates an unhealthy tension and often leads to lower Project and Product success rates.

To counter this mindset we as a profession need to be more assertive and demonstrate the wider value of Business Analysis, so perhaps it’s time we wield our own version of the Triple Constraint to show the business world.

With this final thought, I advocate it would serve the Business Analysis profession better by referring to this notion as the Business Analysis Value Chain (BAVC) rather than the term Business Analysis Triple Constraint.

Maybe I’m on the wrong track here but it kept me thinking for a while…What about you?

Business Analysis Value Chain

ronpurbaIMG01

Don’t forget to leave your comments below.