Toda empresa debe adaptarse a los cambios del mercado y reestructurar su negocio. ¿Cómo? A través de proyectos, programas e iniciativas de transformación complejas. Desde hace décadas hablamos de portafolio, programa, proyecto y, más recientemente, también de «épica». Sin embargo, hasta ahora ha faltado algo: un término genérico común que agrupe lógicamente estos niveles y describa cómo las organizaciones estructuran su trabajo para lograr un resultado.

Es precisamente aquí donde entra en juego un nuevo concepto:

Estructura de Entrega de Resultados (Outcome Delivery Structure, ODS): el conjunto de todos los niveles estructurales que sirven para lograr un resultado.

La ODS es un enfoque moderno e independiente de marcos de trabajo que no reemplaza los niveles conocidos, sino que los organiza de manera más clara.

Por lo tanto, la ODS abarca:

• estructuras de proyecto clásicas (PMI, PRINCE2)
• estructuras ágiles (Scrum, SAFe)
• modelos híbridos (SAP ActivateMetodología oficial de SAP para la implementación de SAP S/4HANA con seis fases (desde Discover hasta Run) y enfoque en la estandarización, la agilidad y el cumplimiento normativo.)
• modelos orientados a servicios (ITILMarco para la gestión de servicios de TI con procesos definidos.)

1. Estructuras jerárquicas clásicas

Entre las estructuras jerárquicas clásicas se incluyen:

• Cartera, Nivel 1: resumen estratégico de todas las iniciativas
• Programa, Nivel 2: grupo coordinado de proyectos relacionados
• Épica, Nivel 3: unidad de trabajo de gran envergadura, subdividida en proyectos
• Proyecto, Nivel 4: resultado claramente definido con fecha de inicio y de finalización
• Tarea, Nivel 5: la unidad operativa más pequeña

2. La jerarquía ágil (SAFe y Scrum)

En un entorno ágil escalado (SAFe), los términos se integran directamente en la estructura existente:

• Épica (nivel de cartera/solución/programa): se encuentra en el nivel más alto. Describe una iniciativa grande y estratégica (p. ej., «Desarrollo de un nuevo portal para clientes»).
• Característica (nivel de programa): una épica se divide en características (p. ej., «sistema de inicio de sesión» o «resumen de facturas»).
• Historia de usuario (nivel de equipo): Las características se subdividen en historias de usuario para su implementación (p. ej., «Como cliente, deseo poder iniciar sesión con mi dirección de correo electrónico»).
• Sprint (marco temporal): Un sprint no es una unidad de trabajo jerárquica, sino un marco temporal (por lo general, de 2 a 4 semanas). Dentro de este marco, el equipo trabaja en una selección de historias de usuario.

Visualización de la jerarquía de SAFe con unidades de tiempo:

1. Portafolio / Solución (estrategia)
2.      ↳ Épica (meses a trimestres)
3.           ↳ FuncionalidadFuncionalidad individual dentro de un producto o servicio. (cabe en un PI / Incremento del programa, aprox. 8 a 12 semanas)
4.                ↳ Historia de usuario (cabe en un sprint, unos días)

3. Clasificación en SAP Activate

SAP Activate combina conceptos ágiles con las fases tradicionales de un proyecto:

• Épica: corresponde a un resultado esencial dentro de un flujo de trabajo (por ejemplo, en el flujo de trabajo «Diseño y configuración de la aplicación»).
• Historia de usuario: En el contexto de SAP, esta suele registrarse en el backlog durante la faseSección delimitada en el tiempo y en cuanto al contenido de un modelo de procedimiento para centrarse en determinados objetivos, actividades y resultados. de exploración. Concretiza los requisitosRequisitos que pueden dar lugar a cambios y, en el nivel más básico, corresponde a las tareas que se implementan en el sprint.
• Sprint: Se lleva a cabo principalmente en la fase «Realizar». Aquí se implementan y prueban las historias de usuario priorizadas en el backlog mediante ciclos iterativos (sprints).

