Gestión del Alcance del Programa

Dharmacon 8,973 views 54 slides Apr 03, 2013
Slide 1
Slide 1 of 54
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40
Slide 41
41
Slide 42
42
Slide 43
43
Slide 44
44
Slide 45
45
Slide 46
46
Slide 47
47
Slide 48
48
Slide 49
49
Slide 50
50
Slide 51
51
Slide 52
52
Slide 53
53
Slide 54
54

About This Presentation

No description available for this slideshow.


Slide Content

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



104

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.

2

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



105

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.

5.8 Monitorear y Controlar el Alcance del Programa : El proceso para
asegurar que el alcance del programa se cont role 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
deConocimiento. 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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



106




















































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

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
.1 Juicio de Expertos
.2 Entrevistas
.3 Grupo de Análisis
.4 Revisiones de Aceptación
del Cliente
.3 Salidas
.1 Actualizaciones del
Enunciado del Alcance del
Programa
.2 Plan de Realización de los
Beneficios
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
.2 Sistemas de Información
de la Gestión del
Programa
.3 Salidas
.1 Enunciado del Alcance del
Programa
.2 Pan de Gestión del
Alcance del Programa
5.6Gestionar la
Arquitectura del Programa
.1 Entradas
.1 Línea Base de la
Arquitectura del Programa
.2 Plan de Gestión del
Programa
.3 Solicitudes de Cambio
.2 Herramientas y
Técnicas
.1 Juicio de Expertos
.2 Análisis del Impacto de los
Cambios
.3 Salidas
.1 Actualizaciones de la Línea
Base de la Arquitectura del
Programa
.2 Solicitudes de Cambio
Aprobadas
.3 Actualizaciones del Plan de
Gestión del Programa
5.5Desarrollar la EDT del
Programa
.1 Entradas
.1 Línea Base de la
Arquitectura del Programa
.2 Documento de los
Requerimientos del
Programa
.3 Documento de los
Requerimientos delos
Componentes
.2 Herramientas y
Técnicas
.1 Juicio de Expertos
.2 Plantillas de la Estructura
de Desglose del Trabajo
.3 Proceso de Planificación
de Gestión
.4 Matriz de Responsabilidad
de Tarea
.5 Herramientas de
Configuración del Sistema
.3 Salidas
.1 EDT del Programa
.2 Matriz de la Estructura de
Desglose del Trabajo
5.3Desarrollar los
Requerimientos del
Programa
.1 Entradas
.1 Enunciado del Alcance del
Programa
.2 Solicitudes de Cambio
.3 Caso de Negocio
.4 Mapa de Ruta del Programa
.2 Herramientas y Técnicas
.1 Recopilación de
Requerimientos
.2 Análisis de Requerimientos
.3 Revisiones de Diseño
.4 Brainstorming
.5 Juicio de Expertos
.6 Validación y Verificación de
los Requerimientos
.3 Salidas
.1 Documento de los
Requerimientos del
Programa
.2 Documentos de los
Requerimientos del
Componente
5.4Desarrollar la
Arquitectura del Programa
.1 Entradas
.1 Documento de los
Requerimientos del
Programa
.2 Herramientas y Técnicas
.1 Conocimiento Técnico
.3 Salidas
.1 Línea Base de Arquitectura
del Programa
5.8Monitorear y Controlar el
Alcance del Programa
.1 Entradas
.1 Enunciado del Alcance del
Programa
.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.7Gestionar las Interfaces
del Componente
.1 Entradas
.1 Línea Base de la
Arquitectura del Programa
.2 Plan de Gestión del
Programa
.3 Solicitudes de Cambio
.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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



107

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,
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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



108

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

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

.1 Enunciado del Alcance del Programa

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,

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



109

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

.2 Plan de Gestión del Alcance del Programa

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.


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 pr ograma 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 stakehold ers, 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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



110
































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

.1 Enunciado del Alcance del Programa

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 e stablece 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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



111

Los entregables del programa.

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

.2 Plan de Gestión del Alcance del Programa

Descrito en la Sección 5.1.3.2.


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

.1 Juicio de Expertos

Descrito en la Sección 5.2.2.1.

.2 Entrevistas

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 Clie nte

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

.1 Actualizaciones del Enunciado del Alcance del Programa

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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



112

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
Asegurar que los resultados planificados del programa sean obtenidos antes
del cierre formal del programa.


5.3 Desarrollar los Requerimien tos 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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



113

























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

5.3.1. Desarrollar los Requerimientos del Programa : Entradas

.1 Enunciado del Alcance del Programa

Descrito en la Sección 5.1.3.1 y 5.2.1.1.

.2 Solicitudes de Cambio

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

.4 Mapa de Ruta del Programa

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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



114

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
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.

.5 Juicio de Expertos

Descrito en la Sección 5.1.2.1.

.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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



115

