Picture me: young, fresh, and disciplined…leading a very boring requirements meeting where we’re poring over a very laborious requirements document. This was way back when I was too new, too green, to know better.
I had a template, a big one in fact. It had 20, maybe even 30 sections in it. And my discipline led me to believe that putting something in each and every one of those sections was the best way to be effective as a business analyst.
After all, someone wouldn’t have added it to the template if it wasn’t important, right?
So, what could go in this particular section?
If I didn’t have an idea, I’d ask the project team. After all, that’s what I’d seen the other BAs do when I was sitting in on their requirements meetings.
So I’d ask. And wait. And think. And struggle a bit.
And by now we are all feeling a bit squeamish and uncomfortable. That hot-head architect is just dying to take a pot shot at me and start a discussion about the template itself and completely derail my meeting. I can feel it coming.
“Oh! What about this?” says the product manager.
{collective sigh of relief}
Yes, that works, a few people nod.
I write a note.
We move on.
Of course, I know that we’ve already captured “this” in another section and I’m crossing my fingers under the conference room table that the uber-smart architect doesn’t call me out on it. But since it also fits here, I can decide how to handle the duplication when I get back to my desk. For now, I’m quickly moving on to a more interesting part of this particular requirements review meeting before anyone else notices.
{fast forward a few years}
I switch organizations and am responsible for starting a new BA practice-of-1. One day while working on a draft of my requirements specification, I realize that I own this. No one at this organization has ever seen this template. No one. They won’t know if I just remove a section or two or three or (yikes!) four and let it die a slow and painful death on my PC.
I think about the pros and cons of this decision.
- I realize that I’ve been letting the templates be my master instead of mastering them.
- I realize that as safe as it feels to fill in every section of a trusted template, it’s not safe at all, especially if no one is reading the thing.
- I realize that I can choose a better way.
My business analysis life starts afresh. I will do better. I will write better. I will serve better. Over the course of the next several years, a transformation happens.
- Instead of thinking big, I start to think small.
- Instead of thinking fill in the blank, I think about decisions and next steps.
- Instead of thinking about an abstract sense of completeness, I think about usefulness.
It all starts with losing my dependence on the long, laborious templates that felt very, very safe. Somewhere along the way I shed my greenness and while I keep my discipline, I apply it using a different set of principles. Somewhere along the way, my requirements start to get just a little bit spunky.
From time to time, I still look back.
I wish that way back when I had the license to cut up my templates so that my documentation would have been shorter and relevant and my meetings less painful.
I wish that way back when I had a more concise starting point so that my documentation would naturally be more readable.
I wish that way back when I was told to add if needed instead of play a game of fill-in-the-very-large-set-of-blanks.
I can’t get back the hours I wasted and the spunk I sucked out of those early requirements documents (and their meetings). But I can give you a simpler starting point.
And that’s exactly what I’ve done with the Business Analyst Template Toolkit. The templates are short and you are welcome to add or subtract. The Toolkit also includes work samples so you can see exactly how the template works and what it helps you accomplish in your requirements documentation. And a guidebook walks you through my approach so you can use it as a starting point for your next project.
I wish I had a lighter starting point way back when, so I wouldn’t have had to learn how to streamline my documentation in a much more painful way. And that’s why I’ve annotated my templates and am sharing them with the business analyst community.
>>Learn More About Templates and Requirements
Click on one of the links below to learn more about how we approach templates and requirements:
