Strings Attached: The Art of Adapting Templates in Business Analysis
I’ve recently started learning to play the ukulele. I made a decision early on that I’m not interested in learning ‘properly’, I don’t want to commit to formal lessons, I just want to try a fun new hobby. For that reason, the (very little) I’ve learned has been learned largely from YouTube.
When I say I’m not learning ‘properly’, I’m really just learning chords and tabs, I’m not reading sheet music and I’m pretty much just strumming along to the YouTube videos. That is perfectly fine for what I am aiming for, I never want to be a professional, I just want to play some simplified versions of songs I know.
In the dim and distant past I took piano lessons. Back then I could read sheet music (in treble and bass clef), knew about timing and some of the theory behind music. That knowledge has all gone now, and I have no idea how to play a piece of sheet music on the ukulele!
Now, you probably didn’t come here to read about ukulele playing, but there is relevance here, I promise! It’s all down to application within a context.
From Ukuleles To BA Templates
One of the things that I see a lot on social media is people asking for (and providing) BA templates. There’s a huge draw in using a template, it means that you don’t have to start from scratch. Things like templates and checklists can be very useful to make sure there’s consistency, and to make sure things don’t get forgotten. (I have a travel checklist for that very reason.)
Yet a template without an understanding of the underlying theory and rationale can be dangerous. It can lead to slavish adoption (“well, I need to put this diagram in, because there’s a section for it… the template is ‘best practice’ after all”). Just like my ukulele playing will always be restricted by my lack of music theory, someone who picks up a template without understanding why the template was created that way and what techniques can potentially accompany it will likely run into issues.
Advertisement
An Example: “BRD for the Financial Services Industry”
Let’s take an entirely fictional example and imagine that somebody produces a Business Requirements Document for the Financial Services Industry. It is pitched as a document that will likely be used in a waterfall or incremental delivery environment, and includes a context diagram, use case diagram, scenarios, functional requirements, non-functional requirements and so on.
It’s hard to criticize any of those sections, there will be times when all of those are useful. But what if the person picking it up doesn’t know what a context diagram is? Even if they do, the whole act of eliciting information to construct a context diagram is an artform in itself.
Or, what about if you’re making a tiny change to the label on a single field? Are you really going to fill in all of those sections? You might, in some circumstances, but in all probability something more lightweight would be appropriate. In fact, a prototype alone might suffice…
Of course, this is a deliberately provocative example, but I’m sure you see the point. There really is no ‘one size fits all’ in business analysis. So much is down to context, and understanding the context is key.
However: Templates Can Be Useful
It is worth clarifying here that I am absolutely not arguing against templates, nor am I arguing against the appropriate sharing of templates on social media. They are extremely useful, when used appropriately by skilled practitioners. They can even act as a guide to less-experienced practitioners providing this is accompanied by a desire to learn the underlying theory and techniques.
However, templates are also most useful when they are flexible. What works in one situation won’t work in all, so cut a section, or add a section! It’s important to think about the purpose of the artifact, its consumers and how persistent it is (i.e. how long it is expected to remain current for).
Like so much in change, pragmatic and intelligent application is what matters.