que los requerimientos son exactos y completos. A medida que evol uciona el
programa y se realizan los cambios, los requerimientos deben ser
continuamente reevaluados por los impactos.

A medida queel programa se desarrolla en etapas posteriores de desarrollo y
construcción, los productos que se están desarrollando debe n 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

.1 Documento de los Requerimientos del Programa

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 Co mponente

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
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 pr oyecto en el
programa concuerde con la arquitectura del programa.

Los objetivos de esta sección son:

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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



116









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




























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


5.4.1. Desarrollar la Arquitectura del Programa : Entradas

.1 Documento de los Requerimientos del Programa

Descrito en la Sección 5.3.3.1.


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,

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



117

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,
procedimientos, estándares, procesos, hitos principales del programa, los productos
entregables dela 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 componentes la 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 conoce n 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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



118

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.

Los objetivos de esta sección son:

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.



























Figura 5–11. Diagrama de Flujo de Datos del ProcesoDesarrollar la EDT del Programa .

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



119

5.5.1. Desarrollar la EDT del Programa: Entradas

.1 Línea Base de la Arquitectura del Programa

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.

.2 Documento de los Requerimientos del Programa

Descrito en la Sección 5.3.3.1.

.3 Documento de los Requerimientos de los Componentes

Descrito en la Sección 5.3.3.2.


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

.1 Juicio de Expertos

Descrito en la Sección 5.1.2.1.

.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
puede ser modificada su bsecuentemente 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 obje tivos 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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



120

.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 el ementos 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.


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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



121









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






























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


5.6.1. Gestionar la Arquitectura del Programa: Entradas

.1 Línea Base de la Arquitectura del Programa

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

.2 Plan de Gestión del Programa

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

.3 Solicitudes de Cambio

Descrito en la Sección 4.4.1.3.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



122


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

.1 Juicio de Expertos

Descrito en la Sección 5.1.2.1.

.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.

.2 Solicitudes de Cambio Aprobada s

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.

.3 Actualizaciones del Plan de Gestión del Programa

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
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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



123













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



































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


5.7.1. Gestionar la Arquitectura del Programa: Entradas

.1 Línea Base de la Arquitectura del Programa

Descrito en la Sección 5.4.3.1.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



124

.2 Plan de Gestión del Programa

Descrito en la Sección 4.2.3.1.

.3 Solicitudes de Cambio

Descrito en la Sección 4.4.1.3.

.4 Plan de Gestión de Comunicaciones del Programa

Descrito en la Sección 10.1.3.1.

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

Descrito en la Sección 14.1.3.2.


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

.1 Juicio de Expertos

Descrito en la Sección 5.1.2.1.

.2 Métodos de Comunicación

Descrito en la Sección 10.1.2.3.

.3 Reuniones de Revisión

Descrito en la Sección 4.6.2.4.

.4 Gestión del Conflicto

Descrito en la Sección 14.4.2.2.


5.7.3. Gestionar la Arquitectura del Programa: Salidas

.1 Solicitudes de Cambio Aprobadas

Descrito en la Sección 5.6.3.2.

.2 Actualizaciones del Plan de Gestión del Programa

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

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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



125

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 dent ro 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.



























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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



126


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

.1 Enunciado del Alcance del Programa

Descrito en la Sección 5.1.3.1.

.2 Solicitudes de Cambio Aprobadas

Descrito en la Sección 5.6.3.2.

.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

Descrito en la Sección 15.1.3.1.

.5 Línea Base de la Arquitectura del Programa

Descrito en la Sección 5.4.3.1.

.6 Plan de Gestión del Programa

Descrito en la Sección 4.2.3.1.


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

.1 Juicio de Expertos

Descrito en la Sección 5.1.2.1.

.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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



127

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

.4 Auditorías

Descrito en la Sección 15.1.3.3.

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

Descrito en la Sección 4.2.2.1.


5.8.3. Monitorear y Controlar el Alcance del Programa: Salidas

.1 Solicitudes de Cambio Aprobada s

Descrito en las Secciones 4.4.3.1 y otras.

.2 Actualizaciones de los Requerimientos del Programa

Descrito en la Sección 5.3.3.1.

.3 Actualizaciones del Plan de Gestión del Programa

Descrito en la Sección 4.3.3.1.

.4 Actualizaciones del Enunciado del Alcance del Programa

Descrito en la Sección 5.2.3.1.

.5 Actualizaciones del Depósito de Docum entos del Programa

Descrito en la Sección 4.2.2.1.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



128

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 individ uales, 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.

Losprocesos 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 per didas 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.
6

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



129



























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 .

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



130


6.1 Desarrollar el Cronograma del Programa


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 media nte 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 interdepend encia 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 cont ratista 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 lo s
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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



131

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.

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 .

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



132

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
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

Descrito en la Sección 5.4.3.1.

.4 Acta de Constitución 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

Descrito en la Sección 11.2.3.1.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



