Requirements specification and the control <-> trust continuum 0

Posted on 10, September 2013

in Category bsg insight

This post was originally published on Unicom Seminars blog. It is reproduced here in its entirety.

It amazes me how often BAs cite a great, thorough, well considered specification as an indication of a job well done. A specification, as beautifully written as it may be, is only an input. A job well done is either a business change that meets a customer need or, perhaps informed by the specification, a decision not to progress a business change.

In fact, Business Analysis as a discipline is merely a means to an end (gasp!). As above, the end is a business change that meets customer need. In this world view, the work of BAs, developers, architects and all the other people who are involved in the design of business change provide the inputs to the change (specifications, architectures, code, etc.). The change itself is the output, and, at a further level of abstraction, the outcome of the change is whatever business benefit is derived as a result of the change being made.

Specification as control

So what is the point of the specification? No really – how much of the effort of writing the specification actually translates directly into observable benefit? My current estimation, instinctively, is probably the first 20% or so (double gasp!). The remainder is resolving differences of opinion between stakeholders, minutae in the exception handling and interminable review cycles. But we all want signoff, and without spending time on these things, signoff is withheld.

I guess that means much of the effort spent generating the specification is in order to create a control. It is a step which says “up to this point, everyone agrees that what I wrote down here represents requirement” and that’s important… right? The BA can use it as a benchmark to measure the output of the developers. In fact, in a frightening number of cases, it is thrown over the fence to developers and the BAs may have no more involvement until UAT.

But the control itself doesn’t actually progress achieving the output – the business change. If the project goes live and the requirements are wrong, the control may help in a he said/she said round of recriminations – but that doesn’t help anybody in the broader scheme of things. And yet, the desire to create a control is so strong that we willingly give up 80% of our specification time over to it. That doesn’t seem efficient. So what’s the alternative?

The shift to trust

The recognition that the ultimate output is the change means that we can also recognise that the BAs, developers and architects all collectively form one team brought together under one objective. The need to specify requirements in a structured format remains. The need to resolve every last issue before development does not. These realisations are at the cornerstone of all agile methods. Abstracting from the method to the interaction, the alternative to the control provided by the specification is trust in the agile process.

The agile process includes methods for eliciting and specifying requirements. As delivery teams tend to be multi-disciplinary teams focused on the output rather than individual input steps, communication across the team is much richer than a world of writing specs and throwing them over the fence. Cycle times are reduced because all the “noise” in the system is removed by virtue of improved communications and resolving detailed requirements issues at the point of development (rather than months before). Trust in the agile process replaces control.

David will be building on some of his thoughts at the Unicom conference on the 19th September in his talk entitled “Did BAs become irrelevant when business learned to code?”

Requirements specification and the control < > trust continuum/bsg insight

David Reinhardt
David is BSG UK's Regional Head and is really passionate about helping organisations effect meaningful change.

He will be presenting a talk, entitled "Did BAs become irrelevant when business learned to code?" at the UNICOM BA Conference 2013. This post was originally published to share some his thinking in advance of the conference.