Some recent posts across the blatherverse have highlighted some considerations that we as good business analysts must employ when developing and delivering our documentation and deliverables. These got me to thinking about my own very strong feelings in the past about what I should be doing as an analyst and how my audiences should be receiving my contributions. How arrogant is that? Who do I think I am acting like that?
The story with me has been that if I am hired to create documentation and other deliverables for either my development or business audiences, they have an obligation to read what I’ve done for the sake of the project and organization. While I do still believe that is true, I have also spent the better part of a year observing my working environment and reading the posts of respected peers and experts regarding documentation, methodologies, bridging the gaps of communication, etc. Why? Because something has been gnawing at me about this scenario. Why is it that people are not using or reading what I deliver?
Well, the fact is that there is not much value in the physical or perceived weight of my deliverable. Think about it. There is a line of diminishing return as the page turns in a massive BRD; I’m sure one that steeply drops into the abyss somewhere around page 319. So the more people are reading, the less they are absorbing and processing for use in their real work.
I’ve been failing. Period. My audiences are diverse and very busy; they simply don’t have the time they need to do things the way they should. Also, as the business world has become more competitive due to many factors, there is less money to produce documents that no one reads. So, I’ve found myself in the middle of a metamorphosis that I’m sure will have Scott Ambler ringing my doorbell any moment. Alas, this is not Agile requirements that I’m talking about (yet). It’s figuring out how I can adapt to serve my customers (Business and Technical) and deliver to them what they need in smaller volumes, without ambiguity yet with enhanced clarity.
See if you can respond with exceedingly good ways to deliver quality requirements WITHOUT mentioning any methodologies or best practices.
>>Let Go of Your Big Thick Requirements Document
Check out the Business Analyst Template Toolkit – the set of requirements templates host Laura Brandenburg has been using to replace 50+ page requirements specifications with a sequence of shorter, actionable documents, most of which are less than 3 pages long.
Click the link below to learn more: