I often hear that we need a business analyst to translate what the business people say, so that technical people understand them. Then, I am told we need the BA to then translate what the technical people say, so that the business people understand them.
I guess it goes something like this:
It sounds good, but actually I don’t think it is true.
I have been told that use cases are very old fashioned now and that all the cool people have moved onto agile user stories.
But I am old school and I still like to pull the old approaches out every now and then and take them for a spin.
I found myself explaining use cases in both a lecture (where the company wanted me to explain them to the BA teams) and a small team where people had been doing use case diagrams but not really use cases. Then I got asked in a BA course – “do you use stories for agile projects and use cases for waterfall ones?”
My answer was “it depends – probably just ask the BA”. But the student responded that she was a BA and that all the other cool BA’s would make fun of her if she wore the wrong clothes to school or used the wrong tool on the wrong project.
I have been doing some business analyst training recently and I spoke about a “trade-off matrix” a couple of times. A couple of people have asked for a good link to explain what one is and why they are so cool. So I looked on the web and couldn’t find anything decent enough to send through.
So I thought I would describe what a trade-off matrix is here. I will also briefly mention why they are useful and then mention a couple of variations that people might not have heard of.
Quite some time ago, I wrote an article on “creating a basic communication plan” and for many projects that is all you need.
But sometimes it is worth analysing your stakeholders in more detail. This article explores a couple of approaches that I like to use when I need to understand more about my end users or more about my “project stakeholders”.
Continue reading “Analysing stakeholders – beyond the basic communication plan”
