gestión del alcance del programa

GOP040v2 – Curso Gestión de Programas

Material de Lectura Nº 02 v1

CAPÍTULO

GESTIÓN DEL ALCANCE DEL PROGRAMA

5.1 PLANIFICAR EL ALCANCE.5.2 DEFINIR LAS METAS Y OBJETIVOS DEL PROGRAMA.5.3 DESARROLLAR LOS REQUERIMIENTOS DEL PROGRAMA.5.4 DESARROLLAR LA ARQUITECTURA DEL PROGRAMA.5.5 DESARROLLAR LA EDT DEL PROGRAMA.5.6 GESTIONAR LA ARQUITECTURA DEL PROGRAMA.5.7 GESTIONAR LAS INTERFACES DEL COMPONENTE.5.8 MONITOREAR Y CONTROLAR EL ALCANCE DEL PROGRAMA.

La Gestión del Alcance del Programa identifica los entregables, estima los riesgos importantes, y establece la relación entre el alcance del producto y el alcance del programa, al mismo tiempo que determina los estándares para objetivos claros y posibles de alcanzar (Figura 5–1).

5.1 Planificar el Alcance: El proceso de identificar y desarrollar actividades para producir los productos entregables y los beneficios que satisfacen las metas y objetivos del programa.

5.2 Definir las Metas y Objetivos del Programa: El proceso para establecer las metas y objetivos generales del programa y de lo que se va a entregar al final.

5.3 Desarrollar los Requerimientos del Programa: El proceso para el desarrollo e identificación formal de los requerimientos y especificaciones del programa para entregar las metas y objetivos del programa.

5.4 Desarrollar la Arquitectura del Programa: El proceso de definir la estructura de los componentes de los programas e identificar las interrelaciones entre todos los componentes del programa.

5.5 Desarrollar la EDT del Programa: El proceso para subdividir el programa en sus partes constituyentes (componentes, entregables, y actividades). Proporciona una descomposición jerárquica orientada al producto entregable del trabajo que será ejecutado y logrado por cada componente del programa.

5.6 Gestionar la Arquitectura del Programa: El proceso para gestionar las relaciones entre todos los componentes del programa para asegurar que la arquitectura del programa permanezca actualizada.

5.7 Gestionar las Interfaces del Componente: El proceso para mantener la adherencia de la entrega del programa y sus partes constituyentes y para gestionar las relaciones entre los componentes del Programa.

104

2



5.8 Monitorear y Controlar el Alcance del Programa: El proceso para asegurar que el alcance del programa se controle de manera que cumpla con las metas acordadas y realice los objetivos y beneficios acordados del programa y que se han identificado en el acta de constitución del programa.

Estos procesos interaccionan entre sí y con los procesos de las demás Áreas de Conocimiento. Cada proceso implica el esfuerzo de una o más personas o grupos de personas, de acuerdo a las necesidades del programa. Cada proceso tiene lugar por lo menos una vez en cada programa y se produce en una o más fases del programa, si el proyecto se encuentra dividido en fases. Aunque los procesos se presentan aquí como componentes discretos con interfaces bien definidas, en la práctica pueden superponerse e interactuar en formas demasiado complejas como para abordarlas en detalle aquí.

En el contexto del programa, el término alcance puede referirse a lo siguiente:

Alcance del Producto: Las características y funciones que caracterizan un producto, servicio, o resultado.

Alcance del Programa: El trabajo requerido para entregar el producto, servicio, o resultado de beneficio principal con las características y funciones específicas a nivel del programa.

105

Gestión del Alcance del Programa

5.2 Definir las Metas y Objetivos del Programa.1 Entradas

.1 Enunciado del Alcance del Programa

.2 Plan de Gestión del Alcance del Programa

.2 Herramientas y Técnicas

5.1 Planificar el Alcance del Programa.1 Entradas.1 Caso de Negocio.2 Acta de Constitución del

Programa.2 Herramientas y

Técnicas.1 Juicio de Expertos

5.3 Desarrollar los Requerimientos del Programa.1 Entradas


.2 Solicitudes de Cambio

.3 Caso de Negocio

.4 Mapa de Ruta del Programa

5.4 Desarrollar la Arquitectura del Programa.1 Entradas

.1 Documento de los Requerimientos del Programa

.2 Herramientas y Técnicas.1 Conocimiento Técnico

.3 Salidas



Figura 5–1. Descripción General de la Gestión del Alcance del Programa.

5.1 Planificar el Alcance del Programa

La planificación del alcance es el proceso de identificar y desarrollar actividades para producir entregables y beneficios que satisfacen las metas y objetivos del programa (Figuras 5–2 y 5–3). Los elementos que se consideran en esta actividad incluyen:

Análisis de los stakeholders,

106

5.2 Definir las Metas y Objetivos del Programa.1 Entradas



.2 Herramientas y Técnicas

5.1 Planificar el Alcance del Programa.1 Entradas.1 Caso de Negocio.2 Acta de Constitución del

Programa.2 Herramientas y

Técnicas.1 Juicio de Expertos

5.3 Desarrollar los Requerimientos del Programa.1 Entradas



.3 Caso de Negocio


5.4 Desarrollar la Arquitectura del Programa.1 Entradas


.2 Herramientas y Técnicas.1 Conocimiento Técnico

.3 Salidas

5.8 Monitorear y Controlar el Alcance del Programa.1 Entradas


.2 Solicitudes de Cambio Aprobadas

.3 Solicitudes de Transición del Componente

.4 Plan de Gobierno

.5 Línea Base de la Arquitectura del Programa

.6 Plan de Gestión del Programa

.2 Herramientas y Técnicas.1 Juicio de Expertos.2 Reuniones de Revisión.3 Toma de Decisiones.4 Auditorías.5 Sistemas de Información de

Gestión del Programa.3 Salidas.1 Solicitud de Cambio

Aprobada.2 Actualizaciones de los

Requerimientos del Programa

.3 Actualizaciones del Plan de Gestión del Programa

.4 Actualizaciones del Enunciado del Alcance del Programa

.5 Actualizaciones del Depósito de Documentos del Programa

5.7 Gestionar las Interfaces del Componente.1 Entradas




.4 Plan de Gestión de Comunicaciones

.5 Pautas de Gestión de los Stakeholders del Componente

.2 Herramientas y Técnicas.1 Juicio de Expertos.2 Métodos de Comunicación.3 Reuniones de Revisión.4 Técnicas de Gestión de

Conflictos.3 Salidas.1 Solicitudes de Cambio

Aprobadas.2 Actualizaciones del Plan de

Gestión del Programa.3 Actualizaciones del Plan de

Gestión de Comunicaciones del Programa



Definición de criterios de aceptación, Definición y priorización de requerimientos de los stakeholders, Desarrollo de la descripción del alcance, Definición de límites del alcance, y Definición de criterios de aceptación de los stakeholders.

Esta sección establece los criterios para identificar y entender los productos entregables del programa.

Figura 5–2. Planificar el Alcance del Programa: Entradas, Herramientas y Técnicas, y Salidas.

Figura 5–3. Flujo de Datos del Proceso Planificar el Alcance del Programa.

5.1.1. Planificar el Alcance del Programa: Entradas

.1 Caso de Negocio

El caso de negocio establece la autoridad, propósito y filosofía de la necesidad de negocio. Este documento proporciona dirección para la estructura, principios de guía, y organización.

.2 Acta de Constitución del Programa

107



El acta de constitución del programa es un documento de alto nivel desarrollado por el gestor del programa y el equipo del programa para apoyar la documentación y captura del marco de trabajo del programa total. Este documento es una fuente de información de alto nivel que puede apoyar a trazar la dirección del programa, a desarrollar los entregables del programa, y desarrollar los requerimientos del cronograma.

5.1.2. Planificar el Alcance del Programa: Herramientas y Técnicas

.1 Juicio de expertos

El juicio de expertos comprende las decisiones, opiniones, y estimaciones hechas por individuos que poseen habilidades, conocimiento, entendimiento, y experiencia en un campo, esfuerzo u ocupación particular, y son reconocidos por sus compañeros como seres informados. Esto es frecuentemente utilizado para evaluar las entradas y salidas de otras actividades para tomar decisiones y desarrollar procesos actuales. Los individuos que poseen habilidades de juicio de expertos están disponibles de muchas fuentes, tales como:

Otras unidades dentro de la organización, Gestores de proyectos, Consultores, Stakeholders, incluyendo clientes y sponsors, Sociedades profesionales y técnicas, y Grupos de industria.

.2 Sistemas de Información de la Gestión del Programa

Descrito en la Sección 4.2.2.1.

5.1.3. Planificar el Alcance del Programa: Salidas


El enunciado del alcance del programa describe el alcance, limitaciones, expectativas, y el impacto de negocio del programa así como presenta una descripción de cada proyecto y de sus recursos. El enunciado del alcance debe abordar los siguientes temas:

Necesidades y requerimientos de la organización, Requerimientos de alto nivel, e iniciales, del producto, Visión de la Solución, y Suposiciones y restricciones.


El plan de gestión del alcance del programa es un elemento subsidiario del plan general del programa. Debe incluir una evaluación de la estabilidad esperada del alcance del programa. El plan describe la manera en que se van a identificar y clasificar los cambios en el alcance, la manera en que se va a gestionar el alcance, y la manera en que se van a integrar los cambios en el alcance dentro del programa total.

108



5.2 Definir las Metas y Objetivos del Programa

La definición de las metas y objetivos del programa se logra mediante el entendimiento e identificación del enunciado del alcance del programa, identificación del plan de gestión del alcance, e implementación de las expectativas (Figuras 5–4 y 5–5). El nivel de detalle necesario para lograr el esfuerzo se determina mediante la complejidad, velocidad, o duración técnica en la cual se debe llevar a cabo la actividad, y la disponibilidad de recursos. El antecedente del programa sumariza el problema que el programa se encuentra resolviendo. Proporciona una breve historia del problema y la justificación del método utilizado para resolverlo. La inclusión de esta información en un enunciado del alcance del programa dependerá de las preferencias de los stakeholders, de la madurez de la organización, y del tiempo disponible.

Los objetivos de esta sección son:

Identificar los resultados generales que se esperan del programa, Aclarar lo que se va a conseguir, y Comunicar los resultados planificados a todos los stakeholders.

Figura 5–4. Definir las Metas y Objetivos del Programa: Entradas, Herramientas y Técnicas, y Salidas.

