si mahoma no va a la montaña… (Parte 1)

 roi cio

 

El área técnica lleva las de perder si espera a que el negocio valide los requisitos de usuario en términos que justifiquen la inversión.

¿Qué puede hacer la Oficina del CIO para agilizar los proyectos TI?

 

 

Si bien la responsabilidad de demostrar el retorno de la inversión en proyectos de TI corresponde al negocio, son la oficina del CIO (Chief Information Office) y el área técnica en general los que deben conciliar las expectativas del sponsor, asegurándose de proveer soluciones que realicen el valor de la inversión y que a la vez se ejecuten dentro de plazos muy justos.

Es lógico entonces que para que el área técnica pueda asumir la responsabilidad de realizar el valor esperado de una iniciativa, el negocio deba responsabilizarse de un traspaso claro de las expectativas y prioridades en cada hito crítico del proyecto, incluyendo la justificación del beneficio económico de cada requisito.

Aunque esto parezca obvio, muchas organizaciones carecen de mecanismos que aseguren la transferencia de dicha información, de negocio a TI, durante las fases iniciales del análisis.

Revisemos en alto nivel las fases de un proyecto TI, representadas en el diagrama adjunto como cinco compuertas que la iniciativa debe superar de manera sucesiva. En cada una de ellas el valor esperado de un requisito debe ser declarado, ajustado y transferido al siguiente stakeholder como parte de un acuerdo. El diagrama ilustra, de izquierda a derecha, desde los acuerdos iniciales en los que se acepta la propuesta de valor de la iniciativa en un caso de negocio (compuerta 1), hasta los criterios de aceptación necesarios para dar por concluido cada sprint durante la ejecución del proyecto (compuerta 5).

 

roi-for-projects-es.png

Antes que nada, recapitulemos lo positivo, repasando mecanismos que sí parecen estar implantados en muchas organizaciones:

Compuerta 1: Gracias a la adopción por parte de la oficina del CIO de la gestión estratégica del portafolio de proyectos, desde hace un par de decadas la jefatura de proyectos (PMO) exige un análisis empresarial de cada iniciativa estratégica. El análisis debe incluir las expectativas de retorno de la inversión, usualmente validado en un caso de negocio.

Compuertas 3, 4 y 5: Nuevamente, gracias a la adopción de buenas prácticas en la gestión de proyectos TI y de metodologías con enfoques iterativos (AGILE, Diseño Centrado en el Usuario, etc.) los expertos del área de negocio, responsables de procesos y productos, ya participan en la renegociación de prioridades y la validación del valor esperado de los requisitos. Sea durante el análisis de gaps (compuerta 3) la validación de las especificaciones funcionales (compuerta 4) o la certificación (compuerta 5).

Pero centrémosnos en la compuerta 2, la cual es crucial porque nadie espera que el área técnica se embarque en un análisis de gaps basándose únicamente en un caso de negocio. El diseño de la solución necesita como punto de partida una validación de todos los requisitos de usuario, independientemente de la tecnología que se baraje para satisfacerlos. Dicha validación es responsabilidad de los expertos en procesos y productos, es decir, es extrictamente responsabilidad del negocio, no del área técnica y debe incluir:

1) Una estimación de los beneficios que realizaría el negocio si el requisito es satisfecho.

2) La trazabilidad de cada requisito a al menos una necesidad de negocio validada por el sponsor del proyecto, además de un mapeo entre requisitos interdependientes cuando se de el caso, de tal modo que se pueda analizar el impacto en el valor del proyecto cuando de priorizan los requisitos.

Si los responsables de procesos y productos en la organización no logran establecer estas estimaciones y dependencias en el conjunto de requisitos de usuario por si mismos y la iniciativa sigue adelante, el impacto sobre las responsablidades del área técnica se hace evidente:

Gap in ROI accountability Sin la validación de la rentabilidad esperada de los requisitos de usuario (Compuerta 2) el área técnica se encontrará utilizando recursos propios del diseño de la solución para completar las carencias en el análisis del negocio, el cual debería haber sido realizado por el negocio internamente.  

Traceability on ROI Si bien no se espera que los proveedores de TI se enfoquen en el ámbito del negocio al diseñar la solución, si intentan priorizar y reconstruir la trazabilidad entre los requisitos de usuario y la rentabilidad esperada del proyecto, su análisis es percibido como una demora en la ejecución, porque desde el punto de vista del Sponsor "las necesidades del negocio (compuerta 1) ya están validadas". De pronto un problema originado estrictamente en el ámbito de negocio se convierte en un obstáculo y "responsabilidad" del área técnica.

¿Qué pueden hacer la oficina del CIO y la jefatura de proyectos para garantizar el control en la compuerta 2 y a la vez agilizar el proyecto?

La solución a esta carencia en los entregables obtenidos de negocio está fuera del alcance del jefe de proyecto. En la mayoría de organizaciones no es sino hasta que se inicia la fase de diseño cuando el área técnica detecta la falta de priorización y de validación en requisitos de usuario.  Pero TI no puede esperar a que el negocio establezca estandares mínimos y buenas prácticas en la gestión de requisitos precedente al diseño. Esto no ha sucedido en veinte años y quizá nunca suceda en los próximos veinte. No es un problema de falta de metodología o herramientas sino un resultado de cómo se presupuestan los proyectos: 

El levantamiento y validación de requisitos de usuario es confundido y postergado junto al análisis de gaps de manera sistemática en los planes de proyecto, como si fuese responsabilidad del área técnica y no del ámbito de negocio.

La solución: Si mahoma no va a la montaña, la montaña va a Mahoma. Tendrán que ser la oficina del CIO y la PMO quienes tomen la iniciativa y auspicien el análisis de negocio y la validación de los requisitos de usuario desde sus presupuestos, como una condición previa al diseño de la solución.

Es en estas cisrcunstancias cuando el analista de negocio asume el rol de acelerador de proyectos. Enviado por la jefatura de proyectos, el BA descompone el impacto en el negocio del cambio en los procesos, propone alternativas en el ámbito del negocio a las soluciones técnicas y facilita de los stakeholders la validación de una línea base de requisitos de usuario que justifique la inversión en TI.

 

   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