As a Business Analyst we are dependent on our communication skills and our experience with handy analysis techniques to elicit excellent requirements. A successful interaction with our business and IT stakeholders involves choosing the right technique to fit the project, the problem, and the stakeholders. The choice will definitely influence a facilitated session outcome, the amount of stakeholder participation, and the quality of your requirements. With the right technique, you can gain critical insights into your business problem whereas picking the wrong one may lead you down the wrong path, or get everyone stuck debating trivial problems and requirements. Even worse – if the technique is confusing, requirements errors may not be discovered by the group. A good technique is understood by all necessary stakeholders and clears the path toward the required solution.
Do you have a technique that has worked well with your stakeholders? Share your success story. Here’s one that I like:
The Context Level Data Flow Diagram is an example of a great technique to use at the beginning of a project to give everyone a high-level, shared understanding of what will be included in the project. The Context Level DFD is visual and uses only three symbols, and so it is easy to explain and understand. The process of drawing a Context Level DFD involves a logical step-by-step procedure where you will ask the stakeholders certain questions which will drive how you draw the diagram. Ultimately the group determines the boundaries of the project and all the external systems, organizations, or roles that interact with the project. While building the diagram, you guide the group through questioning to identify and prioritize critical information, reconcile any differences, and finally gain their consensus on the business areas to be further investigated. The technique also helps the stakeholders quickly identify whether the project is too large. A diagram that looks confusing and complex usually indicates that the project is too big and may pose a business risk. A good Context Level DFD illustrates in a clear, unambiguous birds-eye view the scope of the project, its boundaries and interfaces. The process of reaching stakeholder consensus results in much more than the simple diagram. The best thing about this technique for me is when I am done; I have a great starting point to focus my investigation and my stakeholders have a shared understanding of what the project is about.
- Being part of the solution - May 1, 2012
- What’s the difference between ordinary and extraordinary… - March 14, 2011
- Lots of resources to learn about agile - May 10, 2010
- Agile and the BA – Part 1 - March 23, 2010
- Is It Really Tyranny of Best Practices? - February 20, 2010
- BAs are Bridge-Builders Instead of Bridges - January 25, 2010
- James Bond and Business Analysis - January 18, 2010
- Should the BA scribe at a team meeting? - August 4, 2009
- Why do we need detailed business requirements? - July 28, 2009
- Updated CBAP® Handbook now available for download - July 14, 2009