As a business analyst it’s important to know when to use the right tool for the right job. Although there is a wide range of tools available out there, some differ based on the methodology being employed, but often the end goal is the same. To assist in capturing valuable information and ensuring that it’s well communicated to all involved parties.
As I have mentioned in an earlier post, my background is in traditional waterfall projects. The tools of my trade were the lengthy functional specification documents, developed over time thanks to stakeholder interviews, document analysis and observation sessions. While these documents severed their purposes for the projects I was working on at the time, I have come to learn that they are not always the best tool for the job.
I have been faced recently with a number of scenarios where a long functional specification document is not beneficial and does not help to move the project on at all. Some examples of this include when:
Your client is not your end user
This is quite new to me but the firm I work for are often used as an outsourced technical partner. As a result the brief I get is often third hand and the answers I get during interviews are not accurate.Watch Full Movie Online Streaming Online and Download
Your client doesn’t realise the implications of changes
This can often happen for a number of reasons. In my experience it’s because either the project team have not helped set realistic expectations for the project, thus not limiting the scope. Another reason may be that the client is very technically unaware of software projects.
Your client does not know what they want
This is the client that says. “I’ll know what I want when I see it”. We’ve all worked with these sorts of clients, some are great because they allow you to be creative and innovative, and others can be just unrealistic.
The question is, how do you know which tools to use when projects and clients are so different? This will of course be a decision you make based on a number of factors, some of the things I think about at this stage are:
- Is the PM on the project a good one and will they be concentrating their time on this project or will they be tied up with others?
- Is there a fixed delivery date? What are the implications of missing it?
- Am I going to get access to some stakeholders or just a 3rd party?
- Have I done a similar project to this before? Do I know the domain?
The way that you are able to answer these may affect the tools you chose to use. For some projects it will be obvious which toolset you use, for others it may be a little trickier. In these cases I like to sit with the client and explain the possible approaches and the pros and cons for each. Offering a client the option between a formal document heavy process and an open collaborative process with lots of workshops could be the difference between having a nightmare client and having a champion within the clients organisation who believes in your team and the work you produce.
At the end of the day a BA’s role is to get alongside their clients, elicit requirements and communicate them in the most effective way possible. As long as you’re able to do this, it’s not really relevant the tools you used to do it.