109



Figura 5–5. Flujo de Datos del Proceso Definir las Metas y Objetivos del Programa.

5.2.1. Definir las Metas y Objetivos del Programa: Entradas


El enunciado del alcance del programa es responsabilidad del gestor del programa. Aborda la visión, ámbito, capacidad, y amplitud del esfuerzo del programa. Al inicio del programa, el gestor del programa asegura que el contexto y el marco de trabajo de esfuerzo del programa se definan y evalúen apropiadamente. Esto se logra a través del enunciado del alcance del programa. El enunciado del alcance del programa establece la dirección tomada e identifica los aspectos esenciales que deben ser logrados. El propósito de este documento es asegurar que cada stakeholder comparta un entendimiento común de la naturaleza, propósito, y necesidades que deben ser abordadas por el programa. El enunciado del alcance del programa aborda:

Los requerimientos del negocio, La visión de la solución, El alcance y las limitaciones, El contexto de negocio del programa, Los riesgos potenciales, Los criterios de éxito, Los límites del programa, Los beneficios del programa, y Los entregables del programa.

En esencia, el enunciado del alcance del programa establece las expectativas del esfuerzo.



5.2.2. Definir las Metas y Objetivos del Programa: Herramientas y Técnicas

.1 Juicio de Expertos


.2 Entrevistas

110



Las metas y objetivos del programa se pueden reunir y evaluar mediante entrevistas a los participantes que están familiarizados con el programa y/o con los proyectos interactivos asociados al programa.

.3 Grupo de Análisis

Un grupo de análisis es un grupo de individuos reunidos para abordar preguntas específicas sobre su actitud hacia un producto, servicio, o concepto. Estas preguntas se realizan en un grupo interactivo donde los participantes son libres de hablar con otros miembros del grupo. Los grupos de análisis pueden resolver problemas y/o encontrar soluciones para el caso en estudio.

.4 Revisiones de Aceptación del Cliente

Las metas y objetivos se pueden mejorar y alinear llevando a cabo revisiones de aceptación del cliente. La gestión de la aceptación es el proceso de revisar los entregables dentro del programa y ganar la aceptación del cliente que se completa a un 100%. Obtener la aceptación del cliente para cada entregable puede mitigar la insatisfacción del cliente por:

Identificar los problemas de aceptación del cliente a principios del proyecto, Mejorar los entregables para cumplir con los requerimientos de un cliente, Maximizar la confianza del cliente en la entrega del proyecto, y Mantener felices a los clientes aumenta las oportunidades de éxito.

5.2.3. Definir las Metas y Objetivos del Programa: Salidas


El enunciado del alcance del programa debe ser actualizado para incluir cualquier solicitud de cambio aprobada que resulte del proceso Desarrollar la EDT del Programa. Las actualizaciones se deben registrar formalmente utilizando un sistema de gestión de configuración. La historia de la revisión debe ser bien documentada y listada en el registro de historia de revisión o registro de control de versión de los documentos.

.2 Plan de Realización de los Beneficios

El plan de realización de los beneficios identifica los beneficios del negocio y documenta el plan para realizar los beneficios. Esto permite al equipo monitorear los beneficios establecidos hasta la conclusión del programa. Este plan de beneficios se genera de manera similar a otros documentos – a través de entrevistas, brainstorming, y sesiones de revisión. Adicionalmente, el plan de realización de los beneficios identifica los procesos y sistemas de la organización necesarios para la transformación, los cambios requeridos para los procesos y sistemas, y cómo y cuándo los nuevos arreglos ocurrirán. El plan de realización de beneficios debe:

Asegurar que todas las etapas del programa se gestionen de manera que satisfagan la utilización de las salidas del programa,

Vincular las salidas a los resultados planificados del programa, Evaluar las salidas del programa, Realizar las acciones correctivas necesarias, y

111



Asegurar que los resultados planificados del programa sean obtenidos antes del cierre formal del programa.

5.3 Desarrollar los Requerimientos del Programa

El proceso Desarrollar los Requerimientos del Programa identifica y detalla las especificaciones y resultados del programa para la implementación (Figuras 5–6 y 5–7). Una cantidad considerable de detalle es necesaria a nivel del programa para asegurar que todos los componentes internos y entidades externas se aborden adecuadamente. La organización ejecutante debe tener un proceso sólido para gestionar los requerimientos incluyendo los de alto nivel que abarcan el negocio, cliente, industria, y otras áreas del programa relacionadas a la empresa.

El objetivo de esta sección es desarrollar e identificar los requerimientos y especificaciones que van a guiar a la implementación exitosa del programa.

Figura 5 – 6. Desarrollar los Requerimientos del Programa: Entradas, Herramientas y Técnicas, y Salidas.

Figura 5 – 7. Diagrama de Flujo de Datos del Proceso Desarrollar los Requerimientos del Programa.

112



5.3.1. Desarrollar los Requerimientos del Programa: Entradas


Descrito en la Sección 5.1.3.1 y 5.2.1.1.


Las solicitudes de cambio pueden surgir de las actividades de los componentes, de actividades a nivel del programa y de actividades no proyectizadas o de factores externos al programa.

.3 Caso de Negocio

Descrito en la Sección 4.1.1.2


Descrito en la Sección 4.1.3.4

5.3.2. Desarrollar los Requerimientos del Programa: Herramientas y Técnicas

.1 Recopilación de Requerimientos

Éste es el proceso de reunir los requerimientos de diversas fuentes: stakeholders, arquitectos, documentación existente, análisis de procesos, u otras fuentes. Los métodos para recopilar información incluyen, pero no se limitan a, lo siguiente:

Entrevistas. Las técnicas de entrevista son uno de los muchos métodos utilizados en la recopilación de requerimientos. Entrevistar a participantes experimentados del proyecto, stakeholders, y expertos de materia ayuda a identificar los requerimientos del programa que lo influyen.

Grupos de Análisis. Descrito en la Sección 5.2.2.3. Cuestionarios y Encuestas. Éstos pueden ser utilizados para obtener los

requerimientos mediante la recopilación de la información representativa de los stakeholders y otros.

.2 Análisis de Requerimientos

El proceso de análisis de requerimientos toma los requerimientos que se han recopilado, se asegura de que sean minuciosos, consistentes, y completos, y comienza el proceso de descomposición de los requerimientos de alto nivel en requerimientos más detallados.

.3 Revisiones de Diseño

Existen varios niveles de revisiones de diseño, como revisiones en proceso, revisiones internas, y revisiones formales de diseño. Un programa principal puede incorporar cualquiera de los diferentes tipos de revisiones de diseño. Las revisiones en proceso usualmente involucran grupos de compañeros y por lo general se realizan de manera periódica dentro del programa para evaluar la

113



actividad del programa y hacer recomendaciones. Las revisiones internas son más formales que las revisiones en proceso pero menos formales que las revisiones formales de diseño. En general, las revisiones internas determinan conformidad con las mejores prácticas de la materia dada por los expertos de materia y compañeros. En las revisiones formales de diseño, el diseño (en este caso, los requerimientos), se presenta al cliente para que lo evalúe. Los especialistas y la gerencia se ocupan de las revisiones formales de diseño.

.4 Brainstorming

El brainstorming es una técnica general de gestión utilizada para estimular el proceso pensado y los requerimientos del pensamiento en torno del programa. A través del brainstorming el equipo obtiene una comprensión de los requerimientos y esfuerzos para identificar los requerimientos que puedan afectar el resultado del programa. Durante una sesión de brainstorming, se discuten, comparten y registran ideas. Después, esas ideas se analizan cuando se refieren a la materia en curso.



.6 Validación y Verificación de los Requerimientos

Una vez que los requerimientos iniciales se recopilan y descomponen a un nivel suficiente de detalle, el programa emprende un proceso continuo que valida que los requerimientos son exactos y completos. A medida que evoluciona el programa y se realizan los cambios, los requerimientos deben ser continuamente reevaluados por los impactos.

A medida que el programa se desarrolla en etapas posteriores de desarrollo y construcción, los productos que se están desarrollando deben ser verificados contra los requerimientos para asegurar que satisfacen los requerimientos solicitados. Este proceso de verificación puede implicar realizar pruebas, a nivel de sistemas y a nivel detallado, inspección, análisis, u otro método que asegure que los requerimientos se han cumplido.

5.3.3. Desarrollar los Requerimientos del Programa: Salidas


El Documento de los Requerimientos del Programa describe los requerimientos de alto nivel que van a entregar los beneficios del programa. Detalla un registro de temas que incluye al negocio, medio ambiente, problemas técnicos y legales. Éstos son diferentes a las especificaciones técnicas de diseño. Por ejemplo, un programa para desarrollar un nuevo avión puede incluir requerimientos relacionados con la capacidad máxima de asientos para pasajeros, la capacidad de carga, y los parámetros de despegue/aterrizaje.

.2 Documentos de los Requerimientos del Componente

La documentación de los requerimientos desarrollada a nivel del programa describe los requerimientos de alto nivel. Éstos se descomponen en niveles incrementales de detalle hasta que están lo suficientemente detallados como

114



para ser escritos en contratos que se proporcionan a los contratistas a nivel del componente. Luego, los componentes toman estos requerimientos y continúa el proceso de descomposición hasta que el cronograma del componente pueda ser estimado con exactitud y el producto final del componente pueda ser diseñado.

5.4 Desarrollar la Arquitectura del Programa

El proceso Desarrollar la Arquitectura del Programa produce la estructura de los componentes del programa a través de la identificación de las relaciones entre los componentes y las reglas que determinan su inclusión (Figuras 5–8 y 5–9). Es necesario tener cuidadoso para asegurar que el alcance de cada proyecto en el programa concuerde con la arquitectura del programa.


Definir la estructura de los componentes del programa o sistema, Identificar las interrelaciones entre los componentes, y Establecer un conjunto de reglas que determinen la interacción y evolución del

programa o sistema.

Figura 5–8. Desarrollar la Arquitectura del Programa: Entradas, Herramientas y Técnicas, y Salidas.

115



Figura 5–9. Flujo de Datos del Proceso Desarrollar la Arquitectura del Programa.

5.4.1. Desarrollar la Arquitectura del Programa: Entradas



5.4.2. Desarrollar la Arquitectura del Programa: Herramientas y Técnicas

.1 Conocimiento Técnico