133

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 fe chas
límites para sus componentes propuestos. Una vez que comienza el trabajo a
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 c omponentes 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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



134

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
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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



135

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.2 Monitorear 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 cronogr ama
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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



136
































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 efect o cascada o adverso sobre los

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



137

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 componen tes o
para/remover los componentes existentes.


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

1. Herramientas de Gestión del Cronograma

Descrito en la Sección 6.1.2.1.

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
programasgrandes 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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



138


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.

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 componen te. 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 propor cionan
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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



139

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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



140

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 C omunicaciones 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
10

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



141

Stakeholders del Programa son Áreas de Conocimiento estrechamente relacionadas.
Cada proceso puede implicar esfuerzo de una o más personas o grupos de acuerdo
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 .

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



142

10.1. Planificar las Comunicaciones


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 proye ctos 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úme ro 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
comunicacionescompleja es vital para el éxito de cualquier programa.


















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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



143






































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


10.1.1. Planificar las Comunicaciones: Entradas

.1 Acta de Constitución del Programa

El acta de constitución del programa es la entrada clave al proceso Planificar las
Comunicaciones. Ayuda a determinar los requer imientos 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.

.2 Plan de Gestión del Programa

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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



144

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.

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

Descrito en la Sección 15.1.3.1.

.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.

.6 Enunciado del Alcance del Programa

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

Descrito en la Sección 5.5.3.1.

.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 comunicacion es del programa
incluyen:

Gráficos de la organización;
Matrices de organización y roles y responsabilidad del programa;

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



145

Disciplinas, departamentos, y especialidades involucradas en el proyecto;
Logísticas de la cantidad de personas que estarán involucrada s 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.

.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 comunica rse 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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



146

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?
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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



147

El plan de gestión de comunicaciones delprograma 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 c omunicaciones 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 memor andos publicados, presentaciones, anuncios,
etc.

.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 p rescritos
según las leyes y normas; y
Anuncios públicos que comunican información útil al público en general.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



148
















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





































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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



149

10.2.1 Distribuir Información: Entradas

.1 Plan de Comunicaciones del Programa

Descrito en la Sección 10.1.3.1.

.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

Descrito enla Sección 14.2.3.1.

.4 Registro de las Solicitudes de Cambi o

Descrito en la Sección 15.7.3.2.

.5 Decisión de Gobierno

Descrito en la Sección 15.5.3.1.

.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.

.7 Cronograma Maestro 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 la s 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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



150

.9 Registro de las Comunicaciones

Descrito en la Sección 10.1.3.2.

.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 proy ectos, 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.

Las habilidades de comunicación forman parte de las h abilidades 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:

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



151

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
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, eincluye recomendaciones para mejorar l aperformance
futura de los programas y otros proyectos dentro del programa. Durante el
ciclo devida del programa, el equipo del proyecto y los stakeholders clave
identifican las leccionesaprendidas respecto a los aspectos técnicos, gerenciales
y de procesos del programa. Las leccionesaprendidas 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
algunoscasos, se centrará en los procesos más técnicos o de desarrollo de
productos, mientras que enotros se centrará en los procesos que contribuyeron
o dificultaronla performance del trabajo.Los equipos pueden recopilar
información con más frecuencia si creen que la mayor cantidad dedatos merece
la inversión adicional de tiempo y dinero. Las l ecciones aprendidas
proporcionan a los equipos de programas y proyectos futuros la información

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



152

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 Inform ación
deben provocar cambios/actualizaciones en el registro de comunicaciones
creado durante el proceso Planificar las Comunicaciones.


10.3. Reportar la Performance del Programa


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.

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



153


















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































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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



154

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.

.3 Plan de Gestión del Programa

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.

.4 Cronograma Maestro del Programa

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 v alor ganado se utiliza para ayudar
con la creaciónde un reporte certero sobre la performance y con la proyección
de la performance futura

.5 Decisión de Ir/No Ir

Descrito en la Sección 15.5.3.1.

.6 Reportes de Variaciones

Cuando el resultado final difiere de l 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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



155

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.

.8 Solicitudes de Cambio Aprobadas

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

Descrito en la Sección 11.5.3.2.

.10 Registro de Problemasdel Programa

Descrito en la Sección 4.7.3.2.

.11 Plan de Realización de Beneficios

Descrito en la Sección 5.2.3.2.

.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 crear
imágenes con calidad de presentación de los datos de performance del
programa. Debido a que se r equiere 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

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



156

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 stakehol ders. 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
paraintercambiar información sobre el pro grama. En la mayoría de los
programas, las reuniones derevisión del estado se celebran con diversas
frecuencias y a distintos niveles. Porejemplo, el equipo de gestión del programa
puede reunirse semanalmente por su cuenta ymensualmente 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

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






10.3.3 Reportar la Performance del Programa : Salidas

GOP040v2 – Curso Gestión de Programas


Material de Lectura Nº 02v1



157


.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 benefic ios 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 lo s 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 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.