4. Clasificación según PMI e ITIL

• PMI (Clásico e Híbrido): Una «épica» corresponde a una fase transversal o a un paquete de trabajo de gran envergadura en el plan de estructura del proyecto (PSP/WBS). La «historia de usuario» es la actividad específica y detallada. El «sprint» reemplaza la secuencia temporal clásica y rígida por segmentos cortos e iterativos.
• ITIL (flujos de valor): Una «épica» y sus «historias de usuario» son los requisitos específicos que fluyen a través de un flujo de valor. La implementación de las historias de usuario dentro de un «sprint» forma parte de las actividades «Diseño y Transición» u «Obtención/Construcción» y, en última instancia, aporta un valor agregado al cliente.

5. La brecha conceptual en todos los marcos de trabajo

Contamos con términos perfectos para los niveles estructurales (portafolio, programa, épica, característica, proyecto, historia de usuario, tarea), pero no disponemos de un solo término adecuado para el estado del producto de entrega mientras este aún no se encuentre en producción en el ODS.

En mi libro sobre la gestión de la transición de SAP ya he definido claramente qué se entiende por «entregables» y «tipos de resultados».

Definición: Entregable
Un entregable es un documento o artefacto tangible (por ejemplo, el plan completo de transición), que está listo para su aceptación, cuenta con una versión y ha sido aprobado formalmente.

Definición: Tipo de resultadoHito o resultado parcial (p. ej., aclaración de roles) que se genera y documenta en el marco de un elemento de entrega.
Un tipo de resultado (Outcome) es un hitoMomento del proyecto en el que se debe alcanzar un avance definido; sirve para el control del tiempo y el progreso. o un resultado parcial (p. ej., taller con las partes interesadas, aclaración de roles) que se genera, se registra y se integra en el contexto general en el marco de un elemento de entrega.

Ejemplo: La definición de las responsabilidades es un «tipo de resultado»; se integra en el entregable «Matriz de roles y responsabilidades».

Sin embargo, existen dos tipos de resultados en un proyecto. Algunos se refieren al alcance del proyecto (Project Scope), otros al alcance del producto (Product Scope), para utilizar la terminología del PMI. Por lo general, solo los resultados que se refieren al alcance del producto son transferibles a la producción; es decir, son relevantes para la migración (cutover(i) Fase del modelo de 5 fases: ejecución de la transición a producción; incluye la conmutación técnica y la implementación operativa. (ii) Transición puntual de un proyecto al entorno de producción. (iii) Fase de transición a producción de un sistema de TI, a menudo bajo presión de tiempo y con un alto nivel de coordinación.). Se podría ser minucioso en este punto y argumentar que algunos resultados del alcance del proyecto sí podrían transferirse, como por ejemplo, los conocimientos adquiridos.

Ejemplo: La prueba de integración del sistema (SIT) y la prueba de aceptación del usuario (UAT) son entregables dentro del alcance del proyecto. Aunque constituyen criterios de aceptación para la transición, no se transfieren. Las configuraciones del sistema, los nuevos flujos de procesos, el personal capacitado y los documentos listos para su uso en producción son resultados transferibles.

Y aquí está el término que faltaba: Entregable preoperativo (POD)

Definición: Entregable preoperativo (Pre-Operational Deliverable, POD) frente a entregable operativo (Operational Deliverable, OD)

Un entregable transferible es un entregable preoperativo (POD) mientras aún no esté en producción. Durante la transición, un POD se transfiere a un OD, es decir, a un entregable operativo

6. Resumen

La transición (cutover) convierte los entregables preoperativos (POD) en entregables operativos (OD). Esta transición operativa siempre se refiere a la estructura de entrega de resultados (ODS) seleccionada. Por lo tanto, tiene sentido hablar de una transición específica del proyecto, del programa o de la cartera, según la ODS a la que nos refiramos.