Los arquitectos con habilidades y experiencia en el desarrollo de soluciones que satisfacen los requerimientos son el núcleo del trabajo realizado durante este proceso. Las arquitecturas óptimas de solución son diseñadas por los diseñadores/arquitectos que tienen la capacitación y experiencia en el área del programa, ya sean ingenieros aeroespaciales, arquitectos de construcción, ingenieros civiles, arquitectos de software/base de datos, u otros recursos capacitados en el tipo de programa.

5.4.3. Desarrollar la Arquitectura del Programa: Salidas

.1 Línea Base de Arquitectura del Programa

La línea base de arquitectura del programa es el conjunto de componentes del programa, que delinea sus características, capacidades, productos entregables, coordinación e interfaces externas. También describe la manera en que los componentes contribuyen con los beneficios específicos del programa.

5.5 Desarrollar la EDT del Programa

Desarrollar la EDT del Programa (EDTP) es el proceso de subdividir los entregables principales del programa, las actividades del proyecto, y las fases de implementación del programa (Figuras 5–10 y 5–11). Es el proceso de descomponer todas las actividades de trabajo en componentes más fáciles de gestionar. La EDTP proporciona el marco de trabajo para organizar y gestionar el trabajo. Es una herramienta esencial para construir cronogramas realistas, desarrollar estimaciones de costo y organizar el trabajo. Además, es crucial para el reporte, seguimiento, y control de programas o proyectos. La EDTP es desarrollada y utilizada por todos los proyectos y programas. Es importante que la EDTP se estructure de manera que el alcance de las actividades y el trabajo futuro se pueda gestionar fácilmente.

Una EDTP es una descomposición jerárquica orientada al producto entregable que abarca el alcance total del programa, e incluye los entregables a ser producidos por los componentes constituyentes. Los elementos que no están en la EDTP se encuentran fuera del alcance del programa. La EDTP incluye, pero no se limita a, los productos entregables de la gestión del programa tales como planes,

116



procedimientos, estándares, procesos, hitos principales del programa, los productos entregables de la gestión del programa, y los productos entregables de soporte de la oficina del programa.

La EDTP es la clave para el control y la comunicación efectiva entre el gestor del programa y los gestores de los proyectos componentesla EDTP proporciona una descripción general del programa y muestra la manera en que cada proyecto cabe en él. La descomposición se detiene en el nivel del control requerido por el gestor del programa. Típicamente, esto corresponde a los primeros uno o dos niveles de la EDT de cada proyecto componente. Dado esto, la EDTP sirve como el marco de trabajo de control para desarrollar el cronograma del programa, y define los puntos de control de gestión del gestor del programa que se van a utilizar para la gestión del valor ganado, así como para otros propósitos.

Los componentes de la EDTP en el nivel más bajo de la EDTP se conocen como paquetes de programa. La descripción completa de los componentes de la EDTP y de cualquier información adicional relevante se documenta en el Diccionario de la EDTP, el cual es una parte integrante de la EDTP. La EDTP no reemplaza a la EDT requerida de cada proyecto dentro del programa. En cambio, se utiliza para esclarecer el alcance del programa, ayudar a identificar grupos lógicos de trabajo para los componentes, identificar la interface con las operaciones o productos, y aclarar la finalización del programa. Es también el lugar capturar todo el trabajo no proyectizado dentro del programa. Esto incluye artefactos de gestión de programas desarrollados para ser usados dentro de la oficina de programas, entregables externos como comunicaciones públicas, y entregables de solución final que abarcan los proyectos, como instalaciones e infraestructura.


Identificar y definir las tareas específicas de trabajo que son asignadas a cada elemento de la EDTP,

Definir la solución al problema en términos de un producto, y Proporcionar la definición completa del trabajo a ser realizado.

Figura 5–10. Desarrollar la EDT del Programa: Entradas, Herramientas y Técnicas, y Salidas.

117



Figura 5–11. Diagrama de Flujo de Datos del Proceso Desarrollar la EDT del Programa.5.5.1. Desarrollar la EDT del Programa: Entradas


La arquitectura del programa es el punto de partida para desarrollar la EDT ya que contiene los elementos necesarios. Los proyectos complejos, y grandes, se organizan y entienden a medida que se van dividiendo progresivamente en piezas más pequeñas hasta que se convierten en una colección de “paquetes de trabajo” definidos que pueden ser aún más divididos en tareas.



.3 Documento de los Requerimientos de los Componentes


5.5.2. Desarrollar la EDT del Programa: Herramientas y Técnicas



.2 Plantillas de la Estructura de Desglose del Trabajo

Cualquier plantilla de la EDT que se encuentre disponible para este tipo de programa debe ser utilizada cuando sea posible. Estas plantillas pueden encontrarse disponibles de fuentes internas de la organización, de organizaciones profesionales, o de fuentes comerciales externas como organizaciones de consultoría.

.3 Proceso de Planificación de Gestión

El proceso de planificación de gestión proporciona el esfuerzo de análisis y diseño para planificar la manera en que se van a alcanzar las metas y objetivos del programa. Un plan entrega un punto fijo de partida y una dirección que

118



puede ser modificada subsecuentemente a medida que cambian las circunstancias durante el ciclo de vida del programa. El proceso de planificación de gestión reúne todos los aspectos de planificación en un proceso coherente, unificado que incluye el análisis minucioso de los objetivos de gestión, y las fuentes posibles de conflicto entre las políticas de la organización. Durante el proceso de planificación, se desarrollan y evalúan diversas opciones para gestionar el programa. Este proceso asegura que los planes del programa estén completamente desarrollados, bien enfocados, sean resistentes, prácticos y rentables. Al elegir la opción más apropiada, el propósito es lograr un equilibrio entre los entregables del programa y los objetivos del negocio.

.4 Matriz de Responsabilidad de Tarea

La matriz de responsabilidad de tarea es una herramienta que ayuda a documentar y comunicar los roles y el nivel de participación que cada miembro del equipo y/o grupo funcional diferente ejercerá dentro de sus tareas específicas.

.5 Herramientas de Configuración del Sistema

Las herramientas de configuración del sistema proporcionan documentación consistente de las versiones del producto para utilizarlos a lo largo del programa. Estas herramientas ayudan a proporcionar el control de cambios para los documentos de diseño, alcance, requerimientos, procesos y para la gran cantidad de puntos que se van a modificar durante la vida del programa. Saber qué versión es la más actual es algo invalorable y crítico en todas partes de la vida del programa. Incorporar herramientas de configuración de sistemas proporciona la habilidad de monitorear el control de cambios mientras se aumenta el control organizacional.

5.5.3. Desarrollar la EDT del Programa: Salidas

.1 EDT del Programa

La estructura de desglose del trabajo del programa (EDTP) proporciona una descomposición jerárquica orientada al producto entregable del trabajo que será ejecutado y logrado por cada proyecto del programa. Describe el enunciado de trabajo del programa. La salida es un producto entregable o grupo orientado al producto de los elementos de trabajo del programa, representado gráficamente, que organiza y subdivide el alcance total del trabajo del programa. La EDT delinea la línea base del alcance del programa, la cual es necesaria para alcanzar los objetivos técnicos del trabajo descrito.

.2 Matriz de la Estructura de Desglose del Trabajo

La matriz de la estructura de desglose del trabajo del programa o proyecto es un producto entregable o grupo orientado al producto de los elementos de trabajo del proyecto representado gráficamente para organizar y subdividir el alcance total del trabajo de un proyecto.

119



5.6 Gestionar la Arquitectura del Programa

El proceso Gestionar la Arquitectura del Programa asegura que las relaciones entre los elementos del programa estén bien estructurados y adheridos al conjunto de las reglas de gobierno definidas en la arquitectura del programa (Figuras 5–12 y 5–13). Durante el ciclo de vida del programa, puede ser necesario realizar cambios en la arquitectura del programa. Por ejemplo, esto puede ser debido a una falla de adherirse a los elementos de alcance principales como un proyecto relacionado a la EDT y la arquitectura total del programa.

Figura 5–12. Gestionar la Arquitectura del Programa: Entradas, Herramientas y Técnicas, y Salidas.

Figura 5–13. Flujo de Datos del Proceso Gestionar la Arquitectura del Programa.

5.6.1. Gestionar la Arquitectura del Programa: Entradas


El Documento de la Arquitectura del Programa está descrito en la Sección 5.4.3.1.

120




El plan de gestión del programa está descrito en la Sección 4.2.3.1.



5.6.2. Gestionar la Arquitectura del Programa: Herramientas y Técnicas



.2 Análisis del Impacto de los Cambios

Descrito en la Sección 4.4. El análisis de los cambios arquitectónicos analiza la integridad e influencia que tienen los impactos en los elementos arquitectónicos y sus componentes delineados en el documento de la arquitectura del programa, el cual apoya al plan general de gestión del programa.

5.6.3. Gestionar la Arquitectura del Programa: Salidas

.1 Actualizaciones de la Línea Base de la Arquitectura del Programa

Gestionar la arquitectura del programa puede requerir actualizar los documentos relacionados al programa para reflejar cualquier alteración relevante.


Las solicitudes de cambio aprobadas se incorporan al plan del programa y componentes asociados, o se rechazan si el cambio es perjudicial para las metas y objetivos del programa. Los procesos formales de gobierno abordan los procesos de solicitud de cambio para ayudar de manera consistente a la toma de decisiones.


Las actualizaciones formales del plan de gestión del programa se realizan sobre la aprobación de las solicitudes de cambio hechas en el proceso Gestionar la Arquitectura del Programa.

5.7 Gestionar las Interfaces del Componente

La gestión de programas interactúa con las actividades operativas y del proyecto y también con los componentes distintivos de trabajo, los cuales son parte del alcance total del programa (Figuras 5–14 y 5–15). La gestión transparente de las interfaces del componente es crucial para la adherencia del alcance dentro del

121



programa. Las partes interrelacionadas del alcance del proyecto pueden necesitar ser revisadas, junto con los elementos de arquitectura del programa. Las salidas de otros procesos de planificación son actualizadas como corresponde.

Figura 5–14. Gestionar las Interfaces del Componente: Entradas, Herramientas y Técnicas, y Salidas.

Figura 5–15. Diagrama de Flujo de Datos del Gestionar las Interfaces del Componente.

5.7.1. Gestionar la Arquitectura del Programa: Entradas

122









