Babok® task: Planning the Business Analysis Approach
We are all familiar (business folks and technologists) with the typical business analysis work carried out during IT projects (the requirements workshops, interviews, documentation, etc.) however, beyond these visible activities, there are a few less known tasks, like planning the business analysis approach for a project, which are also important to ensure that business analysis is well-executed and fully integrated into the project management process.
As depicted in the diagram below, in ITIL contexts, planning the business analysis approach could take place during Service Strategy(1), as an organization approves a business case and is initiating the design stage for a new or changed service:
What is planning the business analysis approach?
The business analysis team needs to pause for a moment and consult with stakeholders to determine the best approach to perform all business analysis work required to charter the service: How and when in the project lifecycle will business analysis tasks be performed, what techniques will be used, and what deliverables will be produced.
Even though adapting business analysis activities to waterfall, AGILE, or any hybrid software delivery methodology would first come to mind to many technologists, the choice of a business analysis approach is not limited to Business Analysis work during Service Design and Service Transition. The approach should also address which techniques and workflows will be employed to deliver business requirements during Service Strategy, before solution designers come into the picture!
Why is planning the business analysis approach important to the project?
As the Business Analysis approach is documented, it becomes an input to carry out subsequent business analysis activities, but more importantly, its delivery provides the project manager with an early opportunity to discuss and manage expectations on project scheduling and costs, by incorporating preliminary considerations on business analysis efforts. The diagram below, points to several stakeholders who would participate in this exchange:
Even if the degree of formality or definition of the business analysis approach varies depending on the organization or the type of project, BABOK 2.0 points to some key issues the business analyst should consider when deciding on an approach:
Timing of business analysis work: How much and when would business analysis work be allocated during the project?
Level of detail and formality of deliverables: With what degree of fidelity and formality are requirements going to be defined in each project phase or iteration?
Prioritization criteria: Based on the business needs, what criteria would be important for project owners and sponsors when prioritizing among requirements, and how these criteria would shape the scope of a solution?
Change management process: What would be the overall workflows and approvals required when managing change in requirements?
Business analysis planning process: What would be the overall workflows and approvals required to plan the execution of business analysis activities, and how will business analysts ensure their planning will be compatible with the PM’s overall project plan?
Business analysis communications approach: What would be the ground rules on the level of formality and frequency to be employed in communications during business analysis activities?
Requirements analysis and management tools: What tools would be made available to business analysts during project to manage and analyse requirements, and how compatible would they be with the approach employed.
Project complexity: How would business analysis work adapt to additional project complexity (large number of stakeholders, significant stake on maintaining security, number of lines of business affected, critical dependencies among systems, expensive technical resources required, etc.)
(1) Notes on BABOK® and ITIL®
BABOK 2.O describes Planning the Business Analysis Approach extensively, but we have to stress that BABOK is not prescriptive on when and how this task (or any of the other 31 BA tasks listed in BABOK) should be carried out by the business analyst. BABOK only makes a point on the possibility of executing the task, whenever the inputs required to execute it are available.
In our own practice we find that it makes sense to start planning the business analysis approach during the initiation phase (after the business case has been approved and before the project is chartered). Specifically in ITIL, this task would be executed by the business analyst during Service Portfolio Management, as part of the sub process Approval of New or Changed Services:
We also find that sometimes an additional iteration would be needed during Service Transition, as the BA approach sometimes is adjusted to accommodate the finalized solution approach during delivery and validation. Some light planning on approach might also be needed for business analysts to help deliver the business case.
ITIL v3 deals extensively on requirements engineering during Service Design, but falls short of addressing an end-to-end approach to requirements management. I believe that in practice, defining and analysing the new or changed services during service strategy, requires a similar or greater business analysis effort in requirements management than during Service Design. ITIL v3 assumes that the line of business delivers a complete set of business requirements to initiate Service Design, but does not focus on the requirements management work, strictly on the business domain (solution neutral) that is needed to deliver these business requirements (We have covered this issue in a previous article).
This is a constructive observation on ITIL v3. I believe ITIL is a very comprehensive framework that has shifted its focus increasingly towards the strategic alignment of IT services. BABOK has championed the role of the BA as critical to ensure this alignment from the start, and for this reason I believe it makes an excellent complement to ITIL.
Learn more about our end-to-end requirements management approach in ITIL contexts.
ITIL® is a registered trademark of the Cabinet Office in the United Kingdom and other countries. BABOK® is a registered trademark owned by International Institute of Business Analysis
September 10th, 2013 By Larry Velarde, CBAP®