Business analysts ought to be unselfish communicators.
What do I mean? To explain, I’ll cite a presentation by Dr. Michael A. Covington entitled, “How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily“.
I try not to be too superlative with my recommendations, but if you have not had a chance to page through Dr. Covington’s presentation, you really, really ought to. You’ll enjoy it, and you’ll almost certainly benefit from it. I know I did both.
In the presentation, Covington presents the concept of “The Unselfish Perspective”. I quote:
Good writing is partly a matter of character. Instead of doing what’s easy for you, do what’s easy for your reader. I’m not giving this presentation (or writing this paper) because I’m important. I’m not going to demand that you put up with my quirks (bad spelling, bad organization, sloppiness). I’m going to package the information so that it enters your heads as easily as possible.
Those, my friends, are words to live by! It isn’t enough to document things accurately and completely, although it is critical that we do. To increase the chances of delivering a successful solution, we ought to make it as easy as we can for our business stakeholders and delivery team members to understand and reach agreement on what success for the effort looks like.
In other words, you may be a great facilitator, an excellent “elicitor” of requirements; your analytical skills may be second to none, but if you can’t package and present information in an easily usable form, then you’re not really carrying the business analysis effort to completion.
So, borrowing/adapting the words of Dr. Covington, I give you the creed of the unselfish business analyst:
I will be an unselfish business analyst.
Instead of doing what’s easy for me, I will do what is easy for the reviewers and users of my deliverables.
I am not specifying requirements because I am important, but because those who will use them to deliver solutions that satisfy the requirements are important.
I will not demand that users of my requirements put up with my quirks (bad spelling, bad organization, sloppiness).
I will model and package the requirements so that they might be easily understood by those who will be using them.
The easier you make it to participate meaningfully in the requirements dialog and validation, the more willing stakeholders will be to fully invest themselves in it and the more they will want to work with you on future projects.
If you’ve never done it, or haven’t recently, I’d encourage you to ask a business stakeholder or a developer to help you out by listing a few ways you could make requirements easier for them to understand and use. I bet you’ll get at least a few ideas you wish you’d thought of sooner!
Go on, be an unselfish business analyst!
Comments