.4 Plan de Gestión de Comunicaciones del Programa


.5 Pautas de Gestión de los Stakeholders del Componente


5.7.2. Gestionar la Arquitectura del Programa: Herramientas y Técnicas



.2 Métodos de Comunicación


.3 Reuniones de Revisión


.4 Gestión del Conflicto


5.7.3. Gestionar la Arquitectura del Programa: Salidas




Las solicitudes de cambio a nivel del proyecto se pueden reflejar en las diversas interfaces del programa. Estos cambios se utilizan para actualizar el plan de gestión del programa.

.3 Actualizaciones del Plan de Gestión de Comunicaciones del Programa

123



Las actualizaciones del plan de gestión de comunicaciones aseguran que cualquier modificación que requiera entregables adicionales de comunicaciones de las necesidades comunicación de interfaces se recopile y apoye.

5.8 Monitorear y Controlar el Alcance del Programa

Debido al tamaño, complejidad, y duración de muchos programas, es muy importante gestionar el alcance a medida que se desarrolla el programa para asegurar la finalización exitosa (Figuras 5–16 y 5–17). Los cambios en el alcance que puedan tener un impacto significativo en un componente y/o en el programa se pueden originar de los stakeholders, de componentes dentro del programa, de requerimientos o problemas de arquitectura antes no identificados, o de fuentes externas. Cada cambio potencial necesita ser analizado y sus impactos identificados.

Figura 5–16. Monitorear y Controlar el Alcance del Programa: Entradas, Herramientas y Técnicas, y Salidas.

124



Figura 5–17. Flujo de Datos del Proceso Monitorear y Controlar el Alcance del Programa.

El proceso de control de cambios de un programa es frecuentemente jerárquico. El programa tiene un comité de control de cambios (CCC) que analiza los cambios a nivel del programa. Si el CCC del programa identifica un impacto en un componente, el cambio se envía al CCC del componente para un análisis de impacto más detallado. Los resultados de ese análisis retornan al CCC del programa y se identifica cualquier impacto sobre otros componentes o sobre las interfaces del componente.

5.8.1. Monitorear y Controlar el Alcance del Programa: Entradas





.3 Solicitudes de Transición del Componente

La decisión de cierre del componente se recomienda al gestor del programa quien toma la decisión en base a la entrada de la función de Gobierno.

.4 Plan de Gobierno






5.8.2. Monitorear y Controlar el Alcance del Programa: Herramientas y Técnicas



.2 Reuniones de Revisión

Descrito en las Secciones 4.3.2.3 y 4.6.2.4.

.3 Toma de Decisiones

La toma de decisiones abarca una amplia variedad de técnicas para llegar a un enfoque razonable o a una resolución razonable de un problema o una solicitud

125



de cambio. La toma de decisiones requiere de buena información y personal con experiencia para llegar a conclusiones apropiadas.

.4 Auditorías


.5 Sistemas de Información de Gestión del Programa


5.8.3. Monitorear y Controlar el Alcance del Programa: Salidas


Descrito en las Secciones 4.4.3.1 y otras.

.2 Actualizaciones de los Requerimientos del Programa






.5 Actualizaciones del Depósito de Documentos del Programa


126



CAPÍTULO

GESTIÓN DEL TIEMPO DEL PROGRAMA

6.1 DESARROLLAR EL CRONOGRAMA DEL PROGRAMA.6.2 MONITOREAR Y CONTROLAR EL CRONOGRAMA DEL PROGRAMA.

La Gestión del Tiempo del Programa involucra procesos para programar los componentes y entidades definidos del programa que son necesarios para producir los entregables finales del programa (Figuras 6–1 y 6–2). Incluye determinar el orden en que se ejecutan los componentes individuales, el camino crítico para el programa, y los hitos a ser medidos para mantener el programa total en su curso y dentro de las restricciones definidas.

Los procesos de la Gestión del Tiempo del Programa incluyen:

6.1 Desarrollar el Cronograma del Programa: Desarrollar el cronograma es el proceso de definir los componentes del programa necesarios para producir los entregables del programa, determinar el orden en que se deben ejecutar los componentes, estimar la cantidad de tiempo requerida para llevar a cabo cada componente e identificar los hitos principales del programa durante el periodo de desarrollo.

6.2 Monitorear y Controlar el Cronograma del Programa: Controlar el cronograma es el proceso de asegurar que el programa produce los entregables y soluciones requeridas a tiempo. Las actividades incluyen hacer un seguimiento de las fechas de inicio y fin así como de los hitos intermedios importantes y compararlos con las líneas de tiempo planificadas. Actualizar el cronograma y reportar el impacto de fechas perdidas forman parte de este proceso.

Mientras que los gestores del proyecto se concentran en gestionar sus productos entregables del proyecto en base a un cronograma preplanificado, los gestores del programa se concentran en coordinar todos los cronogramas del componente dentro del programa y en integrarlos para asegurar que el programa se complete de acuerdo al cronograma.

Las dependencias entre los diversos componentes tienen un impacto significativo en el cronograma total. Una finalización tardía de un componente puede impactar en otros componentes o en actividades de integración que dependen de su finalización. Más que gestionar los detalles de cualquier componente individual, el gestor del programa se concentra en la integración de cada componente en el cronograma total del programa.

127

6



Figura 6–1. Descripción General de la Gestión del Tiempo del Programa.

Figura 6–2. Diagrama de Flujo de Datos de la Gestión del Tiempo del Programa.

6.1Desarrollar el Cronograma del Programa

128



El cronograma inicial del programa se crea frecuentemente antes de que los cronogramas detallados de los componentes individuales estén disponibles. La fecha de entrega y los hitos principales del programa se desarrollan mediante el caso de negocio y, si está disponible, el acta de constitución del programa. A medida que se crea la arquitectura del programa, se torna disponible más información detallada del cronograma. Mientras se desarrolle un análisis más detallado, y se reciba feedback de componentes individuales, el cronograma se desarrollará con más detalle (Figuras 6–3 y 6–4).

El cronograma a nivel del programa solo debe incluir esos hitos de componente que representan una salida del programa o comparten una interdependencia con otros componentes. El primer borrador de un cronograma del programa a menudo tiene el carácter de un mapa de rutaidentifica el orden y las fechas de inicio y fin de los componentes. Después, éste se enriquece con más resultados intermedios del componente a medida que se desarrollan los cronogramas del componente. Los cronogramas detallados del componente se escriben en contratos y se utilizan para crear el cronograma maestro del programa total.

Al planificar el cronograma de un componente, es frecuentemente adecuado para la planificación ser realizada principalmente por el gestor del programa y el equipo de gestión del proyecto. Por contraste, en un programa pueden haber muchos componentes diferentes, cada uno gestionado por un diferente contratista e implicando radicalmente diferentes tipos de trabajo, por lo tanto la planificación centralizada sólo se pude realizar a un nivel muy alto. La planificación detallada se debe realizar a nivel del componente. A menudo es recomendable hacer que los contratistas se conozcan entre sí y trabajen a través de cualquier conflicto o restricción en sus respectivos cronogramas. Si existen subcontratistas implicados, el contratista principal puede coordinar las restricciones de sus cronogramas. El cronograma resuelto se reporta a la oficina de gestión del programa y se incorpora al cronograma maestro del programa.

Figura 6–3. Desarrollar el Cronograma del Programa: Entradas, Herramientas y técnicas, y Salidas.

Una vez que se determina el cronograma total del programa, se identifican las fechas para cada componente individual y se utilizan para desarrollar el cronograma del componente. El programa necesita que las fechas actúen como una restricción en la programación del componente individual. Si un componente tiene productos entregables múltiples de los cuales dependen otros componentes, esos productos entregables e interdependencias se deben reflejar en el cronograma maestro del programa total.

129



El cronograma de un programa se crea típicamente utilizando la estructura de desglose del trabajo del programa (EDTP) como punto de partida. Los gestores individuales del proyecto construyen los detalles para su proyecto específico los cuales aparecen luego como puntos del control de la gestión de los paquetes del programa para la EDTP.las interdependencias entre los proyectos constituyentes se deben reflejar y gestionar en el cronograma del programa. El cronograma incluye todos los paquetes del programa en la EDTP que producen los productos entregables. El cronograma del programa comprende líneas de tiempo de diversos paquetes del programa y actividades del programa no proyectizadas, y señala los hitos significativos.

Un elemento esencial de desarrollo del cronograma es programar los paquetes del programa, que permite al planificador pronosticar la fecha sobre la cual terminará el programa, así como las fechas finales para los hitos dentro del programa (por ejemplo, los productos entregables claves dentro de cada proyecto constituyente).

Figura 6–4. Desarrollar el Cronograma del Programa: Diagrama de Flujo de Datos.

6.1.1. Desarrollar el Cronograma del Programa: Entradas

.1 EDT del Programa

Descrito en la Sección 5.5.3.1. El proceso Desarrollar la Estructura de Desglose del Trabajo del Programa (Sección 5.5) toma los componentes descritos en el proceso Desarrollar la Arquitectura del Programa (Sección 5.4) y los divide en fases y entregables a nivel del Programa. Además de los

130



proyectos, los componentes incluyen típicamente grupos de actividades de Soporte del Programa y de la Gestión del Programa.

.2 Restricciones del Programa

Al desarrollar el cronograma maestro del programa, se debe poner la debida atención a las restricciones planteadas por los diversos factores, tanto internos como externos al programa. Esto puede incluir:

Restricciones de financiación, Disponibilidad de recursos, Restricciones técnicas, Contratos, Fecha límite inamovible, Leyes laborales, Restricciones ambientales, Otras dependencias externas, y Otros factores en el entrono del programa.

.3 Línea Base de Arquitectura del Programa



El acta de constitución del programa proporciona el mandato para ejecutar el programa dentro de una línea de tiempo segura. También puede presentar hitos para la entrega de productos y beneficios incrementales.

.5 Contratos

Los cronogramas detallados que han sido desarrollados por los contratistas se introducen en el plan maestro del programa. Cualquier contratista individual puede afectar potencialmente el programa general del programa si no pueden entregar un componente clave dentro de la línea de tiempo inicialmente esperada.

.6 Registro de Riesgos del Programa


6.1.2. Desarrollar el Cronograma del Programa: Herramientas y Técnicas

1. Herramientas de Gestión del Cronograma

