Las actividades de un analista de negocios en implantaciones de ITIL® (Parte 1)


Planning BA_Approach

 

 

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:

ITIL Service_Strategy_BABOK_Plan_BA_Approach

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:

ITIL Service_Strategy_BABOK_Plan_BA_Approach_Stakeholders

 

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:

BABOK- Timing of BA work Timing of business analysis work: How much and when would business analysis work be allocated during the project?

BABOK - Level of detail and formality of deliverables 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?

BABOK - Prioritization criteria 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?

BABOK - Change management process Change management process: What would be the overall workflows and approvals required when managing change in requirements?

BABOK - Business analysis planning process 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?

BABOK - Business analysis communications approach 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?

BABOK: Requirements analysis and management tools 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.

BABOK - Project complexity 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:

ITIL Service_Strategy_BABOK_Plan_BA_Approach_Mapping

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.

Read part 2 (another BA practice: Stakeholder Analysis)

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®

 

 

 

Leverforce  Copyright 2016 Leverforce Inc. Reservados todos los derechos. CBAP® es una marca registrada perteneciente al International Institute of Business Analysis. La marca de esta certificación es utilizada por los analistas de negocio que poseen la certificación CBAP, con el permiso expreso del International Institute of Business Analysis. IIBA®, el logo IIBA®, BABOK® y Business Analysis Body of Knowledge® son marcas registradas pertenecientes al Institute of Business Analysis. Estas marcas son utilizadas con el permiso expreso del International Institute of Business Analysis. 

Condiciones legales de uso y acceso a este sitio web

Módulos SAAS

  • Módulo: Necesidad de Negocio +

    Este módulo permite gestionar un listado de las necesidades de negocio asociada al análisis. Cada necesidad define lo que el cliente o el impulsor de la iniciativa (sponsor) busca obtener con los cambios solicitados en servicios TI, en términos de eliminación de problemas, mitigación de riesgos o aprovechamiento de oportunidades en su negocio. Read More
  • Módulo: Requisito de Usuario +

    Este módulo permite gestionar un listado de los requisitos de usuario asociados a una o varias necesidades de negocio. Un requisito de usuario explica un comportamiento o condición que el usuario necesita de un servicio TI para satisfacer la necesidad de negocio. Read More
  • Módulo: Requisito Funcional +

    Este módulo permite gestionar un listado de los requisitos funcionales asociados a uno o varios Requisitos de usuario. Un requisito funcional (Prefijo SLR) es la propuesta inicial del proveedor de TI que explica lo que hay que construir/cambiar en un servicio TI para que el usuario pueda disponer del comportamiento o condición solicitado en el requisito de usuario.. Read More
  • 1
  • 2
  • Modelio UML Tool +

    Leverforce permite la entrada de elementos UML (Casos de uso, Actividades, Actores, etc) desde la herramienta de modelado Modelio, vía la importación de archivos XMI. Read More
  • JIRA Issues +

    Set up JIRA projects from Leverforce’s SLA or Product Increment Modules. Read More
  • 1