Let’s talk ‘concise’

*** Find an example.

As part of your BA role, are you tasked with writing lengthy requirements or functional specifications. This is certainly something something I’ve seen in my work. When completing these documents, do you take pride in that 3-digit page count? A testament to the volume of work you have produced?

This post invites you to challenge that metric. If there was a means to reduce the length of the document - should you? The answer is, ‘absolutely’. In most cases, there a number of ways such a document could be reduced in size.

Before we talk ‘how’, let’s take a minute to consider the hidden costs associated with monolithic documents.

QUALITY FEEDBACK

  1. Getting people to read it. As riveting as your “XZY Interface Specification” sounds, at 200 (dry) pages. There is risk that stakeholders won’t read it, will be lax in providing feedback, or simply lose concentration - and fail to notice detail.

WEIGHT ON OTHERS TIME

  1. Handover. Consider that eventually this document will be absorbed as an input into Technical Design, Architecture, Development, Test, and User Documentation, work streams. Put an hourly rate on each these stakeholders, and consider the cost of their time to read your document. Any aspect that has been described in 2 pages, when 1 page would do - represents wastage.

PERSONAL BRAND

  1. Consider what it might feel like to be overwhelmed by a monolithic document (or conversely, consider the ease in reading a well-written document). As a regular consumer of such documents, you want the authors to make your inputs through - yet easy to consume. If the document fails to meet this criteria, it’s author is not doing their share of the job. Poor authors can quickly gain reputation as repeat offenders.

So how do you do concise?