Una herramienta primordial utilizada en el desarrollo del cronograma del programa es el software de gestión del cronograma. El cronograma general del programa se introduce en la herramienta al igual que los hitos para cada componente individual. Estos hitos se proporcionan luego a los procesos de adquisición y los contratistas proporcionan respuestas contra las fechas límites para sus componentes propuestos. Una vez que comienza el trabajo a

131



nivel del componente, la herramienta se utiliza para gestionar y controlar el cronograma durante la ejecución del programa.

La herramienta automatizada puede ser muy simple o altamente avanzada y capaza de manejar un programa que cuesta billones de euros, dólares, u otra moneda local, y tomar de cinco a 10 años o más tiempo. La herramienta debe ser apropiada para el tipo de proyecto y para su escala. Aunque el contratista gestiona cada componente al detalle a nivel del componente (para los programas donde están involucrados los contratistas), la herramienta del programa debe estar suficientemente detallada a nivel del componente para permitir al gestor del programa entender el estado del programa total. Si todo el trabajo del programa se realiza internamente sin la participación de los contratistas, la herramienta debe tener cada componente y recurso en su base de datos y permitir al gestor del programa llegar hasta el nivel más bajo de detalle.

Cuando hay múltiples contratistas involucrados, es un beneficio significativo tener todas las herramientas de empleo de contratistas que son tecnológicamente compatibles. Esto permite a las herramientas de gestión del cronograma de componentes producir los reportes de estado en un formato que pueden ser fácilmente introducidos a la herramienta a nivel del programa más que tener que reintroducirlos.

2. Análisis de Beneficios

El análisis de beneficios es el proceso de mirar cualquier beneficio incremental que proporciona el programa y hacer ajustes al cronograma para mejorar la entrega de esos beneficios. Muchos programas no proporcionan beneficios incrementales (todos los beneficios pueden llegar al final). El Gestor del Programa puede aún realizar un análisis de beneficios para mejorar las decisiones tomadas durante la ejecución del programa.

3. Análisis de Flujo de Caja

El análisis de flujo de caja examina el cronograma de financiación para los ingresos y gastos del programa. El dinero para los contratistas o para otros gastos del programa no puede ser pagado a menos que esté disponible para el programa. La programación de las actividades del componente puede tenerse en consideración cuando el dinero para pagar cada actividad esté disponible.

Por ejemplo, en la industria de construcción los fondos no siempre están disponibles de forma continua, pero se pagan cuando los hitos son cumplidos. Las actividades de programación se pueden realizar en el último inicio posible para aplazar los gastos hasta que tan pronto como sea posible los fondos se encuentren disponibles para pagar por ellas. Los contratistas del componente deben prestar atención a sus flujos de caja en lo que se refiere a retenciones u otros fondos contenidos hasta que el contrato total se complete.

6.1.3. Desarrollar el Cronograma del Programa: Salidas

1. Cronograma Maestro del Programa

El cronograma maestro del programa es el documento del programa de alto nivel, que define los cronogramas individuales del componente y las

132



dependencias entre los componentes del programa (proyectos y otros trabajos individuales) para alcanzar la meta del programa. El cronograma maestro del programa determina la coordinación entre componentes individuales y permite al gestor del programa determinar cuándo entregará el programa los beneficios. El Cronograma Maestro del Programa también identifica las dependencias externas del programa.

2. Hitos del Componente

Los hitos del componente identifican todos los entregables del programa. Esto permite que se realicen los beneficios y que se identifiquen los hitos para la transición de los entregables del componente del programa. Además, los hitos del componente se utilizan para indicar las dependencias internas del programa.

3. Plan de Gestión del Cronograma del Programa

Este proceso produce el plan de gestión del cronograma del componente. El plan identifica la secuencia acordada de las entregas del componente para permitir a las entregas individuales del componente ser planificadas y gestionadas. Proporciona al equipo/stakeholders del programa el plan que identifica la manera en que se va a gestionar el programa a los largo de la vida del programa. Es un documento vital, que brinda al gestor del programa los medios para identificar los riesgos y problemas intensificados del componente que puedan afectar las metas del programa.

4. Actualizaciones del Acta de Constitución del Programa

Este proceso puede generar actualizaciones en el acta de constitución del programa, donde el desarrollo del cronograma del programa identifica la necesidad de alterar el acta de constitución para realizar las metas del programa o corregir las metas del programa como resultado del desarrollo del cronograma.

5. Actualizaciones del Registro de Riesgos del Programa

Cualquier riesgo identificado como parte del desarrollo del cronograma debe ser incorporado en el registro de los riesgos del programa, a medida que se identifican a través del desarrollo del cronograma del programa. Estos riesgos pueden ser resultado de las dependencias del componente dentro del cronograma o de factores externos identificados como resultado del Plan de Gestión del Cronograma del Programa acordado.

6.2Monitorear y Controlar el Cronograma del Programa

El control del cronograma del programa incluye los procesos para asegurar que el programa produzca los entregables y soluciones requeridos a tiempo y dentro del presupuesto y especificaciones (Figuras 6–5 y 6–6). Estos procesos incluyen el seguimiento y monitoreo del inicio y fin de todas las actividades e hitos del componente y programa de alto nivel contra las líneas de tiempo planificadas. Actualizar los cronogramas maestros del programa y dirigir los cambios de los cronogramas individuales del proyecto es requerido para mantener un cronograma

133



maestro del programa actualizado y preciso. El proceso Monitorear y Controlar el Cronograma del Programa trabaja estrechamente con otros procesos del programa para identificar las variaciones de los cronogramas y dirigir las acciones correctivas cuando sea necesario para devolver al programa a la línea base del cronograma. La identificación de las disminuciones y de las entregas anticipadas es necesaria como parte de la función general de la gestión del programa. La identificación de las entregas anticipadas puede proporcionar oportunidades para la aceleración del programa.

Figura 6–5. Monitorear y Controlar el Cronograma del Programa: Entradas, Herramientas y Técnicas, y Salidas.

134



Figura 6–6. Monitorear y Controlar el Cronograma del Programa: Diagrama de Flujo de Datos.

6.2.1. Monitorear y Controlar el Cronograma del Programa: Entradas

1. Cronograma Maestro del Programa

El cronograma maestro del programa es la salida clave para monitorear y controlar los cronogramas individuales del componente. El gestor del programa mantiene un balance delicado entre la orientación brindada y el monitoreo del progreso de los componentes, por un lado, y la libertad dada a los líderes del componente para que desarrollen sus cronogramas respectivos.

2. Estado del Componente

Para todo el trabajo del proyecto y el trabajo no proyectizado relacionado al componente, esta entrada debe incluir los tiempos de inicio y finalización reales para los elementos de planificación de alto nivel que se basan en técnicas de medición predefinidas (hitos medibles, porcentaje ponderado completo, nivel de esfuerzo (NDE), etc.). La plantilla para los reportes de estado del componente debe proporcionar la función de la gestión del programa con amplia advertencia si un hito a nivel del programa está en peligro de cambiar. Típicamente, estos hitos a nivel del programa señalan las dependencias entre componentes. Un retraso en la entrega de un producto del componente puede tener un efecto cascada o adverso sobre los cronogramas de otros componentes del programa. Los reportes del estado del componente vienen de la Sección 10.2, Distribuir Información.

3. Registro de Riesgos del Programa

Una gran parte de los riesgos identificados tendrá un impacto en la línea de tiempo. A nivel del programa, el tiempo tope señalado en el cronograma necesita ser analizado y comparado con la tolerancia de los riesgos de la organización patrocinadora.

4. Solicitudes de Cambio Aprobadas

Una vez que el gobierno del programa acepta una solicitud de cambio, el componente del/de los componente(s) impactado(s) necesitan ser ajustados. El impacto de una solicitud de cambio puede variar de añadir o remover tareas a nivel del componente hasta introducir nuevos componentes o para/remover los componentes existentes.

6.2.2. Monitorear y Controlar el Cronograma del Programa: Herramientas y Técnicas

135



1. Herramientas de Gestión del Cronograma


2. Métricas del Programa

Las métricas del programa identifican los números específicos sobre los cuales se mide el progreso del programa. Por ejemplo, si un programa está 10% atrasadoel estado es ¿rojo, amarillo, o verde? Las métricas identifican qué se va a medir y cómo se va a reportar el estado contra esas métricas.

3. Gestión del Valor Ganado

La gestión del valor ganado es un enfoque que integra el alcance, cronograma, y recursos para proporcionar una medición precisa y objetiva del estado del programa y componente. Un número de estudios indican que es la manera más precisa de medir el estado y es particularmente útil para programas grandes donde las actividades individuales se pueden medir en semanas o meses.

La EVM requiere que los requerimientos del programa se identifiquen al 100% para las actividades de término cercano, y que se creen técnicas bien definidas para la medición del progreso. La EVM utiliza los valores de:

Valor Planificado (VP). El VP es la cantidad de dinero presupuestada para el trabajo programado a ser completado en cualquier actividad de la EDT.

Costo Real (CA). El CA es el costo para la actividad que ha sido completada o que está en progreso.

Valor Ganado (VG). El VG es la cantidad de dinero presupuestada para el trabajo que ya ha sido completado.

La EVM utiliza estos métodos y estándares de medición para calcular el estado del programa hasta la fecha midiendo la variación del costo (la VC es el valor ganado menos el costo real) y la variación del cronograma (la VC es el valor ganado menos el valor planificado).

Las técnicas de la EVM implican desarrollar pronósticos de estimación hasta la finalización (EHF) así como pronósticos de estimación a la finalización (EAC).

6.2.3. Monitorear y Controlar el Cronograma del Programa: Salidas

1. Actualizaciones del Cronograma Maestro del Programa

Las actualizaciones al cronograma maestro del programa se incluyen como resultado de la performance de la entrega del programa contra el cronograma acordado. Estas actualizaciones incluyen cambios al cronograma maestro en respuesta a los riesgos identificados durante la vida del programa o cambios a los estados del componente.

136



Debido a la naturaleza compleja y duración de los programas, que atraviesan fronteras globales y funcionan por muchos años, estas actualizaciones se incluyen para lograr la entrega de las metas del programa o se revisan las metas del programa como resultado de las solicitudes de cambio aceptadas.

