A LinkedIn update from Giles the other day read “Working on more reliable mechanisms for the transfer of the underdocumented elements of business analysis. Osmosis doesn’t quite cut it.” I’m not sure what exactly he meant (is underdocumented a word) but I joked that perhaps he should use the ‘back of a fag packet’ approach. It got me thinking about requirements and the how best to share them and ultimately get them signed off.
What is a good requirement? Well there are a lot of definitions which I won’t even attempt to re-write or challenge, so I thought I’d share some characteristics of good requirements. This list is found in Wikipedia.
Almost all BA’s I have either worked with or have spoken to have the same issue. Stakeholders rarely officially sign off the scope and requirements documents, and even more rare is the formal following of any change control of the requirements post sign off. As a BA how do we share 25, 50 or a 100 requirements with the project stakeholders in a format that lends itself to validation further down the line whilst keeping their interest? A single spreadsheet or 75 page word document will not be read/understood by all parties – it’s just the curse of large requirements documents.
How do I approach it? Most of my projects have followed a classic scenario for law firms ‘the product has been chosen, we just need it to fit to our requirements’. So it’s a lot of system configuration, implementation and process mapping. I think the challenge Giles was referring to would be more about the system design and less about a product but I think broadly it’s the same challenge just a slightly different audience.
Broadly speaking my approach is not best practice and may not fulfill any particular methodology entirely but it seems to have been ok so far in my career. My blended approach is to contain my document writing to a minimum; an initiation document, the high level requirements and stakeholder analysis, ensures that the main bases are covered and the project is going in the right direction with the right people. In conjunction with the main document set, I combine prototypes and use cases to flesh out specific part os the system, process or product. They a ‘picture speaks a 1000 words’ and for me these ‘pictures’ are easy to share and discuss with the project stakeholders which helps ongoing validation and eases the pain of sign off. Ultimately it means I am more visible and not hiding for a month creating a behemoth of a document with no guidance.
All three, combined with the increased stakeholder engagement, form my blended approach which hopefully provides a clearer and more concise set of requirements. Getting sign off will always be a challenge but hopefully easier. Of course there are some projects which I can’t avoid a larger document set and inevitably within them are the infamous 200 page requirements documents, it’s safe to say the stakeholders don’t like reading those almost as much as I don’t writing them.
Your feedback is always welcome.