Since I completed my master degree at HEC Montreal back in 2006, I tried to maintain good relationships with my teachers. This gave me the opportunity to start teaching in 2008, as well as to give conferences to undergraduate and graduate students about the role of the business analyst in organizations.
At the beginning of 2015, one of my teachers asked me to come in one of her classes to give her students an idea of what I was doing on a daily basis as a Business Analyst. She was looking for applied examples so that her students could see how everything they learned in class relate to the real business world.
After some thinking, I decided that I would not show them examples of deliverables. After all, most of their classes were about methodologies and formalisms; my contribution would bring them little to no value. Instead, I decided to focus on the real added value of the business analysis delivrables, ie how we can use them beyond their primary objective.
In this upcoming series of posts (the first one on this blog!), I will bring you on a journey as a Business Analyst, to show you how your deliverables can fulfill much more than a pure requirements documentation objective.
BA deliverables as a collaboration tool
Business Analysis is mainly about communication, where your ultimate goal is to understand, summarize and communicate your stakeholders requirements. Therefore, most of your deliverables will be used to collaborate with these stakeholders and bring everyone on the same level of understanding.
From business processes models to detailed solution requirements and UML diagrams, your deliverables will be at the center of your work as a Business Analyst, and allow you to work more closely and efficiently with your stakeholders. This series’ first post will explore this dimension.
BA deliverables as a support tool
Many people in organizations (too many, actually) see business analysis as a one-step activity. You elicit requirements, have them approved, and you’re done. This is just wrong.
Once requirements documentation is completed, it must become the one and only reference regarding the solution to be implemented. Should anyone have a question about it, they should use this documentation as their bible.
However, BA deliverables cannot live by themselves; your role as a Business Analyst is to spread this knowledge among team members, and enforce a common understanding. The second part of this series will highlight how to achieve this.
BA deliverables as an insurance policy
With so much attention given to BA deliverables, it becomes more difficult to ignore them or go against them. Doing so would be quickly identified by all stakeholders who are relying on them.
This makes well-executed BA deliverables a good insurance policy against misunderstandings and change requests, since it makes the scope of a solution clear as crystal. This series’ last post will be about the protective value of your BA deliverables.
Using BA deliverables in productive ways, as described above, is only possible if these deliverables meet 2 objectives: quality and relevance. Our goal as Business Analysts is to meet those objectives.
Deliverables quality can be met through formal training on business analysis techniques, and through the use of standard frameworks (such as BPMN for process modeling). This is usually the easy part.
The relevancy objective is harder to meet, because it requires business and stakeholders knowledge. Quality is essential, but is not sufficient to make an deliverable relevant to your audience. As a BA, you need to tell an interesting story through your documents to captivate your audience, which can mean derogating from methodologies & standards (without sacrificing quality).
The key to good BA deliverables is to find the right proportion of both quality and relevance. Only then you’ll be able to use these deliverables properly.
Image credits: zachd1_681 @ flickr.com