El cronograma maestro del programa se actualiza para incluir nuevos componentes identificados como resultado de las solicitudes de cambio aceptadas o de actividades adicionales requeridas para satisfacer las metas del programa, como resultado de los estados del componente. A medida que cambia el estado de los componentes individuales, el cronograma maestro del programa debe ser revisado para evaluar el impacto de los cambios a nivel del componente sobre otros componentes y sobre el propio programa. Tales cosas como los artículos adquiridos, que experimentan inesperadamente un plazo de entrega largo pueden tener un efecto significativo sobre la performance del cronograma total del programa.

2. Actualizaciones de los Cronogramas del Componente

Las desviaciones de los componentes acordados pueden ser requeridas como resultado de la performance de la entrega actual. Estos cambios son requeridos para mantener la realización de los beneficios y metas acordados del programa. Los cambios en los cronogramas del componente proporcionan la dirección necesaria a los componentes individuales para corregir desviaciones negativas de los cronogramas individuales del componente que puedan afectar el Cronograma Maestro del Programa total.

Puede existir la necesidad de acelerar o desacelerar los componentes dentro del cronograma para alcanzar las metas del programa. Además, las oportunidades para realizar los beneficios anticipadamente se pueden presentar como resultado de la entrega anticipada del componente.

3. Reportes de Performance del Programa

Las actualizaciones del estado de la entrega del programa se realizan contra el cronograma acordado para proporcionar el estado del monitoreo de la performance para comunicar la performance del programa a los stakeholders del programa (ver la Sección 10.3 en el proceso Reportar la Performance del Programa).

La definición clara de las métricas a ser utilizadas para definir el estado del cronograma del componente debe ser proporcionada al inicio de la performance. Generalmente, un programa tendrá múltiples componentes, cada uno en una fase diferente. Por ejemplo, un proyecto puede estar en la fase de iniciación y a tiempo, otro en la fase de ejecución y atrasado 20%, otro en la fase de prueba e integración con un 5% de anticipación. ¿Qué es el estado del programa en ese punto? Mientras no se pueda dar una respuesta universalmente aceptada, el gestor del programa y la organización u organismo de gobierno debe llegar a un entendimiento común de cómo definir claramente el estado del cronograma del programa total.

137



CAPÍTULO

GESTIÓN DE LAS COMUNICACIONES DEL PROGRAMA

10.1 PLANIFICAR LAS COMUNICACIONES.10.2 DISTRIBUIR INFORMACIÓN.10.3 REPORTAR LA PERFORMANCE DEL PROGRAMA.

La Gestión de las Comunicaciones del Programa es el Área de Conocimiento que incluye los procesos para asegurar la oportuna y adecuada generación, recopilación, distribución, almacenamiento, recuperación, y disposición final de la información del programa. Los procesos de la Gestión de las Comunicaciones del Programa proporcionan las conexiones críticas entre la gente y la información necesaria para las comunicaciones exitosas. Los gestores del programa pueden emplear una cantidad significativa de tiempo para comunicarse con el equipo del programa, los equipos del proyecto, los gestores del proyecto, stakeholders, clientes, y sponsor. Cualquiera que esté implicado en el programa debe entender cómo afectan las comunicaciones al programa total. La gestión de las comunicaciones del programa, tanto las comunicaciones internas como externas, es un área que no puede ser subestimada o ignorada. Los problemas significativos pueden ocurrir si no se dedica un esfuerzo suficiente a las comunicaciones.

La Gestión de las Comunicaciones del Programa es diferente a las comunicaciones del proyecto. Debido a que afecta a una selección más amplia de stakeholders, se requieren diferentes herramientas y marketing de las comunicaciones.

La Figura 10–1 proporciona una descripción general de los procesos de la Gestión de las Comunicaciones del Programa, con entradas, herramientas y técnicas, y salidas. Los procesos de la Gestión de las Comunicaciones del Programa incluyen lo siguiente:

10.1. Planificar las Comunicaciones: Determinar las necesidades de información y comunicaciones de los stakeholders del programa.

10.2. Distribuir Información: Poner la información necesaria a disponibilidad de los stakeholders del programa de manera oportuna.

10.3. Reportar la Performance del Programa: Recopilar y distribuir la información sobre la performance. Esto incluye reportes de estado, medición del progreso, y pronósticos.

Estos procesos interactúan entre sí y también con los procesos de las demás Áreas de Conocimiento. La gestión de las Comunicaciones y la Gestión de los Stakeholders del Programa son Áreas de Conocimiento estrechamente relacionadas. Cada proceso puede implicar esfuerzo de una o más personas o grupos de acuerdo

138

10



a las necesidades del programa. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se produce en una o más fases del proyecto. Aunque los procesos se presentan como elementos discretos con interfaces bien definidas, en la práctica se pueden superponer e interactuar de maneras que no se detallan en este estándar.

Figura 10 – 1. Descripción General de la Gestión de las Comunicaciones del Programa.

10.1.Planificar las Comunicaciones

139



Planificar las Comunicaciones es el proceso de determinar las necesidades de información y comunicación de los stakeholders del programa en base a quién necesita qué información, cuándo la necesitan, cómo se les será proporcionada y por quién. Los requerimientos de las comunicaciones deben estar claramente definidas para asegurar la transferencia de la información de los proyectos al programa (Figuras 10–2 y 10–3).

Comparado con los proyectos, los programas generalmente requieren más tiempo para terminar y son más complejos. Esta distinción se debe abordar al planificarse las comunicaciones. Debido a que los programas toman más tiempo para terminar, los miembros del equipo, sponsors del proyecto, gestores del proyecto, y gestores del programa frecuentemente dejan los programas antes de que se completen. Cuando múltiples vendedores forman parte del equipo del programa el número de stakeholders se incrementa. Las diferencias de cultura y lenguaje, huso horario, y otros factores asociados a la globalización se deben considerar al momento de desarrollar el plan de comunicaciones, aunque la planificación de las comunicaciones compleja es vital para el éxito de cualquier programa.

Figura 10 – 2. Planificar las Comunicaciones: Entradas, Herramientas y Técnicas, y Salidas.

140



Figura 10 – 3. Diagrama del Flujo de Datos del Proceso Planificar las Comunicaciones.

10.1.1. Planificar las Comunicaciones: Entradas


El acta de constitución del programa es la entrada clave al proceso Planificar las Comunicaciones. Ayuda a determinar los requerimientos de las comunicaciones proporcionando información sobre los requerimientos del programa, necesidades del negocio, propósito, así como otra información de alto nivel. El acta de constitución del programa se trata con detalle en la Sección 4.1.3.2.


El plan de gestión del programa proporciona información origen sobre el programa. Incluye detalles relacionados al alcance, riesgos, requerimientos de calidad, cronograma, y otra información relevante a la Planificación de las Comunicaciones.El equipo del programa necesita prestar atención especial a los supuestos y restricciones, que pueden requerir una planificación de comunicaciones adicional.

Restricciones: Las restricciones son factores que pueden limitar las opciones del equipo de gestión del programa. Los ejemplos de restricciones incluyen a los miembros del equipo situados en diferentes ubicaciones geográficas, versiones de software de comunicación incompatibles, o capacidades técnicas de comunicaciones limitadas.

141



Supuestos: Los supuestos específicos que pueden afectar al proceso Planificar las Comunicaciones dependen del programa específico, cláusulas de confidencialidad en los contratos, y reglas gubernamentales u organizacionales.

.3 Plan de Gobierno


.4 Plan de Gestión de los Stakeholders del Programa

Descrito en la Sección 14.1.3.1. Las comunicaciones son la herramienta principal para gestionar las expectativas de los stakeholders.

.5 Estrategia Organizacional de Comunicaciones

La estrategia de comunicaciones de la organización, si existe alguna, debe ser revisada como parte de este proceso. Esto asegurará que las comunicaciones del programa concuerdan con cualquier pauta o política y que siguen los procesos de la organización.


Descrito en la Sección 5.1.3.1. Mediante el análisis del enunciado del alcance del programa, re pueden realizar las comunicaciones de manera más cuidadosa.

.7 EDT del Programa


.8 Requerimientos de la Comunicaciones

Los requerimientos de las comunicaciones pueden variar dependiendo de las necesidades específicas del programa. Se deben considerar diversos factores al momento de recopilar los requerimientos de las comunicaciones incluyendo el tamaño y complejidad del programa. La información típicamente requerida para determinar los requerimientos de las comunicaciones del programa incluyen:

Gráficos de la organización; Matrices de organización y roles y responsabilidad del programa; Disciplinas, departamentos, y especialidades involucradas en el proyecto; Logísticas de la cantidad de personas que estarán involucradas con el

programa y en qué ubicaciones; Necesidades de información internas (por ejemplo, comunicaciones

dentro de la organización y comunicaciones dentro del programa y entre los componentes del programa);

Necesidades de información externas (por ejemplo, comunicaciones con los medios, con los contratistas, o con agencias del gobierno); y

Información de los stakeholders, que es, quién necesita estar comunicado con quién, cuán frecuentemente, qué información será comunicada, y los formatos de las comunicaciones.

142



.9 Registro de los Stakeholders

Descrito en la Sección 14.2.3.1. Esto es una entrada crítica a la planificación de las comunicaciones y proporciona una descripción de los stakeholders y ayuda a las decisiones guía sobre las mejores formas de comunicarse con los diferentes stakeholders para asegurar el intercambio óptimo de la información.

.10 Cronograma Maestro del Programa

Descrito en la Sección 6.1.3.1. El cronograma maestro del programa delinea los cronogramas y dependencias individuales del componente entre los componentes del programa incluyendo los proyectos individuales y otros trabajos. El cronograma maestro del programa determina el periodo de los hitos individuales del componente.

10.1.2. Planificar las Comunicaciones: Herramientas y Técnicas

.1 Sistemas de Información de la Gestión del Programa

Descrito en la Sección 4.2.2.1. Los Sistemas de Información de la Gestión del Programa proporcionan los medios para reportar y comunicar el programa con los stakeholders del programa. Estos sistemas son utilizados frecuentemente durante la vida del programa para comunicar el estado, los cambios, y la performance.

.2 Análisis de los Requerimientos de las Comunicaciones

Un análisis de los requerimientos de las comunicaciones resulta en la suma de las necesidades de información de los stakeholders del programa. Esto implica determinar el tipo y formato de la información necesaria y analizar el valor de esa información. Los recursos del programa son gastados sólo en la comunicación de la información que contribuye con el éxito, o donde la falta de comunicación puede llevar a la falla. Esto no significa que no deban compartirse las “malas noticias”, sino que el objetivo es evitar abrumar a los interesados con información intrascendente

El gestor del programa debe considerar el número de los canales o caminos de comunicación potenciales como indicadores de la complejidad de las comunicaciones de un programa. Un componente clave en la planificación de las comunicaciones es decidir quién comunicará qué información a quién.

.3 Métodos de Comunicación

Las metodologías utilizadas para transferir información entre los stakeholders del programa pueden variar significativamente. Por ejemplo, un equipo de gestión de programas puede entablar conversaciones breves o reuniones largas. La información se puede comunicar a través de documentos escritos simples o materiales más complejos como cronogramas y bases de datos.

Los factores de comunicación que pueden afectar al programa incluyen:

Urgencia de la necesidad de información. ¿El éxito del programa depende de tener la información disponible actualizada al momento, o será suficiente emitir regularmente reportes escritos?

143



Disponibilidad de la tecnología. ¿Son apropiados los sistemas con los que ya se cuenta, o las necesidades del programa justifican un cambio?

Personal previsto para el programa. ¿Son los sistemas de comunicaciones propuestos compatibles con la experiencia y especialización de los participantes del proyecto, o se requerirá una extensa formación?

Duración del programa. ¿Es probable que la tecnología disponible cambie antes de que termine el programa?

Entorno del programa. ¿El equipo se reúne y trabaja cara a cara o en un entorno virtual?

10.1.3. Planificar las Comunicaciones: Salidas

.1 Plan de Gestión de Comunicaciones del Programa

El plan de gestión de las comunicaciones del programa está contenido en, o es un plan subsidiario de, el plan de gestión del programa (Sección 4.2.3.1). El plan de gestión de comunicaciones del programa delinea:

Requerimientos de las comunicaciones de los stakeholders; Información que debe ser comunicada, incluidos formato, contenido, y

nivel de detalle; Persona responsable de comunicar la información; Persona o grupos que recibirán la información; Métodos o tecnologías utilizadas para comunicar la información, como

memorandos, correo electrónico y/o comunicados de prensa; Frecuencia de la comunicación; Proceso de escalamiento para identificar los plazos y el personal de la

gestión responsable del escalamiento de problemas que no puedan resolverse a un nivel inferior del personal;

Método para actualizar y refinar el plan de gestión de las comunicaciones a medida que el programa avanza y se desarrolla; y

Glosario de terminología común.

El plan de gestión de comunicaciones del programa también puede incluir pautas para reuniones sobre el estado del programa, reuniones del equipo del programa, reuniones electrónicas y correo electrónico. El plan de gestión de comunicaciones del programa puede ser formal o informal, altamente detallado o ampliamente esbozado, dependiendo de las necesidades del programa.La planificación de las comunicaciones frecuentemente implica crear entregables adicionales que, sucesivamente, requieren esfuerzo y tiempo adicional. Por lo tanto, la estructura de desglose del trabajo del programa, el cronograma del programa, y el presupuesto del programa son actualizados como corresponde.

.2 Registro de Comunicaciones

El gestor del programa o jefe de las comunicaciones del programa debe mantener un registro global de las reuniones y comunicaciones de los stakeholders. El registro debe identificar el quién, qué, cuándo, cómo, y por qué para cada forma de comunicación, incluidas las reuniones de los stakeholders, reportes y memorandos publicados, presentaciones, anuncios, etc.

144



.3 Estrategia de Comunicaciones

Una estrategia de comunicaciones documentada ayudará a asegurar que la comunicación con los stakeholders sea oportuna y relevante. La estrategia de comunicaciones incorpora el registro de los stakeholders, registro de reuniones de los stakeholders y el plan de comunicaciones del programa. Asegura que todos los stakeholders estén comunicados y tengan sus problemas y preocupaciones minuciosamente tratadas.

10.2.Distribuir Información

Distribuir la Información es el proceso de proporcionar información oportuna y precisa a los stakeholders del programa en formatos útiles y medios de comunicación adecuados (Figuras 10–4 y 10–5). La información es distribuida a las tres partes principales de recepción: los clientes, los sponsors, y los gestores del componente. La información distribuida puede incluir lo siguiente:

Información sobre el estado del programa y proyectos, incluidos el progreso, información de costos, análisis de riesgo, y otra información relevante a la audiencias internas o externas;

Notificación de las solicitudes de cambio de los equipos del programa y proyecto, y la respuesta correspondiente a las solicitudes de cambio;

Información presupuestaria interna; Archivos externos con organismos de gobierno y reguladores prescritos

según las leyes y normas; y Anuncios públicos que comunican información útil al público en general.

Figura 10–4. Distribuir Información: Entradas, Herramientas y Técnicas, y Salidas.

145



Figura 10–5. Diagrama de Flujo de Datos de Distribuir Información.

10.2.1 Distribuir Información: Entradas

.1 Plan de Comunicaciones del Programa


.2 Mensajes de las Comunicaciones

Éstos son los mensajes distribuidos a los stakeholders. Los ejemplos incluyen: correos electrónicos, reportes de performance, correos de voz, y presentaciones.

Durante la vida del programa, las solicitudes especiales de información serán frecuentes si los stakeholders sienten que sus necesidades no están siendo satisfechas. Si estas solicitudes especiales se vuelven demasiado agobiantes, pueden ser requeridos cambios en el plan de comunicaciones.

.3 Registro de los Stakeholders


.4 Registro de las Solicitudes de Cambio


.5 Decisión de Gobierno

146




.6 Acta de Constitución del Componente

Descrito en la Sección 15.4.1.2. El acta de constitución del componente puede definir a los stakeholders y entregables del componente, que van a influenciar al plan de gestión de comunicaciones del programa.


Descrito en la Sección 6.1.3.1 y en la Sección 10.1.1.10. El cronograma maestro del programa debe definir el periodo de las diversas comunicaciones del programa.

.8 EDT del Programa

La estructura de desglose de trabajo del programa (EDTP) (descrita en la Sección 5.5.3.1.) es útil al momento de comunicar el tamaño y complejidad del programa. Permite al equipo del programa perfeccionar las estrategias y tácticas de comunicaciones.

El plan de gestión de comunicaciones del programa utiliza la EDT del programa al momento de planificar las diversas comunicaciones del programa.

.9 Registro de las Comunicaciones


.10 Estrategia de Comunicaciones

Descrita en la Sección 10.1.3.3.

10.2.2 Distribuir Información: Herramientas y Técnicas

1. Habilidades de Comunicación

Los gestores de programas deben ser altamente calificados en la comunicación. El gestor del programa debe traducir las metas estratégicas del programa en actividades tácticas diarias. Es importante que el gestor del programa se comunique bien a todos los niveles. Aunque un gestor de programas generalmente se comunica a un nivel mayor que los gestores de proyectos, los gestores de programas deben ser capaces de comunicar fácilmente los detalles a los miembros del equipo del proyecto como conceptos a ejecutivos. Debido a la amplia gama de escenarios de comunicaciones que un gestor de programas puede experimentar, es importante que tenga habilidades de comunicación escrita y oral para el éxito del programa. Los gestores de programas también deben tener buenas habilidades de presentación para asegurar que la información se comunica con bastante precisión y es claramente entendida por los stakeholders. La manera en que el mensaje puede ser interpretado por los receptores y los efectos del mensaje deben ser cuidadosamente considerados antes de la comunicación.

147



Las habilidades de comunicación forman parte de las habilidades de gestión general y se utilizan para intercambiar información. Las habilidades de gestión general relacionadas a las comunicaciones incluyen asegurar que las personas correctas tengan la información adecuada en el momento oportuno, como está definido en el plan de gestión de las comunicaciones. Las habilidades de gestión general también incluyen el arte de gestionar los requerimientos de los stakeholders.

2. Recopilación de Información y Sistemas de Recuperación

La información puede ser recopilada y recuperada a través de una variedad de medios que incluye sistemas manuales de archivo, bases de datos electrónicas, software de gestión de proyectos, y sistemas que permiten el acceso a la documentación técnica como dibujos de ingeniería, especificaciones de diseño, y planes de evaluación.

3. Métodos de Distribución de Información

La Distribución de la Información implica comunicar información a los stakeholders del programa de manera oportuna durante todo el ciclo de vida del programa. La información del programa se puede distribuir a través de una variedad de métodos, que incluyen:

Reuniones cara a cara, distribución de documentos impresos, sistemas manuales de archivo manual, y bases de datos electrónicas de acceso compartido;

Herramientas de comunicación y conferencia electrónica, como correo electrónico, fax, correo de voz, teléfono, videoconferencias y conferencias por Internet, y publicaciones en la web.

Herramientas electrónicas para la gestión de programas, como interfaces web con software de programación y gestión de proyectos, software de soporte para reuniones y oficinas virtuales, portales y herramientas colaborativas de gestión del trabajo; y

Comunicaciones informales que pueden incluir correos electrónicos, conversaciones de grupos pequeños, y reuniones de personal. Éstos son los métodos principales para comunicar las actividades diarias pero no se utilizan para comunicar formalmente el estado del programa.

4. Base de Datos de Lecciones Aprendidas

Las lecciones aprendidas son una compilación de conocimiento aprendido. Este conocimiento se puede adquirir de la ejecución de programas similares y relevantes pasados, o puede residir en las bases de datos de dominio público. Las lecciones aprendidas son activos críticos a ser revisados al desarrollar un plan de gestión de las comunicaciones efectivo. La base de datos de lecciones aprendidas se actualiza al final de los componentes así como al final del programa.

10.2.3 Distribuir Información: Salidas

1. Reportes de Performance del Programa

Existe una variedad de maneras de representar los reportes de estado: tableros de mando, memorandos, presentaciones a los stakeholders, foros de preguntas

148



y respuestas. Éstos son los métodos principales para comunicar el estado de un programa; existen muchos otros métodos formales de comunicación.

2. Actualizaciones de las Lecciones Aprendidas

Las lecciones aprendidas se enfocan en identificar los éxitos y los fracasos del programa y proyecto, e incluye recomendaciones para mejorar la performance futura de los programas y otros proyectos dentro del programa. Durante el ciclo de vida del programa, el equipo del proyecto y los stakeholders clave identifican las lecciones aprendidas respecto a los aspectos técnicos, gerenciales y de procesos del programa. Las lecciones aprendidas se compilan, formalizan y almacenan durante toda la duración del programa.

El centro de atención de las reuniones de lecciones aprendidas varía. En algunos casos, se centrará en los procesos más técnicos o de desarrollo de productos, mientras que en otros se centrará en los procesos que contribuyeron o dificultaron la performance del trabajo. Los equipos pueden recopilar información con más frecuencia si creen que la mayor cantidad de datos merece la inversión adicional de tiempo y dinero. Las lecciones aprendidas proporcionan a los equipos de programas y proyectos futuros la información que puede mejorar la efectividad y la eficiencia de la gestión de programas. Además, las sesiones de lecciones aprendidas al final de cada fase proporcionan un buen ejercicio de formación de equipos. Los gestores del programa tienen la obligación profesional de llevar a cabo las sesiones de lecciones aprendidas para todos los programas con los stakeholders clave internos y externos, especialmente si el proyecto ha producido resultados inferiores a los deseados.

Algunas salidas específicas de las actividades de las lecciones aprendidas incluyen:

Actualización de la base de conocimientos de lecciones aprendidas; Entrada al sistema de gestión del conocimiento; Políticas, procedimientos y procesos corporativos actualizados; Habilidades de negocio mejoradas; Mejoras generales de productos y servicios; y Actualizaciones del plan de gestión de riesgos.

3. Actualizaciones del Plan de Comunicaciones del Programa

Los cambios en el proceso Distribuir Información deben provocar cambios/actualizaciones en el plan de gestión de las comunicaciones del programa.

4. Actualizaciones del Registro de Comunicaciones

Las comunicaciones y cambios claves en el proceso Distribuir Información deben provocar cambios/actualizaciones en el registro de comunicaciones creado durante el proceso Planificar las Comunicaciones.

10.3.Reportar la Performance del Programa

149



Reportar la Performance del Programa es el proceso de consolidar datos sobre la performance para proporcionar a los stakeholders información sobre la manera en que se están utilizando los recursos para entregar los beneficios del programa (Figuras 10–6 y 10–7). El reporte de performance sumariza toda la información de la performance a través de las actividades del proyecto y de las no proyectizadas para proporcionar una imagen clara de la performance global del programa.

Esta información se transmite a los stakeholders por medio del proceso Distribuir Información para proporcionarles la información necesaria sobre el estado y los entregables. Adicionalmente, esta información se comunica a los miembros del equipo del programa y sus proyectos constituyentes para proporcionarles información general y preliminar sobre la performance del programa.

Figura 10–6. Reportar la Performance del Programa: Entradas, Herramientas y Técnicas, y Salidas.

150



Figura 10–7. Diagrama de Flujo de Datos de Reportar la Performance del Programa.

10.3.1 Reportar la Performance del Programa: Entradas

.1 Reportes de Performance del Programa

Descrito en la Sección 10.2.3.1. El gestor del programa reúne el reporte de performance y estado de cada uno de los componentes. El gestor del programa utiliza esta información para construir el reporte de performance del programa que se les presentará a los stakeholders del programa. Estos reportes son el vehículo principal de comunicación entre los gestores del proyecto y el gestor del programa.

La información de la performance del trabajo sobre el estado de finalización de los entregables se reúne como parte de la ejecución del programa, y se ingresa en el proceso de Reportar la Performance. El proceso de reunir la información de la performance del trabajo se trata con más detalle en el proceso Dirigir y Gestionar la Ejecución del Programa (Sección 4.4).

.2 Línea Base de Presupuesto del Programa

Descrito en la Sección 13.4.3.1. El gestor del programa reporta la performance del costo del programa comparando la cantidad actual gastada de dinero con el presupuesto del programa. El análisis de valor ganado se utiliza para ayudar con la creación de un reporte certero sobre la performance y con la proyección de la performance futura. Estos resultados se reportan a los stakeholders con parte de proceso de comunicaciones.


Descrito en la Sección 4.2.3.1. Al referirse frecuentemente al plan de gestión del programa, el gestor del programa puede comparar el plan con la performance de la ejecución actual del programa. Las diferencias entre la ejecución actual y el plan requerirán acciones correctivas.


Descrito en la Sección 6.1.3.1. El gestor del programa reporta la performance del cronograma del programa al comparar el trabajo actual completado con el cronograma del programa. El análisis de valor ganado se utiliza para ayudar

151



con la creación de un reporte certero sobre la performance y con la proyección de la performance futura

.5 Decisión de Ir/No Ir


.6 Reportes de Variaciones

Cuando el resultado final difiere del resultado esperado, se presentan variaciones. Las variaciones pueden ser positivas o negativas. Las métricas medidas pueden ser incluidas en los reportes de variación incluidas las variaciones de costo, variaciones de cronograma, variaciones de calidad, variaciones del número de problemas generados, variaciones en los niveles de satisfacción de los stakeholders, etc. Las acciones correctivas se requerirán para todas las variaciones.

.7 Medición de la Performance

Descrito en la Sección 4.6.


Las solicitudes de cambio aprobadas (Sección 15.7.3.1.) son cambios solicitados para expandir o disminuir el alcance del programa, para modificar el costo estimado, o revisar las estimaciones de duración de las actividades que han sido aprobadas y están listas para ser implementadas por el equipo del programa.

.9 Registro de Riesgos del Programa


.10 Registro de Problemas del Programa


.11 Plan de Realización de Beneficios


.12 Pronósticos

Los pronósticos están basados en los resultados combinados del programa y el análisis del valor ganado y el juicio de expertos. Su objetivo es apoyar a los ejecutivos en la predicción de la probabilidad o logro de los resultados planificados.

10.3.2 Reportar la Performance del Programa: Herramientas y Técnicas

.1 Herramientas de Presentación de Información

Los paquetes de software que incluyen reporte de tablas, análisis de hojas de cálculo, presentaciones, o capacidades gráficas pueden ser utilizados para

152



crear imágenes con calidad de presentación de los datos de performance del programa. Debido a que se requiere frecuentemente que los gestores del programa realicen presentaciones a los diferentes stakeholders, es importante que se encuentren familiarizados con estas herramientas para el éxito del programa.

.2 Recopilación y Compilación del Estado

La información puede recopilarse y compilarse a través de una gran variedad de medios, entre los que se incluyen los sistemas manuales de archivo, las bases de datos electrónicas, el software de gestión de proyectos, y los sistemas que permiten el acceso a documentación técnica como diseños de ingeniería, especificaciones de diseño y planes de prueba, para producir proyecciones, así como reportes de performance, estado y progreso.

Registros del Programa. Los registros del programa pueden incluir correspondencias, memorandos, y documentos que describen el programa. Esta información, al grado posible y apropiado, debe ser mantenida en una manera organizada. Los miembros del equipo del programa también puede mantener registros en un cuaderno de notal del programa.

Reportes del Programa. Los reportes formales y informales del programa detallan el estado del programa e incluyen lecciones aprendidas, registros de problemas, reportes de cierre del programa, y salidas de otras Áreas de Conocimiento.

Presentaciones del Programa. El equipo del programa proporciona información de manera formal e informal a los stakeholders. La información proporcionada debe ser relevante para la audiencia dirigida, y el método de presentación debe ser el apropiado.

Feedback de los stakeholders. La información recibida de los stakeholders referente a las operaciones del programa pueden ser distribuidas y utilizadas para modificar o mejorar la performance futura del programa.

Notificaciones de los stakeholders. La información sobre problemas resueltos, cambios aprobados, y estado del programa general, puede ser proporcionada a los stakeholders.

.3 Reuniones de Revisión del Estado

Las reuniones de revisión del estado son eventos programados regularmente para intercambiar información sobre el programa. En la mayoría de los programas, las reuniones de revisión del estado se celebran con diversas frecuencias y a distintos niveles. Por ejemplo, el equipo de gestión del programa puede reunirse semanalmente por su cuenta y mensualmente con el cliente

.4 Sistemas de Reporte de Tiempo

Los sistemas de reporte de tiempo registran y proporcionan el tiempo invertido en el programa.

.5 Sistemas de Reporte de Costo

153



Los sistemas de reporte de costo registran y proporcionan el costo invertido en el programa.

10.3.3 Reportar la Performance del Programa: Salidas

.1 Reportes de Performance del Programa

El gestor del programa reporta la performance del programa a través de los reportes de performance y tableros de mando del programa. Los reportes de performance organizan y sumarizan la información recopilada y presenta los resultados de cualquier análisis comparado con la línea base de medición de la performance. Los reportes típicamente proporcionan la información sobre estado y progreso al nivel de detalle requerido por los diversos stakeholders según lo documentado en el plan de gestión de las comunicaciones. Los formatos comunes para los reportes de performance incluyen gráficos de barras, curvas S, histogramas, y tablas. Los datos del análisis de valor ganado se incluyen frecuentemente como parte del reporte de la performance.

.2 Pronósticos del Programa

A medida que se ejecuta el programa, los pronósticos se actualizan y reeditan en base a la información sobre la performance del trabajo. Esta información se relaciona con la manera en que la performance pasada del programa podría impactar el programa en el futuro. Los ejemplos sobre pronósticos incluyen estimación a la finalización y estimación hasta la finalización.

.3 Mensajes de Comunicación

Estos son los mensajes que se distribuyen a los stakeholders. Los ejemplos incluyen: correos electrónicos, reportes de performance, correos de voz, y presentaciones.

.4 Reporte de Realización de Beneficios

Los beneficios se pueden realizar ocasionalmente antes de que el trabajo formal del programa haya sido terminado completamente.

Los programas que entregan beneficios incrementales tienen que ser cuantificados de manera que su realización pueda ser medida. Esto incluye las dimensiones del beneficio (por ejemplo, la fecha en que debe empezar la realización) y una cuantificación del beneficio (por ejemplo, horas ahorradas, ganancias incrementadas, participación en el mercado incrementada, fuerza competitiva reducida, o mejoras incrementales de productividad).

El gobierno debe determinar si esto toma lugar dentro de los parámetros requeridos para que los cambios en los proyectos componentes o en el programa total puedan ser propuestos.

El reporte de beneficio mide al componente contra el Plan de Realización de Beneficios. El reporte, que es analizado por el equipo del programa y reportado

154



a los ejecutivos de la empresa, puede causar que el componente sea realineado, terminado, o que comience de nuevo. Ver la Sección 15.6.3.1 para obtener más información sobre beneficios.

155

gestión del alcance del programa

Documents