PS - Scheduling - 3rd (ES)

Machine Translated by Google
ESTÁNDAR DE PRÁCTICA
PARA PROGRAMAR
Beneficio para miembros de PMI con licencia para: Esteban Duran - 4710089. No para distribución, venta o reproducción.
yo
Datos de catalogación en publicación de la Biblioteca del Congreso
Nombres: Instituto de Gestión de Proyectos.

Título: Estándar de práctica para la programación / Project Management Institute.
Descripción: Tercera edición. | Newtown Square: Instituto de gestión de proyectos, 2019. | Edición
revisada del Estándar de práctica para la programación, c2011. | Incluye referencias bibliográficas e
indice.
Identificadores: LCCN 2019009443 (letra impresa) | LCCN 2019010321 (libro electrónico) | ISBN
9781628255621 (ePub) | ISBN 9781628255638 (tipo) | ISBN 9781628255645
(PDF web) | ISBN 9781628255614 (rústica)
Materias: LCSH: Gestión de proyectos--Normas. | BISAC: NEGOCIOS Y ECONOMÍA
/ Gestión de proyectos.
Clasificación: LCC HD69.P75 (ebook) | LCC HD69.P75 P653 2019 (imprimir) | DDC
658.4/04--dc23
Registro LC disponible en https://lccn.loc.gov/2019009443
ISBN: 978-1-62825-561-4
Publicado por:
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pensilvania 19073-3299 EE. UU. Teléfono:
+610-356-4600 Fax: +610-356-4647 Correo electrónico:
customercare@pmi.org Internet: www.PMI.org
©2019 Project Management Institute, Inc. Todos los derechos reservados.
Nuestro contenido con derechos de autor está protegido por la ley de propiedad intelectual de EE. UU. que es reconocida por la mayoría de los países. Para
volver a publicar o reproducir nuestro contenido, debe obtener nuestro permiso. Visite http://www.pmi.org/permissions para obtener más detalles.
Para realizar un pedido comercial o para obtener información sobre precios, comuníquese con Independent Publishers Group:
Independent Publishers Group Order
Department 814 North Franklin Street
Chicago, IL 60610 EE. UU. Teléfono: +1
800-888-4741 Fax: +1 312-337-5985

Correo electrónico: orders@ipgbook.com
(Solo para pedidos)
Para todas las demás consultas, comuníquese con el Centro de servicio de libros de PMI.
PMI Book Service Center PO
Box 932683, Atlanta, GA 31193-2683 EE. UU. Teléfono:
1-866-276-4764 (dentro de EE. UU. o Canadá) o +1-770-280-4129 (a nivel mundial)

Fax: +1-770-280-4113
Correo electrónico: info@bookorders.pmi.org
Impreso en los Estados Unidos de América. Ninguna parte de este trabajo puede ser reproducida o transmitida de ninguna forma o por ningún medio, ya sea electrónico,
manual, fotocopiado, grabación o cualquier sistema de almacenamiento y recuperación de información, sin el permiso previo por escrito del editor.
El papel utilizado en este libro cumple con el Estándar de papel permanente emitido por la Organización Nacional de Estándares de Información (Z39.48—1984).
PMI, el logotipo de PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE
PROFESSION y el slogan HACIENDO LA GESTIÓN DE PROYECTOS INDISPENSABLE PARA LOS RESULTADOS EMPRESARIALES. son todas marcas de Project Management Institute, Inc. Para
obtener una lista completa de las marcas comerciales de PMI, comuníquese con el Departamento Legal de PMI. Todas las demás marcas comerciales, marcas de servicio, nombres comerciales, imágenes
comerciales, nombres de productos y logotipos que aparecen en este documento son propiedad de sus respectivos dueños. Quedan reservados todos los derechos no concedidos expresamente en el presente.
10 9 8 7 6 5 4 3 2 1 Beneficio de
miembro de PMI con licencia para: Esteban Duran - 4710089. No para distribución, venta o reproducción.
AVISO
Las publicaciones de normas y directrices de Project Management Institute, Inc. (PMI), de las cuales el documento contenido en
este documento es uno, se desarrollan a través de un proceso de desarrollo de normas de consenso voluntario. Este proceso reúne
a voluntarios y/o busca la opinión de personas interesadas en el tema tratado en esta publicación.
Si bien PMI administra el proceso y establece reglas para promover la equidad en el desarrollo del consenso, no redacta el documento
y no prueba, evalúa o verifica de forma independiente la precisión o integridad de cualquier información o la solidez de los juicios
contenidos en su publicaciones de normas y directrices.
PMI se exime de responsabilidad por lesiones personales, daños a la propiedad u otros daños de cualquier naturaleza, ya sean
especiales, indirectos, consecuentes o compensatorios, que resulten directa o indirectamente de la publicación, el uso de la aplicación
o la confianza en este documento. PMI renuncia y no ofrece ninguna garantía, expresa o implícita, en cuanto a la exactitud o
integridad de cualquier información publicada en este documento, y renuncia y no garantiza que la información en este documento
satisfaga cualquiera de sus propósitos o necesidades particulares. PMI no se compromete a garantizar el rendimiento de los
productos o servicios de ningún fabricante o vendedor individual en virtud de esta norma o guía.
Al publicar y poner a disposición este documento, PMI no se compromete a prestar servicios profesionales o de otro tipo para o
en nombre de ninguna persona o entidad, ni PMI se compromete a cumplir con ningún deber que una persona o entidad le deba a
otra persona. Cualquier persona que utilice este documento debe basarse en su propio juicio independiente o, según corresponda,
buscar el asesoramiento de un profesional competente para determinar el ejercicio del cuidado razonable en cualquier circunstancia dada.
La información y otros estándares sobre el tema cubierto por esta publicación pueden estar disponibles en otras fuentes, que el
usuario puede desear consultar para obtener vistas adicionales o información no cubierta por esta publicación.
PMI no tiene poder ni se compromete a vigilar o hacer cumplir el contenido de este documento. PMI no certifica, prueba ni
inspecciona productos, diseños o instalaciones con fines de seguridad o salud. Cualquier certificación u otra declaración de
cumplimiento con cualquier información relacionada con la salud o la seguridad en este documento no será atribuible a PMI y es
responsabilidad exclusiva del certificador o autor de la declaración.
tercero
TABLA DE CONTENIDO
1. INTRODUCCIÓN............................................... .................................................... .......................1
1.1 Programación del proyecto ............................................... .................................................... .......2

1.2 ¿Por qué programar?.................................... .................................................... ...................3 1.3
Descripción general ...................... .................................................... ..........................................5
1.4 Propósito.................................................. .................................................... ........................7 1.5

Aplicabilidad ...................... .................................................... ..........................................7
2. PRINCIPIOS Y CONCEPTOS DEL MODELO DE LISTA ........................................... .........................9

2.1 Descripción general .................................. .................................................... ......................9
2.2 Ciclos de vida del proyecto y enfoques de programación ........................................... .............10

2.2.1 Enfoque de ruta crítica ............................... .................................................... ....14
2.2.2 Cadena Crítica ........................................... .................................................... ........18
2.2.3 Ciclo de Vida Adaptativo................................................ .............................................21
2.2.4 Planificación ola de rodadura ............................................... .....................................23
2.2.5 Otros enfoques y tendencias emergentes.... .................................................... ..25 2.3
Herramienta de programación .................................. .................................................... .............28
2.4 Modelo de Horario ............................... .................................................... ..........................29
2.5 Programar instancias y presentaciones del modelo ........................................... ...............30
2.6 Ágil .................................................. .................................................... ..........................31 2.6.1

Seguimiento y presentación .................. .................................................... .............38
V
3. RESUMEN DE BUENAS PRÁCTICAS DEL MODELO DE CRONOGRAMA .................................. ......................45
3.1 Gestión de horarios.................................................... ..........................................................45 3.1.1 Plan

de gestión de datos del cronograma....................................... ..................46 3.1.2 Plan de gestión
del cronograma .................. .................................................... ......47 3.1.2.1 Enfoque de
programación ...................................... ..........................48 3.1.2.2 Herramienta de
programación ........... .................................................... ...........48 3.1.2.3 Plan de creación
del modelo de cronograma .................. ..................................48 3.1.2.4 ID del modelo de
programación ......... .................................................... ..........49 3.1.2.5 Instancia del modelo
de programación .................. ..................................49 3.1.2.6 Calendarios y Períodos de
Trabajo .... .................................................... .....49 3.1.2.7 Ciclo de actualización del
proyecto y granularidad de la actividad ........ ........................50 3.1.2.8 Estructura de

codificación de hitos y actividades .................. .......................51 3.1.2.9 Planificación de
recursos ............... .................................................... ....52 3.1.2.10 Indicadores clave de
rendimiento ....................................... ...........52 3.1.2.11 Modelo de programa
maestro .................. .......................................53 3.1.2.12 Control de
cambios... .................................................... ..........................53 3.2 Creación del modelo de

cronograma .................. .................................................... .......................53
3.2.1 Desarrollar la línea base del modelo de cronograma .................................. .......................55

3.2.1.1 Definir hitos ........................... .................................................... .....55 3.2.1.2 Definir
las Actividades del Proyecto ........................................... ....................55 3.2.1.3 Secuencia

de actividades.................... .................................................... 59 3.2.1.4 Determinación de
los recursos para cada actividad .................................. ..61 3.2.1.5 Determinación de la
duración de cada actividad .................................. .62 3.2.1.6 Analizar la salida del
cronograma........................................... ...........62 3.2.1.7 Aprobar el Modelo de
Cronograma........................... ..................................64 3.2.1.8 Línea base del modelo de
cronograma ....... .................................................... .65 3.2.1.9 Niveles de
programación ........................................... ....................................sesenta y cinco
3.3 Programar el mantenimiento del modelo ........................................... ..........................................67
3.3.1 Recopilación de datos reales y trabajo restante o duración .................................. .67 3.3.2
Actualizar el modelo de cronograma de acuerdo con los reales ...........................68
VI Tabla de contenido
3.3.3 Comparar y abordar cualquier desviación ........................................... ...........68 3.3.4

Actualizar el modelo de cronograma con los cambios aprobados .................. ..........69 3.3.5
Actualizar el modelo de cronograma de línea base .................. ....................................69 3.3.6
Comunicar ......... .................................................... ..........................................69
3.3.7 Mantener los registros .................................................. ..........................................70
3.3.8 Control de cambios ............................................. .................................................... .70 3.4

Análisis del modelo de cronograma ........................................... .............................................71 3.4 .1
Ruta Crítica y Actividades Críticas.................................................. ......................71 3.4.1.1
Ruta crítica ...................... .................................................... ..............71 3.4.1.2
Actividades Críticas.................................. .............................................72 3.4 .2
Flotación total y flotación libre ........................................... .....................................72 3.4.3
Estimación de la duración de las actividades ..... .................................................... ..............74

3.4.4 Restricciones de fecha.................................. .................................................... ..............76
3.4.5 Actividades abiertas.................................................... ..........................................77 3.4.6

Fuera de secuencia ( OOS) Lógica .................................................. ..........................79 3.4.7
Adelantos y retrasos .................. .................................................... .............................81 3.4.8
Relación de principio a fin ........... .................................................... ..............82 3.4.9 Enlaces
a/desde Resumen de actividades........................... ...................................83 3.4.10 Programar
análisis de recursos... .................................................... ....................83 3.4.11 Evaluación de
riesgos del cronograma .................. .................................................... ..83
3.4.12 Calendario Ganado ............................................. .............................................85
3.5 Comunicación e informes ............................................... .....................................88
4. COMPONENTES DEL PROGRAMA .................................................. .................................................... ..93
4.1 Cómo usar la lista de componentes........................................... .....................................94 4.1.1

Nombre del componente ....... .................................................... ....................................94 4.1.2
Uso requerido, condicional u opcional.... .................................................... .....94 4.1.3 Manual
o Calculado........................................... ..........................................94
4.1.4 Formato de datos ............................................. .................................................... ......95
4.1.5 Comportamiento ............................................. .................................................... ...........95
4.1.6 Buenas Prácticas .................................. .................................................... .............95
VII
4.1.7 Pagaré Condicional/Componente Asociado........................................... .............95

4.1.8 Definición .............................................. .................................................... .........95
4.2 Lista de componentes por categoría ........................................... .....................................96
4.3 Lista detallada de componentes ............................................. .............................................98
5. ÍNDICE DE CONFORMIDAD ............................................... .................................................... ........137
5.1 Resumen de conformidad ............................................... .............................................137
5.1.1 Categorías de componentes ............................................. ..........................138

5.1.2 Uso de los componentes del cronograma .................................. ............................138
5.1.3 Evaluación de la conformidad ............................................... ...............................139
5.2 Proceso de evaluación de la conformidad ............................................... .............................140
APÉNDICE X1
CAMBIOS EN LA TERCERA EDICIÓN ........................................... .................................................... ........143
APÉNDICE X2
COLABORADORES Y REVISORES DEL ESTÁNDAR DE PRÁCTICAPOR
PLANIFICACIÓN- TERCERA EDICION ............................................... ..........................................145
X2.1 Estándar de práctica para Planificación – Comité Central de la Tercera Edición ...................145
X2.2 Revisores .............................................. .................................................... ..........146
X2.2.1 Revisión de PYME.................................................... .................................................... ..146
X2.2.2 Revisión final del proyecto de norma ............................................... ..........................146
X2.3 Grupo Asesor de Miembros del Programa de Estándares del PMI (MAG) .................................. 148
X2.4 Revisión del cuerpo de consenso ........................................... .............................................148

X2.5 Personal de producción ............................................. .................................................... .......149
APÉNDICE X3
TABLA DE PUNTUACIÓN DE LA EVALUACIÓN DE LA CONFORMIDAD .................................. ........................151
APÉNDICE X4
HOJAS DE TRABAJO PARA LA EVALUACIÓN DE LA CONFORMIDAD .................................. ..........................159
viii Tabla de contenido
APÉNDICE X5
ANÁLISIS DEL HORARIO FORENSE ............................................... ..........................................165
REFERENCIAS .................................................. .................................................... ........................169
GLOSARIO................................................. .................................................... .............................171
ÍNDICE .................................................. .................................................... ....................................195
IX
LISTA DE TABLAS Y FIGURAS
Figura 1-1. Programar el desarrollo y el uso del modelo ........................................... ......................6
Figura 2-1. Continuidad del ciclo de vida .............................................. .............................................10
Figura 2-2. Ejemplo de Diagrama de Flujo Predictivo ............................................... .......................11
Figura 2-3. Diagrama de flujo iterativo .............................................. ..........................................11
Figura 2-4. Un ciclo de vida de incrementos de tamaño variable .................................. ....................11
Figura 2-5. Diagrama de flujo adaptativo .............................................. ..........................................12
Figura 2-6. Enfoques predictivos y adaptativos combinados utilizados ..........................................13
Figura 2-7. Flujo del modelo de cronograma................................................... ..............................................15
Figura 2-8. Diagrama de flujo para el modelo de cronograma asignado

a los procesos del área de conocimiento de la guía PMBOK ® .................................. .....................dieciséis
Figura 2-9. Ejemplo de diagrama CPM ............................................... ..........................................18
Figura 2-10. Tampones de alimentación ................................................ .................................................... ..20
Figura 2-11. Amortiguadores del proyecto ................................................ .................................................... ...21
Figura 2-12. Diagrama de Incertidumbre ............................................... ..........................................22
Figura 2-13. Ejemplos de enfoques ágiles ............................................... ..........................23
Figura 2-14. Ejemplo de planificación de ondas móviles—Planificación

Paquete 1 Descompuesto ............................................... ..........................................24
Figura 2-15. Ejemplo de planificación de ondas móviles—Planificación

Paquete 2 Descompuesto .................................................. .......................................24 Figura
2-16. Ejemplo de horario basado en la ubicación ........................................... ..........................25
XI
Figura 2-17. Programar instancias de modelos y presentaciones ............................................... ......30
Figura 2-18. Ejemplo de Múltiples Iteraciones o Sprints ............................................... ...............32
Figura 2-19. Ciclo de Vida Adaptativo Típico ............................................... ....................................33
Figura 2-20. Resultados de la reunión de planificación de Sprint (iteración) .................................. ........34
Figura 2-21. Tablero de Scrum que muestra Sprint (iteración) 1 ........................................... .............35
Figura 2-22. Tablero Kanban ................................................. .................................................... ....36
Figura 2-23. Ejemplo de Dependencias Funcionales entre Requerimientos..........................37 Figura
2-24. Diagrama de Burndown típico con trabajo planificado.................................... ..........38
Figura 2-25. Gráfico Burndown con trabajo restante ............................................... ...........39
Figura 2-26. Gráfico de avance con iteración suavizada de progreso ...........................................40
Figura 2-27. Gráfico Burndown—Compromiso no cumplido.................................................... ..........40
Figura 2-28. Gráfico Burndown con trabajo restante ............................................... ...........41
Figura 2-29. Burndown Chart con compromisos cumplidos ............................................... ..............41
Figura 2-30. Ejemplo de un gráfico de quemado ............................................... ....................................42
Figura 2-31. Relaciones entre la visión del producto, la planificación de la

versión y la planificación de la iteración .................................. .................................................... 43
Figura 3-1. Resumen de actividades ................................................. ..........................................57
Figura 3-2. Actividad LOE ................................................ .................................................... ..........58
Figura 3-3. Actividad de la hamaca ................................................ .................................................... 58
Figura 3-4. Ilustraciones de tipos de relaciones en la metodología CPM....................................60
Figura 3-5. Relaciones de actividad requeridas ............................................... .............................61
Figura 3-6. Flotación total y flotación libre ............................................... .............................................73
Figura 3-7. Ejemplo de Diagrama de Precedencia con Estimaciones

de Duración de Actividad PERT .................................. .................................................... .....75
XII Lista de tablas y figuras
Figura 3-8. Ejemplo de Desviación Estándar de una Actividad ........................................... ...........76
Figura 3-9. Ejemplo de Extremos Abiertos por Omisión ............................................... ..........................78
Figura 3-10. Ejemplo de apertura virtual .............................................. ..........................................79
Figura 3-11. Ejemplo de lógica fuera de secuencia ........................................... .............................80
Figura 3-12. Anulación de progreso frente a lógica retenida ........................................... .....................81
Figura 3-13. Adelantos frente a retrasos ........................................... .................................................... ......82
Figura 3-14. Nivelación de recursos................................................. ..........................................84 Figura
3-15. Ejemplo de Distribución de Probabilidad de Duración para una Actividad Única .........85
Figura 3-16. Relación entre ES, PV y EV ........................................... ........................86
Figura 3-17. Informe de horario ganado .................................................. ....................................87
Figura 3-18. Ejemplos de presentaciones del cronograma del proyecto .................................. ...............91
Figura X4-1. Hoja de trabajo base................................................. ..........................................................160
Figura X4-2. Hoja de trabajo de ejemplo de recursos requeridos .................................. .............161
Figura X4-3. Hoja de trabajo de ejemplo de recurso, EVM y riesgo requerido .......................... 162
Figura X4-4. Hoja de trabajo de ejemplo de recursos y riesgos requeridos .......................... 163
Figura X4-5. Hoja de trabajo de ejemplo sin puntuación ............................................... .........................164
Tabla 3-1. Fórmulas de calendario ganado ............................................... ......................................88
Tabla 3-2. Niveles de presentaciones de instancias del modelo de cronograma .................................. ....90
Tabla 4-1. Lista de componentes por categoría ............................................... ..........................97
Tabla 5-1. Número de componentes por categoría ............................................... .......................140
Tabla X3-1. Ejemplo de tabla de puntuación de la evaluación de la conformidad .................................. 152
XIII
1
INTRODUCCIÓN
El Estándar de práctica para la programación proporciona el marco para crear, administrar y mantener programaciones en un entorno
de proyecto. Este estándar de práctica contiene cinco secciones principales. Cada sección proporciona información adicional sobre el
contenido y la terminología utilizada en este estándar de práctica:
Sección 1 Introducción. Esta sección proporciona una introducción a la programación y sus beneficios, así como una descripción
general del desarrollo y uso de modelos de programación.
Sección 2—Principios y conceptos del modelo de programación. Esta sección proporciona orientación e información sobre los principios
y conceptos asociados con la creación y el uso de modelos de programación en entornos predictivos, adaptativos o híbridos.
Sección 3—Resumen de las buenas prácticas del modelo de cronograma. Esta sección proporciona orientación e información
sobre las buenas prácticas generalmente aceptadas asociadas con los procesos de planificación, desarrollo, mantenimiento, comunicación
y generación de informes de un enfoque de modelo de programa de método de ruta crítica (CPM) efectivo.
Sección 4—Componentes de Programación. Esta sección proporciona un catálogo detallado de los componentes potenciales de un
Herramienta de programación de CPM.
Sección 5—Índice de Conformidad. Esta sección proporciona una descripción general del proceso del índice de conformidad.
Proporciona un método para evaluar qué tan bien un modelo de cronograma de CPM incorpora los componentes, las pautas, las
definiciones, los comportamientos y las buenas prácticas descritas en este estándar de práctica.
Los apéndices contenidos en este estándar de práctica son:
Apéndice X1—Cambios en la tercera edición
Apéndice X2—Contribuidores y revisores del Estándar de Práctica para Programación – Tercera Edición
Apéndice X3—Tabla de puntuación de la evaluación de la conformidad
Apéndice X4—Hojas de trabajo de evaluación de conformidad
Apéndice X5—Análisis forense del cronograma
1
Este estándar de práctica incluye enfoques adaptativos como ágil (consulte las Secciones 2.2.3 y 2.6). Sin embargo, la mayor parte del contenido de
este estándar de práctica, excepto donde se indique, describe un enfoque tradicional (es decir, predictivo) para la programación utilizando CPM. Se puede
encontrar información adicional sobre ágil en la Guía de práctica ágil [1].1
La Sección 1 proporciona una descripción general del contenido de este estándar de práctica y se divide de la siguiente manera:
1.1 Programación del proyecto
1.2 ¿Por qué programar?
1.3 Resumen
1.4 Propósito
1.5 Aplicabilidad
1.1 PROGRAMACIÓN DEL PROYECTO
La programación de proyectos asegura el desarrollo de modelos de cronograma efectivos a través de la aplicación de habilidades, herramientas,
técnicas e intuición adquiridas a través del conocimiento, la capacitación formal e informal y la experiencia. Un modelo de cronograma organiza e integra
racionalmente varios componentes del proyecto (p. ej., actividades, recursos y relaciones lógicas) para optimizar la información disponible para el equipo
de gestión del proyecto y facilitar la probabilidad de una finalización exitosa del proyecto dentro de la línea base del cronograma aprobado. Los términos
clave del modelo de cronograma se definen de la siguiente manera:
tu hito. El Léxico de Términos de Gestión de Proyectos de PMI [2] define un hito como: Un punto o evento significativo en una cartera, programa o
proyecto. A los efectos de esta norma, un hito es un punto o evento significativo en un proyecto definido con una duración de períodos de tiempo
cero.
uActividad . El Lexicon [2] define una actividad como: Una parte distinta y programada del trabajo realizado durante el curso de un proyecto. A los
efectos de esta norma, una actividad es una porción de trabajo programada única y distinta con una duración superior a cero períodos de tiempo,
que se realizará durante el curso de un proyecto.
tu recurso. Un recurso humano calificado (disciplinas específicas, ya sea individualmente o en cuadrillas o equipos), equipos, servicios, suministros,
productos básicos, materiales, presupuestos o fondos necesarios para realizar el trabajo definido.
u Relación lógica. Una dependencia entre dos actividades o entre una actividad y un hito.
1 Los números entre paréntesis se refieren a la lista de referencias al final de este estándar de práctica.
2 Sección 1
Los términos herramienta de programación, modelo de cronograma, instancia de modelo de cronograma y presentación de cronograma se definen en el
glosario de este estándar de práctica y se describen a continuación:
u Herramienta de programación. Una herramienta que proporciona nombres de componentes del cronograma, definiciones, relaciones estructurales, formatos,
y algoritmos para el cálculo de horarios que soportan la aplicación de un método de programación.
u Modelo de horario. Una representación del plan para ejecutar las actividades del proyecto, incluidas las duraciones, las dependencias y otra información
de planificación, que se utiliza para producir una programación del proyecto junto con otros artefactos de programación. El modelo de cronograma es
dinámico y lo desarrolla y mantiene el equipo del proyecto con aportes de las partes interesadas clave. Aplica un enfoque de programación seleccionado
a una herramienta de programación utilizando datos específicos del proyecto. El modelo de programación puede ser procesado por una herramienta de
programación para producir varias instancias del modelo de programación.
u Programar instancia de modelo. Una versión del modelo de programación que ha sido procesada por una herramienta de programación basada en
entradas y ajustes realizados a los datos específicos del proyecto dentro de la herramienta de programación. El planificador guarda las instancias del
modelo de programación como registros del proyecto y como referencia, incluida la fecha de los datos, la versión (basada en un ciclo de actualización
completado), los modelos de programación objetivo y el modelo de programación de referencia. Las instancias pueden producir varias presentaciones de
horarios. Cuando se usan juntas, las instancias admiten la generación y el análisis de informes, como el análisis de varianza y de riesgo.
u Programar presentación. Salida publicada de una instancia de modelo de cronograma utilizada para comunicar datos específicos del proyecto para
informes, análisis y toma de decisiones. Las presentaciones pueden incluir gráficos de barras, rutas críticas, rutas casi críticas, perfiles de recursos,
asignaciones de actividades, líneas base, registro de logros, riesgos/problemas, etc. Las presentaciones también pueden proporcionar pronósticos
basados en el tiempo e identificar desviaciones de desempeño a lo largo del ciclo de vida del proyecto.
1.2 ¿POR QUÉ PROGRAMAR?
Los proyectos son esfuerzos temporales complejos; sin embargo, un modelo de cronograma detallado que contiene trabajo lógicamente relacionado permite
que el proyecto se simplifique en fases manejables o agrupaciones de actividades. Estas fases o agrupaciones permiten a la gerencia optimizar las compensaciones
entre alcance, costo y cronograma. El desempeño del proyecto se informa y supervisa cuando el progreso con respecto a estas actividades e hitos se registra
dentro del modelo de cronograma. A medida que se registra el progreso de un proyecto, el esfuerzo restante, tal como se define en la línea de base aprobada,
requiere una nueva evaluación.
La ejecución de un proyecto a menudo procede de manera diferente al plan inicial y la línea de base. En un entorno de proyecto típico, se hace necesario refinar el
modelo de cronograma debido a (a) una planificación incompleta o inadecuada, (b) una mayor descomposición del alcance del proyecto, (c) cambios significativos
en el proyecto, (d) cambios organizacionales, o (e ) cambios ambientales. Esta evolución iterativa es necesaria para predecir, reconocer y abordar los factores y
problemas en evolución que podrían afectar potencialmente el rendimiento del proyecto.
3
La clave para el éxito del proyecto es aplicar el conocimiento y la experiencia para crear un plan de gestión de proyectos creíble. El plan de
gestión del proyecto equilibra de manera óptima el costo, los recursos, el alcance y el desempeño basado en el tiempo con el compromiso del
equipo del proyecto para ejecutar el proyecto de acuerdo con el plan. La programación es uno de los requisitos básicos de la planificación y el
análisis de proyectos. El modelo de cronograma, una vez completado, se convierte en una herramienta de planificación efectiva para (a)
comunicaciones atractivas que se enfocan en optimizar acciones futuras, (b) ayudar a la colaboración proactiva y (c) crear un sistema de gestión
del desempeño del proyecto.
La programación proporciona los detalles que representan quién, cómo, dónde y cuándo los recursos del proyecto asignados entregarán los
productos, servicios y resultados definidos en el alcance del proyecto. El plan detallado sirve como herramienta para gestionar las actividades a
realizar, las comunicaciones y las expectativas de las partes interesadas. También sirve como base para los informes de desempeño. El director
del proyecto, junto con el equipo del proyecto, utiliza el cronograma del proyecto (línea de base y progreso real) como una herramienta principal
para planificar, ejecutar y controlar todas las evoluciones basadas en el proyecto. El modelo de cronograma se utiliza para rastrear, pronosticar y
monitorear el desempeño del proyecto a lo largo de su ciclo de vida.
La naturaleza dinámica de la ejecución de un proyecto se atiende mejor con una herramienta que permita el modelado del proyecto, las
dependencias internas y externas del proyecto y el análisis debido al impacto de los eventos de progreso y riesgo. El modelo
El concepto busca que el modelo de cronograma reaccione a las entradas (actualizaciones de progreso, elaboración progresiva, cambios en la
definición del alcance (WBS), etc.) ya que el equipo del proyecto espera que el proyecto funcione en función de esas entradas. Los siguientes son
ejemplos de cómo el modelo de cronograma respalda el proyecto al permitir:
u Escalonamiento temporal de las actividades requeridas;
u Restricciones que limitan las opciones para gestionar una cartera, programa, proyecto o proceso;
u Planificación de recursos;
u Movilización de los recursos planificados de la manera más eficiente;
u Coordinación de eventos dentro del proyecto y entre otros proyectos;
u Representación visual de estos problemas de cronograma para las partes interesadas;
u Detección temprana de riesgos, problemas, cuestiones u oportunidades;
u Implementación de acciones para lograr los objetivos del proyecto según lo planeado;
u Análisis hipotético y de varianza;
u Planificación de costos; y
u Pronóstico de estimación al completo y por completar.
4 Sección 1
1.3 VISIÓN GENERAL
Este estándar de práctica describe los componentes del modelo de programación (consulte la Sección 4) y las buenas prácticas generalmente reconocidas
para los procesos de programación. Generalmente reconocido significa que el conocimiento y las prácticas descritas son aplicables a la mayoría de los
proyectos la mayor parte del tiempo. Además, existe consenso sobre el valor y la utilidad de los conocimientos y las prácticas. Buena práctica significa que
existe un acuerdo general de que la aplicación de estas habilidades, herramientas y técnicas puede aumentar la probabilidad de éxito en una amplia gama de
proyectos. La buena práctica no significa que el conocimiento descrito deba aplicarse siempre de manera uniforme a todos los proyectos; significa que el
equipo del proyecto es responsable de determinar qué es apropiado para un proyecto determinado. El uso adecuado de los componentes y sus prácticas da
como resultado un modelo de cronograma utilizable para la planificación, ejecución, seguimiento y cierre, además de la entrega del alcance del proyecto a los
interesados. Aunque se incluyen enfoques de programación y ciclos de vida adicionales, este estándar de práctica describe un enfoque tradicional (es decir,
predictivo) para la programación utilizando el enfoque CPM.
La creación del modelo de programación comienza con la selección de un enfoque de programación y una herramienta de programación que admita el
enfoque de programación deseado. Luego, comenzando con la WBS, los datos específicos del proyecto se incorporan dentro de la herramienta de
programación para crear un modelo de programación único. Las instancias del modelo de programación son instantáneas capturadas del modelo de programación.
Los programadores producen varias presentaciones a partir de estas instancias del modelo de programación en función de los datos específicos del proyecto.
Consulte la Figura 1-1 para comprender mejor las interrelaciones de los conceptos y la terminología de creación del modelo de programación.
Este proceso da como resultado un modelo de cronograma para la ejecución, el seguimiento y el control del proyecto que responde de manera predecible al
progreso y los cambios. El modelo también se utiliza para atraer comunicaciones hacia la optimización proactiva de acciones futuras. El programador debe
actualizar periódicamente el modelo de programación para reflejar el progreso y los cambios, como el alcance, la duración, los hitos, los recursos asignados,
las tasas de productividad, los medios de logro, las variaciones, las evaluaciones de riesgos y la lógica de programación.
Este estándar de práctica también proporciona una evaluación que se puede utilizar para determinar qué tan bien se ajusta el modelo de cronograma a
este estándar de práctica. Se desarrolla un índice de conformidad (consulte la Sección 5 de este estándar de práctica) determinando qué componentes se
usan y cómo se usan dentro del modelo de cronograma. Para obtener una evaluación de conformidad aceptable, un modelo de cronograma, como mínimo,
debe contener todos los componentes requeridos descritos en la Sección 4 y el Apéndice X3. La selección de una herramienta de software de programación
adecuada brinda acceso a los componentes necesarios para desarrollar el modelo de programación. El uso de este estándar de práctica, junto con la
experiencia, habilidad y madurez organizacional, proporciona la guía adecuada para la aplicación de los componentes.
La inclusión de un componente en este estándar de práctica no tiene necesariamente ninguna relación con los problemas de tamaño o complejidad del
proyecto. Este estándar de práctica asume que todos los modelos de cronograma deben tener los componentes, comportamientos básicos y buenas prácticas
requeridos. El tamaño y la complejidad del proyecto solo dan como resultado cambios en la escala y la repetición del
componentes requeridos. Una guía para el cuerpo de conocimientos de gestión de proyectos (PMBOK) para abordar® Guía) [3] proporciona procesos
los factores relacionados con el tamaño y la complejidad del proyecto. Además, la definición de generalmente reconocida también
5
Datos específicos del

proyecto (p. ej., WBS, actividades,
recursos, duraciones,
dependencias, restricciones,
calendarios, hitos, retrasos, etc.)
Planificación Planificación Calendario

Acercarse Herramienta Modelo
Proyecto
Información
Por ejemplo,
CPM, ágil
Calendario
Modelo
Instancias
Ejemplos de presentaciones
Diagrama de Red
Que hacer Haciendo Hecho
1 5 11 5 4 1
11 4 2 13 8 2
13 13 21 14 13
Gráfico de barras
18 18
20
Lista de actividades
Tablero Kanban
Figura 1-1. Programar el desarrollo y uso del modelo
6 Sección 1
asume que no hay diferencias significativas para el uso de los componentes requeridos con respecto a las prácticas de programación de
varias industrias. A medida que las prácticas evolucionen y se desarrollen dentro de la comunidad de gestión de proyectos después de la
publicación de este estándar de práctica, la definición de generalmente reconocida también evolucionará. Se pueden agregar más componentes
al conjunto básico y las buenas prácticas deben ser menos subjetivas.
1.4 PROPÓSITO
Este estándar de práctica proporciona estándares y pautas que utilizan la gestión eficaz del cronograma para un proyecto al proporcionar
conocimientos sobre la creación y el mantenimiento de modelos de cronograma. Este estándar de práctica amplía la información contenida en
la Sección 6 de la Guía del PMBOK® .
Este estándar de práctica establece un conjunto básico de componentes requeridos que se utilizarán para establecer un modelo de
cronograma que cumpla con un nivel mínimo aceptable de madurez (consulte la Sección 3) y un método para evaluar el cumplimiento de un
modelo de cronograma con este estándar.
El objetivo de este estándar de práctica es crear modelos de cronograma que sean valiosos para los proyectos que representan.
Este estándar de práctica no pretende proporcionar una guía completa sobre cómo desarrollar un modelo de cronograma.
Para obtener instrucciones completas sobre cómo desarrollar un modelo de horario, consulte los cursos y libros de texto sobre el tema.
1.5 APLICABILIDAD
Este estándar de práctica se aplica a los profesionales de la gestión de proyectos que conocen los fundamentos de la programación de
proyectos, tal como se describe en este estándar de práctica. A los efectos de este estándar de práctica, estos profesionales se conocerán
como programadores. Este estándar de práctica se centra en los enfoques utilizados en un ciclo de vida predictivo (específicamente CPM),
pero incluye consideraciones relacionadas con los enfoques utilizados en ciclos de vida adaptativos (específicamente ágiles).
CPM es el enfoque más común para la programación de proyectos, pero la prevalencia de los ciclos de vida adaptativos, como Agile, ha
aumentado significativamente desde la edición anterior del estándar de práctica, especialmente en el desarrollo de software.
Los enfoques utilizados en un ciclo de vida adaptativo definen un plan, pero reconocen que una vez que comienza el trabajo, las prioridades
pueden cambiar y el plan debe reflejar esta nueva información. Estos enfoques también funcionan bien para proyectos que experimentan altos
niveles de incertidumbre e imprevisibilidad en mercados globales competitivos.
Finalmente, este estándar de práctica incluye una consideración ampliada de algunas de las prácticas emergentes para los enfoques de
programación de proyectos, como la programación basada en la ubicación.
7
La premisa de este estándar de práctica es que: (a) el lector tenga un conocimiento práctico básico de los Grupos de Procesos
de Dirección de Proyectos y las Áreas de Conocimiento definidas en la Guía del PMBOK®, (b) el proyecto tenga una estructura
de desglose del trabajo (EDT) que cumple con los procesos definidos en el Estándar de Práctica para Estructuras de Desglose
del Trabajo [4], y (c) se ha realizado una planificación suficiente.
A medida que avanza el desarrollo del cronograma, se pueden aplicar estándares de práctica relacionados, como la Guía de
práctica ágil [1], el Estándar para la gestión del valor ganado [5] y el Estándar para la gestión de riesgos en carteras, programas
y proyectos [6].
Este estándar de práctica se aplica solo a proyectos individuales, no a carteras o programas. Sin embargo, debido a que las
carteras y los programas son colecciones de proyectos individuales, cualquier modelo de cronograma individual dentro de esas
estructuras debe utilizar y evaluarse de acuerdo con este estándar de práctica.
Una organización que adopta los principios y buenas prácticas descritos en este estándar de práctica y los aplica globalmente
en toda la organización garantiza que todos los modelos de cronograma desarrollados en apoyo de la propuesta de valor
estratégico de la organización se realicen de manera uniforme en toda la organización.
8 Sección 1
PRINCIPIOS Y CONCEPTOS DEL MODELO DE LISTA

Esta sección proporciona orientación e información sobre los principios y conceptos asociados con el modelo de cronograma.
creación y uso dentro de entornos predictivos o adaptativos. Esta sección cubre los siguientes temas:
2.1 Resumen
2.2 Ciclos de vida del proyecto y enfoques de programación
2.3 Herramienta de programación
2.4 Modelo de horario
2.5 Programar instancias y presentaciones del modelo
2.6 Ágil
Las Secciones 2.2 a 2.5 vinculan los procesos descritos en esta sección con las buenas prácticas descritas en la Sección 3
y los componentes de programación definidos en la Sección 4.
2.1 VISIÓN GENERAL
El plan de gestión del cronograma identifica el enfoque de programación y la herramienta de programación utilizada para crear el modelo de programación.
La creación del modelo de programación incorpora los procesos definidos asociados con el esfuerzo de programación del proyecto durante la planificación.
Un proceso para crear un modelo de cronograma que satisfaga las necesidades del proyecto y sus partes interesadas comienza durante la planificación
del proyecto.
La Sección 2.2.1 proporciona una descripción general de la creación del modelo de programación. Programe los principios y conceptos del modelo con
las consideraciones relacionadas con la adaptación y otros enfoques emergentes aparecen en las Secciones 2.2.3 y 2.2.4.
9
2.2 CICLOS DE VIDA DEL PROYECTO Y ENFOQUES DE PROGRAMACIÓN
Ningún tipo de ciclo de vida es perfecto para todos los proyectos o para todas las partes de un proyecto. En cambio, cada ciclo de vida
del proyecto cae dentro del continuo que se muestra en la Figura 2-1, que proporciona un equilibrio óptimo de características para su contexto.
Se pueden utilizar varios enfoques de programación dentro de los ciclos de vida descritos.
Alto
incrementales Adaptado
Frecuencia
entrega
de continuo
Bajo
Profético Iterativo
Bajo Alto
Grado de cambio
Figura 2-1. Continuidad del ciclo de vida
Los cuatro ciclos de vida que se muestran en la Figura 2-1 son los siguientes:
u Ciclo de vida predictivo. La figura 2-2 ilustra un diagrama de flujo predictivo típico. Este ciclo de vida aprovecha los proyectos o
productos que son conocidos y probados, lo que permite que ocurra la planificación principal antes de la ejecución del proyecto.
Esto reduce la incertidumbre y la complejidad y permite a los equipos segmentar el trabajo en una secuencia de agrupaciones
predecibles. CPM es un enfoque predictivo.
10 Sección 2
Analizar Diseño Construir Prueba Entregar
Figura 2-2. Ejemplo de diagrama de flujo predictivo
u Ciclo de vida iterativo. La figura 2-3 representa un diagrama de flujo iterativo típico. Este ciclo de vida permite la retroalimentación
sobre el trabajo parcialmente completado o sin terminar para mejorar y modificar ese trabajo.
Refinar Refinar Refinar
Desarrollar prueba Construir

Analizar Diseño Entregar
de concepto Prueba
Figura 2-3. Diagrama de flujo iterativo
u Ciclo de vida incremental. La figura 2-4 muestra un diagrama de flujo incremental típico. Este ciclo de vida proporciona entregables
terminados que el cliente puede usar de inmediato, creando valor temprano para el proyecto.
Analizar Analizar Analizar

Diseño Diseño Diseño
Construir Construir Construir
Prueba Prueba Prueba
Entregar Entregar Entregar
Figura 2-4. Un ciclo de vida de incrementos de tamaño variable
11
u Ciclo de vida adaptativo. La figura 2-5 representa un ciclo de vida adaptativo típico. Este ciclo de vida aprovecha los
aspectos de las características iterativas e incrementales. Cuando un equipo usa ciclos de vida adaptativos, itera a lo
largo del proyecto para crear entregables terminados. El equipo obtiene retroalimentación temprana y brinda visibilidad,
confianza y control al cliente. El proyecto puede proporcionar un retorno de la inversión más temprano porque el equipo
puede lanzar antes y entregar primero el trabajo de mayor valor. Este ciclo de vida funciona bien cuando el nivel de incertidumbre es alto.
Agile es un enfoque adaptativo.
Ágil basado en iteraciones
Requisitos Requisitos Requisitos Requisitos Requisitos Requisitos
Análisis Análisis Análisis Análisis Análisis Análisis

Repita
Diseño Diseño Diseño Diseño Diseño Diseño
según sea necesario
Construir Construir Construir Construir ... Construir Construir
Prueba Prueba Prueba Prueba Prueba Prueba
NOTA: Cada caja de tiempo es del mismo tamaño. Cada timebox da como resultado funciones probadas que funcionan.
Ágil basado en flujo
Requisitos Requisitos Requisitos Requisitos

Requisitos
Análisis Análisis Análisis Análisis
Análisis
Diseño Diseño Diseño Diseño
Diseño
Repita
Construir Construir Construir Construir
Construir según sea necesario
Prueba Prueba
Prueba
... Prueba Prueba
el número de el número de el número de el número de

el número de características
características en el características en el características en el características en el
en el límite WIP
límite de trabajo en curso límite de trabajo en curso límite de trabajo en curso límite de trabajo en curso
NOTA: En flujo, el tiempo que lleva completar una función no es el mismo para cada función.
Figura 2-5. Diagrama de flujo adaptativo
12 Sección 2
u Ciclos de vida híbridos. La figura 2-6 muestra un diagrama de flujo híbrido típico. No es necesario utilizar un único ciclo de vida
para todo un proyecto. Los proyectos a menudo combinan elementos de diferentes ciclos de vida para lograr ciertos objetivos.
Una combinación o uso híbrido de predictivo, iterativo, incremental y/o adaptativo puede ser apropiado para etapas o partes de
un proyecto.
Adaptativo Adaptativo Adaptativo Predictivo Predictivo Predictivo
Adaptado Adaptado Adaptado
Profético Profético Profético
Figura 2-6. Enfoques predictivos y adaptativos combinados utilizados
Un punto clave con respecto a los ciclos de vida mencionados anteriormente es que cada tipo comparte el elemento de planificación.
Lo que diferencia a un tipo de otro no es si se planifica, sino cuánto se planifica y cuándo.
El enfoque de programación proporciona la estructura para la creación del modelo de programación. El enfoque de programación más
común, compatible con la mayoría de las herramientas de programación, es el método de diagrama de precedencia (PDM). PDM es una
técnica utilizada para construir un modelo de cronograma en el que las actividades están representadas por nodos y están vinculadas
gráficamente por una o más relaciones lógicas para mostrar la secuencia en la que se realizarán las actividades. PDM se conoce
comúnmente como CPM. CPM puede usar técnicas de cadena crítica, planificación de ondas continuas, evaluación de programas y
revisión (PERT) y programación maestra integrada (IMS). Las interdependencias críticas entre las actividades y los subproyectos deben
incluirse en el cronograma.
El primer paso en la creación del modelo de cronograma es la selección de un enfoque apropiado. Algunas organizaciones estandarizan
una herramienta de software específica y definen sus propios enfoques de programación preferidos, aplicando estándares para su uso.
En ese caso, la decisión del enfoque de programación a menudo ya se ha tomado, ya que es inherente a la herramienta y no es necesario
volver a tomarla. Dado que es el enfoque más utilizado, este estándar de práctica se centra en CPM (un enfoque predictivo) con
consideraciones relacionadas con enfoques ágiles y otros emergentes.
13
2.2.1 ENFOQUE DE LA RUTA CRÍTICA
CPM se refiere al enfoque predominante utilizado en las herramientas de programación modernas y ayuda a identificar el tiempo más corto para completar
el proyecto. El enfoque de la ruta crítica se utiliza para derivar las actividades críticas que no se pueden retrasar sin retrasar la fecha de finalización del
proyecto. Un principio básico de CPM es que cada actividad está impulsada por una o más actividades anteriores. La red CPM pura permite solo flotación total
cero o positiva en la ruta crítica del proyecto. Las herramientas modernas de CPM se adaptan a una variedad de características para mejorar la viabilidad del
cronograma del proyecto. Estas características incluyen recursos, calendarios (proyecto, actividad y recurso), restricciones, diversas definiciones de criticidad,
duraciones transcurridas, retrasos, clientes potenciales, dependencias externas, prioridades de actividad y la asignación de fechas de inicio y finalización reales
a las actividades. Estas características adicionales introducen la posibilidad de valores flotantes negativos y variables a lo largo de la ruta crítica.
Generalmente, el enfoque utilizado en estas herramientas es el método de diagramación de precedencia (PDM). Este estándar de práctica sigue esa
convención de uso común pero usa el término CPM.
La figura 2-7 ilustra una descripción general del flujo del modelo de cronograma.
Dentro de este proceso de modelado, todas las actividades e hitos requeridos del proyecto se definen y secuencian para lograr los objetivos del proyecto.
La creación del modelo de cronograma incluye los siguientes procesos relacionados con las Áreas de conocimiento de Gestión del cronograma del proyecto y
Gestión de recursos del proyecto en la Guía del PMBOK ® (consulte la Figura 2-8):
u Definir actividades,
u Secuencia de actividades,
u Estimar los recursos de la actividad,
u Estimar la duración de las actividades, y
u Desarrolle el cronograma.
El modelo de programación genera instancias de modelo de programación a partir de las cuales se crean presentaciones (consulte la Figura 2-7).
Las instancias del modelo de cronograma pueden representar la línea de base aprobada, los objetivos seleccionados o los modelos de cronograma hipotéticos.
La creación del modelo de cronograma da como resultado un modelo de cronograma aprobado utilizado por los procesos en los Grupos de Procesos de
Ejecución y Monitoreo y Control (consulte el PMBOK ® Guía). El modelo de cronograma reacciona de manera predecible y lógica al progreso
y los cambios del proyecto. Una vez creado y aprobado (línea de base establecida), el programador actualiza el modelo de programación para respaldar los
intervalos de informes regulares del proyecto de acuerdo con el plan de gestión del cronograma y para reflejar el progreso y los cambios.
14 Sección 2
Proyecto
comienzo Método de ruta crítica, método de
diagramación de precedencia o método de cadena
crítica, por ejemplo.
Este enfoque a menudo es inherente a la

selección de herramientas de programación, ya
Seleccione que la mayoría de las herramientas de programación

modernas son implementaciones de software de
Planificación un enfoque de programación particular. Muchas
Acercarse empresas ya han hecho esta selección para todos
los proyectos.
Seleccione La selección de un enfoque de programación

puede limitar la elección de herramientas.
Planificación
Muchas empresas ya han hecho esta selección
Herramienta
para todos los proyectos.
Ingresar
Proyecto específico
Datos
Calendario Modelo de horario

Modelo Instancias y
Presentaciones
Actualizar y
Estado
Proyecto
Completo
Figura 2-7. Programar el flujo del modelo
15
Gestión de modelos de horarios
Procesos de PM Programar la creación de modelos
Nombre del proyecto Definir

Proyecto Hitos
Id. de horario
Definir
Definir el Alcance Actividades
5.3 6.2
Secuencia
de
Actividades 6.3
Crear EDT 5.4

Estimar los recursos
de la actividad 9.2
Adquirir
Recursos 9.3 Estimar la duración de
las actividades 6.4
Desarrollar
el Anexo
Realizar
6.5*
adquisiciones
12.2
Analizar
Modelo de horario
Producción
Factores ambientales de la empresa/

Activos de procesos organizacionales
Aprobar el
Modelo de horario
Procesos de PM Programar el mantenimiento del modelo
Desarrollar el Plan
de Gestión del línea de base el
Proyecto 4.2 Modelo de horario
directo y
Horario
Gestionar
de control
el trabajo del
proyecto 4.3 6.6*
*Estos procesos están definidos en el

Factores ambientales de la empresa/ Guía del PMBOK® y no se puede cambiar; sin
Activos de procesos organizacionales embargo, lo que se está desarrollando y
controlando es el modelo de cronograma.
Figura 2-8. Diagrama de flujo para el modelo de cronograma asignado a los procesos del área de conocimiento de la guía PMBOK ®
dieciséis Sección 2
CPM determina la duración mínima total del proyecto y la fecha de finalización más temprana posible del proyecto. CPM también determina
la cantidad de flexibilidad de programación (flotación total) en el modelo de programación. Para aplicar CPM, se desarrolla un modelo de
cronograma que se compone de actividades del proyecto. Las fechas de inicio y finalización anticipadas se calculan para cada actividad por
medio de un pase hacia adelante desde una fecha de inicio de proyecto específica. Las fechas de inicio y finalización tardías se determinan para
cada actividad mediante un pase hacia atrás, a partir de la fecha de finalización anticipada del proyecto determinada durante el cálculo del pase
hacia adelante o desde una fecha de finalización específica del proyecto (restricción).
Para establecer una ruta crítica significativa, es necesario desarrollar una red de actividades basada en la lógica con duraciones derivadas
empíricamente para su ejecución de una manera realista y práctica. Estas relaciones lógicas pueden ser de carácter físico (necesidad de
estructuras de soporte, llegada de los recursos necesarios, etc.) y la secuencia deseada del plan de ejecución (norte a sur, interior a exterior,
etc.). Al construir la red de programación, se puede crear un bucle sin querer, donde una ruta de actividades vuelve a sí misma. En la mayoría
de los casos, la herramienta de programación dejará de calcular y proporcionará una notificación del bucle detectado. Los extremos abiertos en
un cronograma son aquellas actividades que carecen de un antecesor y/o
o una actividad sucesora, creando así un agujero o brecha en la lógica del cronograma de principio a fin del proyecto. Los únicos extremos
abiertos que son aceptables son los hitos de inicio y finalización del proyecto. El uso de restricciones, incluidos adelantos y retrasos, debe
restringirse a aquellas condiciones que no se pueden definir y modelar adecuadamente mediante la aplicación de la lógica de la actividad.
CPM ilustra las relaciones entre las actividades de izquierda a derecha (por fases), lo que permite que las actividades del proyecto fluyan
desde un hito de inicio del proyecto hasta el hito de finalización del proyecto. Las relaciones entre las actividades con fases de tiempo se
representan mediante flechas direccionales. Las relaciones lógicas necesitan ser satisfechas.
En CPM, una actividad se puede conectar desde su inicio o su finalización. Esto permite una presentación lógica de principio a fin sin
necesidad de dividir más el trabajo. Otra característica de los diagramas CPM es el uso de componentes de adelanto y atraso.
Un ejemplo de un diagrama de red se muestra en la Figura 2-9.
17
Actividad B
comienzo Actividad A Actividad D Finalizar
Actividad C
Duración de la actividad
Comienzo temprano Final temprano
(Días)
Enlace(s) de Vínculos a
Antecesores) sucesor(es)
Nombre de la actividad
(Incluya los ID de agrupación apropiados)
Flotación total (días)

Inicio tardío Fin tardío
Costo (moneda)
Figura 2-9. Ejemplo de diagrama CPM
2.2.2 CADENA CRÍTICA
La cadena crítica se centra en la actividad del modelo de cronograma del proyecto y las dependencias de los recursos. La cadena crítica
elimina efectivamente la mayor parte de la contención de recursos antes de que comience el proyecto y utiliza amortiguadores para el
control del proyecto. Reduce los cambios del proyecto y la principal fuente de sobrecostos del proyecto al mejorar el rendimiento del
cronograma. Logra estos resultados cambiando el sistema de medición y control del proyecto junto con ciertos comportamientos del equipo
del proyecto y el personal de apoyo.
18 Sección 2
La disponibilidad de recursos compite con la capacidad de ejecutar tareas en las fechas planificadas. Como tal, muchos programas de
software permiten nivelar los recursos (para que no se sobrecarguen), lo que puede extender la duración del proyecto y las fechas de inicio
y finalización programadas para las actividades. Teniendo en cuenta la disponibilidad de recursos, el modelo de programación resultante
puede contener una ruta crítica con recursos limitados y es el punto de partida para la programación de la cadena crítica. El enfoque de
cadena crítica se desarrolla a partir de CPM y considera los efectos de la asignación de recursos, la nivelación de recursos y la incertidumbre
de la duración de la actividad en la ruta crítica determinada por CPM.
La cadena crítica crea un cronograma de proyecto nivelado de recursos agresivo (pero no necesariamente detallado). El principio
fundamental del proceso de la cadena crítica radica en el hecho de que dentro de una cadena sistémica de acciones casi siempre hay una
acción que está restringida o limitada por los recursos, lo que afecta el rendimiento de toda la cadena.
La fecha de finalización del proyecto se define como el final de la cadena crítica, incluidos los amortiguadores para dar cuenta de los
riesgos, incertidumbres y retrasos del proyecto. Durante la ejecución del proyecto, cuando las actividades consumen una duración mayor a
la prevista por la cadena crítica, el buffer del proyecto se consume gradualmente. De acuerdo con el grado de consumo de búfer, el equipo
del proyecto puede abordar las acciones correctivas necesarias; de “no hay necesidad de reaccionar” a “planificar la respuesta” a “ejecutar
la respuesta planificada para recuperar la reserva del proyecto”. Siempre que el total de desfases sea menor que la reserva, hay un efecto
limitado en el alcance, la duración y el presupuesto del proyecto. Este enfoque se denomina gestión de búfer.
La ruta nivelada de recursos más larga a través del cronograma, incluidos los búferes, es la cadena crítica. La cadena crítica a menudo
es diferente de la ruta crítica en CPM. Los factores que definen la cadena crítica son las actividades de amortiguación, los recursos que no
son multitarea, la nivelación de recursos y la gestión de amortiguación.
La cadena crítica comienza con un modelo de cronograma de CPM, pero se diferencia de CPM en cuatro aspectos principales:
u La cadena crítica asume que riesgos significativos e inesperados que no estaban previstos se materializarán durante un
proyecto y requieren acciones proactivas.
u El foco de atención gerencial permanece fijo durante todo el proyecto en la cadena crítica y la tasa de
consumo de tampón.
u La cadena crítica considera la magnitud de la contención de recursos (basada en la teoría de las restricciones) en el
cálculo de la duración del proyecto y programación de las actividades.
u En lugar de que los márgenes se distribuyan y oculten en actividades individuales, los márgenes se exponen y agregan en reservas,
lo que reduce la exposición al riesgo del proyecto.
19
Los buffers se toman de las duraciones planificadas de las actividades y no aumentan la duración del proyecto. La cadena crítica
introduce tres tipos de amortiguadores: amortiguadores de alimentación, amortiguadores de recursos y amortiguadores de proyectos de la siguiente manera:
u Tampones de alimentación. Como se muestra en la Figura 2-10, los amortiguadores de alimentación son amortiguadores (en duración) agregados al
modelo de cronograma donde las cadenas de tareas no críticas alimentan una tarea de cadena crítica.
15 días de retraso búfer de 20 días
Ruta A Buffer
En la fecha prevista
Ruta B Buffer
15 días antes Empezar 5 días antes
Ruta C Ruta fusionada
Figura 2-10. Tampones de alimentación
u Buffers de recursos. Las reservas de recursos actúan como señales de alerta temprana que aseguran la disponibilidad oportuna de los recursos del
proyecto al notificar al equipo sobre estos requisitos de recursos. Se establecen a lo largo de la cadena crítica para garantizar que los recursos estén
disponibles para trabajar en las actividades tan pronto como se necesiten. A diferencia de los búferes de proyecto y los búferes de alimentación, los
búferes de recursos no son tiempos de seguridad agregados al proyecto y no cambian el tiempo transcurrido del proyecto.
u Amortiguadores de proyectos. Los amortiguadores de proyecto típicos se muestran en la Figura 2-11. Los amortiguadores del proyecto son duraciones
agregadas al final del proyecto entre la última actividad del proyecto y la fecha de entrega final o la fecha de finalización contratada.
Los amortiguadores se pueden determinar estadísticamente, pero en su mayoría se definen mediante el uso de reglas generales (la mitad de la duración de
las actividades). Los márgenes de seguridad agregados se asignan a cadenas de actividades individuales. Los amortiguadores se crean (a) asignando tiempos
de realización de actividades agresivos para eliminar cualquier margen de seguridad oculto y (b) agregando los ahorros resultantes de los tiempos planificados
en amortiguadores. La cantidad de reserva del proyecto se puede derivar como la contingencia del cronograma resultante del análisis de riesgo cuantitativo (por
ejemplo, Monte Carlo). En lugar de repartir los márgenes de seguridad entre todas las actividades, un margen de seguridad se concentra al final de una cadena y
se usa solo si se materializa el riesgo (cualquiera que sea, lo que genera incertidumbres sobre los recursos y la duración). Este efecto de administrar la tasa de
consumo del búfer es similar a administrar la flotación total y la flotación libre en el enfoque de CPM, pero a menudo es más eficaz y eficiente.
20 Sección 2
Método del camino crítico
Actividad A
Actividad B
Método de la cadena crítica Actividad C
Actividad A
Actividad D
Actividad B
Actividad C
Actividad D
Buffer
Figura 2-11. Búferes de proyecto
2.2.3 CICLO DE VIDA ADAPTABLE
Los proyectos van desde trabajos definibles con requisitos de alcance conocidos hasta trabajos de alta incertidumbre en los que el
alcance y los enfoques del proyecto no se conocen tan bien (consulte la Figura 2-12). Los proyectos de trabajo definibles se caracterizan por
procedimientos y procesos que han demostrado ser exitosos en proyectos similares en el pasado. La producción de un automóvil, un
electrodoméstico, un edificio o una casa una vez finalizado el diseño son ejemplos de trabajo definible que utiliza un enfoque lineal. El
dominio de producción y los procesos involucrados generalmente se comprenden bien, y la cantidad de incertidumbre y riesgo generalmente
es manejable.
Los nuevos diseños, la resolución de problemas y los proyectos no realizados anteriormente se consideran exploratorios. Requieren
expertos en la materia para colaborar y resolver problemas específicos para crear una solución. Los ejemplos de trabajo de alta incertidumbre
incluyen la ingeniería de software y el diseño de productos. A medida que se automatiza un trabajo más definible, los equipos de proyectos
emprenden más proyectos de alta incertidumbre que requieren los enfoques más adecuados para un enfoque adaptativo como Agile.
21
Fundamentalmente
arriesgado
Caos complejo complicado
Adaptado
Simple enfoques
trabaja bien aquí
Lineal
enfoques
trabaja bien aquí
Incertidumbre baja Incertidumbre alta
Grado Técnico de Incertidumbre
Figura 2-12. Diagrama de Incertidumbre
Los proyectos de alta incertidumbre tienen altas tasas de cambio, complejidad y riesgo. Estas características pueden presentar problemas para
los enfoques predictivos tradicionales que tienen como objetivo administrar la mayor parte de los requisitos por adelantado y controlar los cambios
a través de un proceso de solicitud de cambio. Ágil es un término general para muchos enfoques adaptativos. Permite a los gerentes de proyecto
ajustarse rápidamente a las necesidades de las partes interesadas, así como a cualquier comentario que el equipo reciba interna o externamente.
Hay muchos enfoques bajo el paraguas ágil como se refleja en la Figura 2-13. Dos de los enfoques más populares son Scrum y Kanban.
22 Sección 2
Inclinarse
Ágil
Kanban
ScrumBan
Cristal
PUA
Melé
FDD
XP
DSDM
Figura 2-13. Ejemplos de enfoques ágiles
2.2.4 PLANIFICACIÓN DE ONDAS ROLLING
La planificación de ondas móviles es una técnica de planificación iterativa en la que el trabajo que se realizará a corto plazo
se planifica en detalle, mientras que el trabajo futuro se planifica con un nivel de detalle más bajo. La técnica de planificación de
onda continua, a veces denominada "elaboración progresiva", asume que es muy probable que el equipo del proyecto tenga
información precisa y detallada sobre las actividades a corto plazo de la onda actual y menos información sobre las actividades
en las olas futuras del proyecto. . Al utilizar la planificación de ondas continuas, es importante realizar la planificación detallada a
intervalos regulares. La planificación detallada para el próximo intervalo debe completarse antes del inicio de la ejecución de la
próxima ola. Las duraciones de las olas definen los límites dentro de los cuales se agregará el trabajo detallado en una fecha posterior.
23
Para períodos más allá de la fase de planificación detallada, las actividades se enumeran como paquetes de planificación con mucho menos
detalle. Estos paquetes de planificación contienen información sobre costos y recursos, que se fija en la duración y el costo de referencia para
un enfoque de CPM. Cuando se lleva a cabo una planificación detallada, se reemplazan los paquetes de planificación con detalles adicionales.
Las Figuras 2-14 y 2-15 ilustran un ejemplo de planificación de ondas móviles. Los conceptos de planificación de olas también se aplican a
algunos enfoques adaptativos.
Marzo Abril Mayo Junio Julio agosto
18 25411 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 1 8 15 22 29 5
Paquete de planificación 1
Actividad A
Actividad B
Actividad C
Actividad D
Figura 2-14. Ejemplo de planificación de ondas móviles: paquete de planificación 1 desglosado
Marzo Abril Mayo Junio Julio agosto
18 25411 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 1 8 15 22 29 5
Actividad A
Actividad B
Actividad C
Actividad D
Actividad E
Actividad F
Actividad G
Figura 2-15. Ejemplo de planificación de ondas móviles: paquete de planificación 2 desglosado
24 Sección 2
2.2.5 OTROS ENFOQUES Y TENDENCIAS EMERGENTES
Otros enfoques y tendencias emergentes para la programación son:
u Programación basada en la ubicación. La programación basada en la ubicación (LBS) se desarrolló para ayudar a los gerentes de
proyectos en la industria de la construcción con los flujos de trabajo y la planificación. LBS también se conoce como método de producción
vertical, programación lineal, método de programación repetitiva, producción uniforme y programación de línea de flujo.
El enfoque de programación LBS desarrolla un programa que muestra la ubicación y la hora de un evento, además del movimiento de las
cuadrillas a través del tiempo y el espacio (consulte la Figura 2-16). Este enfoque se enfoca en optimizar las tasas de producción para
muchos recursos que trabajan en paralelo, a menudo en múltiples frentes de trabajo. Las diferentes tareas del proyecto deben proceder
en el mismo flujo para crear una progresión constante sin pérdida de tiempo. Con frecuencia, el modelo contiene una ubicación geográfica
de las actividades en el proyecto. LBS se utiliza para planificar o registrar el progreso de múltiples actividades que se mueven
continuamente en secuencia. El método se visualiza mediante una herramienta gráfica.
El principal atractivo de este método sobre CPM es su idea subyacente de optimizar la utilización de recursos. El progreso del trabajo se
ve fácilmente y la secuencia de diferentes actividades de trabajo se entiende fácilmente. Este enfoque se utiliza predominantemente en
proyectos de construcción horizontal a gran escala (p. ej., vías férreas, autopistas, oleoductos, líneas de transmisión) y proyectos de
construcción vertical (p. ej., acondicionamiento piso por piso de rascacielos). Los proyectos industriales a veces usan un híbrido de este
enfoque.
Tiempo Excavación Instalación Modelo de horario basado en la ubicación

2,200
M1 250 2,000
1,800
M2 670 250
1,600
M3 830 670 1,400
1200
M4 1,010 830 1,000
800
M5 1,400 1,010 600
400
M6 1,543 1,400
200
M7 1,715 1,543 0
M1 M2 M3 M4 M5 M6 M7 M8 M9
M8 2,020 1,715 Tiempo
M9 2,020
Excavación Instalación
Figura 2-16. Ejemplo de horario basado en la ubicación
25
u Programación bajo demanda. La programación bajo demanda se utiliza normalmente en un entorno adaptativo. Los enfoques bajo
demanda se basan en conceptos de programación basados en pull de manufactura esbelta. El propósito de la programación a pedido es
limitar el trabajo en curso (WIP) de un equipo para equilibrar la demanda con el rendimiento de entrega de un equipo. Es preferible que el
equipo del proyecto sea ágil y receptivo para que el producto del trabajo pueda entregarse “justo a tiempo”. La demanda y la capacidad
siempre fluctúan; por lo tanto, el balanceo ocurre cuando el trabajo ingresa al sistema, no antes. Otros enfoques de programación hacen
suposiciones sobre los productos de trabajo, lo que dificulta tomar medidas de equilibrio una vez que el trabajo se incluye en un proyecto.
Usando un enfoque de extracción, el trabajo de aguas abajo toma (extrae) trabajo de aguas arriba solo cuando aguas abajo tiene la
capacidad de continuar con el nuevo trabajo. Los sistemas pull requieren que las etapas de trabajo tengan límites para el trabajo en curso
(límites WIP).
Una vez que se establece un flujo, ayuda a estimar la finalización del trabajo. Dichos sistemas son más predecibles y tienen menos
variaciones no deseadas, lo que minimiza el desperdicio en el proceso. La planificación elimina los cuellos de botella, impulsando así el
valor del modelo de programación. Una vez que se eliminan los cuellos de botella o las restricciones, se crea un flujo de proceso eficiente
que equilibra el rendimiento de la entrega.
u Programación ajustada. La programación ajustada se basa en los principios de la entrega de proyectos ajustados (programación bajo
demanda) y está diseñada para minimizar el desperdicio a fin de maximizar el valor. Para lograr este objetivo, los entregables no se
asignan al equipo. Los principios de programación ajustada apuntan a la importancia de limitar las colas extrayendo trabajo cuando hay
capacidad para colocar el trabajo en el proceso. Los miembros del equipo del proyecto colaboran en sesiones de planificación de
extracción donde se definen las actividades esenciales, las duraciones y las transferencias entre operaciones para completar los hitos.
Los pasos principales son:
n Programación maestra. Identifica hitos clave, actividades esenciales y fases. Este cronograma detallado es
creado por el equipo del proyecto.
n Programación de fases. Utiliza las fases identificadas en el programa maestro. Trabajando hacia atrás (tirando), la duración, las
secuencias, las restricciones y la coordinación en cada fase se establecen en colaboración. El equipo acuerda el plan y lo ejecuta
como equipo. El resultado de este cronograma de fases se utiliza para generar cronogramas anticipados.
n Planificación prospectiva. Maximiza la confiabilidad al hacer coincidir el flujo de trabajo con la capacidad. Los planes detallados para el
trabajo a realizar se establecen utilizando planes de trabajo semanales y se mantiene una acumulación de trabajo listo.
u Sistemas inteligentes. Los sistemas inteligentes consideran la inteligencia artificial aplicada a la programación de proyectos que se basa
en el aprendizaje automático. El aprendizaje automático utiliza algoritmos para analizar datos, aprende de ellos y luego toma una
determinación o predicción. En base a eso, en lugar de realizar una secuencia de actividades manualmente, ingresa un conjunto de
suposiciones y requisitos de actividad, como restricciones, lógica estricta, recursos y condiciones (IF-THEN-ELSE). Como tendencia
emergente, los sistemas inteligentes se han aplicado ampliamente en todas las industrias.
Para fines de programación, un escenario posible es que el modelo de programación aprenda del progreso realizado y proponga una
nueva secuencia de relaciones en función de las entradas para las actividades que quedan por realizar.
Otra posibilidad es que el modelo de cronograma aprenda de los modelos de cronograma de otros proyectos y, en función de los patrones
identificados, el modelo de cronograma recomiende el nivel de evitación de contingencias para materiales, proveedores,
26 Sección 2
o trabajadores. Los algoritmos identifican grupos de actividades con comportamientos específicos e identifican patrones donde las actividades
pueden analizarse para comprender cómo evitar o explotar dichos patrones.
u Línea de equilibrio. La línea de equilibrio (LOB) se desarrolló inicialmente para planificar y controlar los procesos industriales de fabricación.
Posteriormente, se amplió su uso como método de planificación y control de proyectos con actividades repetitivas o de larga duración.
El enfoque de LOB está en las tasas de producción (unidades) a lo largo del tiempo para actividades repetitivas, en lugar de definir y rastrear
actividades discretas a lo largo del tiempo. Esto da como resultado una visualización que muestra el flujo de trabajo y las unidades producidas.
LOB muestra el trabajo repetitivo en el proyecto como una sola línea en un gráfico en lugar de una serie de actividades individuales en un
diagrama de barras. Esta línea representa la velocidad a la que se debe realizar el trabajo para cumplir con el cronograma. LOB puede ayudar
a exponer los cuellos de botella del proceso. La principal ventaja de LOB es que calcula la productividad junto con el tiempo en una sencilla
representación gráfica.
u Modelado de información de construcción. El modelado de información de construcción (BIM) es un proceso que crea y gestiona información
sobre las características físicas y funcionales de un edificio. Se utiliza para apoyar la toma de decisiones durante todo el ciclo de vida de un
edificio.
La recopilación de información del proyecto en un depósito central brinda la oportunidad de integrar el modelo de diseño 3D del proyecto (alto/
ancho/profundidad) y el modelo de cronograma. El software BIM permite la identificación de secuencias para los objetos de diseño que se
convierten en la lógica subyacente para el modelo de cronograma. En BIM, el tiempo se considera la cuarta dimensión. Agregar la dimensión
del tiempo a BIM permite que el cronograma se vincule con objetos de datos en un nivel apropiado de detalle y que el proyecto se construya
virtualmente. También permite probar diferentes opciones antes de decidir el mejor enfoque desde una perspectiva de programación. El costo
se puede incorporar como una quinta dimensión. Un enfoque BIM integrado admite lo siguiente:
n Estimación de costos,
n coordinación 3D,
n Adquisición/prefabricación oportuna,
n Planificación y seguimiento de la construcción,
n Visualización de un modelo 4D de ejecución planificada, y
n Modelo de registro del uso del ciclo de vida del propietario.
La visualización del modelado 4D BIM incorpora datos de fecha de inicio y finalización para el suministro e instalación de componentes de
construcción y revela la importancia de estos en relación con el proyecto general. BIM elimina el desafío provocado por la falta de visualización
asociada con la programación tradicional de secuencias de construcción. Las herramientas de software BIM en el campo de la construcción/
ingeniería/infraestructura ahorran cantidades significativas de tiempo y dinero en los proyectos que las utilizan. Este enfoque puede reducir
sustancialmente tanto los costos como el cronograma, lo que reduce las reclamaciones de construcción. Las principales empresas y gobiernos
de todo el mundo están comenzando a exigir el uso de BIM en grandes proyectos.
27
2.3 HERRAMIENTA DE PROGRAMACIÓN
Una herramienta de programación suele ser una aplicación de software que contiene algoritmos, componentes, características y reglas para ingresar y
manipular actividades, dependencias, recursos y sus asignaciones para crear instancias de modelos de programación y presentaciones de programación. Los
componentes de programación se visualizan fácilmente ejecutando una aplicación de software de programación y observando la funcionalidad en la herramienta
de programación que está disponible para construir el modelo de programación.
La herramienta de programación es la plataforma sobre la cual se ensambla el modelo de programación. Esta plataforma proporciona los medios para
ajustar varios parámetros y componentes del cronograma dentro del modelo y analizar tendencias y desempeño. Por ejemplo, la herramienta de programación
para un enfoque de CPM incluye la capacidad de lograr lo siguiente:
u Seleccionar el tipo de relación (como fin a comienzo o fin a fin) entre actividades;
u Agregue retrasos y adelantos entre actividades;
u Agregar información complementaria a las actividades que ayude en el análisis, la presentación de informes y la agrupación;
u Aplicar recursos a las actividades y usar la información de recursos junto con la disponibilidad de recursos para ajustar la programación de actividades;
u Asignar prioridades a las actividades que utilizan los mismos recursos durante el mismo período;
u Agregar restricciones a las actividades donde la lógica (p. ej., relaciones de precedencia con otras actividades) por sí sola no es adecuada para cumplir
con los requisitos del proyecto, especialmente cuando se consideran factores de programación externos y disponibilidad de recursos;
u Capturar una instancia específica del modelo de cronograma como línea de base;
u Registrar el progreso real de las actividades programadas;
u Realizar varios escenarios de análisis hipotéticos dentro del modelo de cronograma para obtener diferentes fechas de finalización del proyecto;
u Analizar el impacto que los posibles cambios en el modelo de cronograma tendrían en los objetivos del proyecto;
u Compare la instancia de modelo de programación más reciente con una instancia de modelo de programación anterior o con la
instancia de referencia aprobada para identificar y cuantificar variaciones y tendencias; y
u Verificar la validez del modelo de horario resultante.
28 Sección 2
2.4 MODELO DE HORARIO
La introducción de datos específicos del proyecto (p. ej., paquetes de trabajo, actividades, duraciones, recursos, relaciones, dependencias y restricciones) en la
herramienta de programación crea un modelo de programación para el proyecto dado que es independiente del enfoque y sus requisitos.
El modelo de cronograma es una herramienta de gestión que contiene información relacionada con el plan de ejecución del proyecto. El modelo de cronograma
simula distintos escenarios y situaciones que predicen hitos y fechas de finalización de acuerdo con la entrada de datos reales y futuros del proyecto por parte del
equipo del proyecto. Es una herramienta importante utilizada para la comunicación y la gestión de las expectativas de las partes interesadas. El modelo de
programación está guiado por un plan de gestión de programación que identifica (a) el enfoque de programación utilizado; (b) la herramienta de programación
utilizada; y (c) cómo deben abordarse las actividades, las fechas previstas, la duración, los recursos, las dependencias y las limitaciones.
La creación del modelo de cronograma incorpora secuencias, duraciones, requisitos de recursos y restricciones de cronograma para la ejecución del proyecto,
además de la supervisión y el control. Como resultado, genera un modelo de cronograma con fechas planificadas para completar las actividades del proyecto.
La creación del modelo de cronograma da como resultado un modelo de cronograma aprobado utilizado por los procesos en los Grupos de Procesos de
Planificación y Monitoreo y Control (consulte la Sección 6 en la Guía del PMBOK®), que reacciona de manera lógica y predecible al progreso y los cambios del
proyecto.
El análisis del modelo de cronograma compara los cambios en el modelo de cronograma con la línea de base en función de las actualizaciones de progreso,
costo y alcance con las expectativas del equipo del proyecto sobre el impacto de estos cambios. Los cambios en el alcance, a través de cambios formales o evolución,
deben incluirse simultáneamente en la WBS y el modelo de cronograma.
El equipo del proyecto utiliza el modelo de programación para predecir las fechas de finalización del proyecto en forma de instancias del modelo de programación.
El modelo de cronograma proporciona pronósticos basados en el tiempo y responde dinámicamente a las entradas y los ajustes realizados a lo largo del ciclo de vida
del proyecto.
En la creación del modelo de cronograma, los hitos y las actividades definidas, que se basan en la EDT del proyecto y el diccionario de la EDT, deben identificarse
y describirse de manera única. Los nombres de las actividades deben (a) comenzar con un verbo, (b) incluir al menos un objeto específico único y (c) incluir adjetivos
aclaratorios cuando sea necesario. Las actividades se secuencian con las relaciones lógicas apropiadas. Se debe considerar la cantidad, el nivel de habilidad y las
capacidades de los recursos necesarios para completar cada actividad. Además, se recomienda consultar con quienes realizan la actividad para conocer su opinión
sobre la duración de cada actividad. Finalmente, si los datos históricos están disponibles, deben ser considerados para determinar la duración. Las restricciones,
incluidos los factores de tiempo de adelanto/retraso, no deben usarse en el modelo de cronograma para reemplazar la lógica del cronograma. La creación del modelo
de cronograma proporciona una línea de base para permitir la comparación del progreso con el plan aprobado.
29
2.5 MODELO DE LISTA DE INSTANCIAS Y PRESENTACIONES
Una instancia de modelo de cronograma se usa para producir presentaciones para informar sobre elementos, como rutas críticas, perfiles de utilización
de recursos, listas de actividades, listas de asignación de actividades, registros de logros, datos del sistema de gestión de valor ganado, presupuestos con
fases temporales y costos con fases temporales. . Estos resultados de datos específicos del proyecto respaldan el análisis por parte del equipo del proyecto,
incluidas las partes interesadas (consulte la Figura 2-17).
Cronograma del proyecto

Presentación
(Reportar un)
Modelo de horario
(Actual)
Modelo de horario
(Actual) Cronograma del proyecto
Modelo de horario
Presentación
(Actual)
(Informe B)
Instancias
Cronograma del proyecto

Presentación
(Informe C)
Figura 2-17. Programar instancias de modelos y presentaciones
Una presentación, en su forma más simple, es una tabla de actividades con las fechas programadas asociadas. Las presentaciones comunican a las
partes interesadas cuándo se espera que sucedan las actividades y los eventos del proyecto. Las presentaciones de recursos también pueden identificar el
recurso, ya sea por una persona específica, rol o sistema/herramienta que se requiere para completar las actividades.
El término cronograma se usa a menudo para referirse tanto al modelo de cronograma como al resultado de las actividades con fechas asociadas. Para
mayor claridad y consistencia con el PMBOK ® Guía, este estándar de práctica define (a) los datos específicos del proyecto dentro
de la herramienta de programación como un modelo de programación y (b) los resultados resultantes, basados en los datos específicos del proyecto, como
presentaciones de modelo de programación (consulte las Figuras 2-7 y 2). -8).
30 Sección 2
Las presentaciones del modelo de cronograma se pueden representar de muchas maneras, incluidas, entre otras, las siguientes:
u Listas simples,
u Gráficos de barras con fechas,
u Diagramas lógicos de red con fechas,
u Patrones de uso de recursos,
tu costos,
tu hitos,
u Horarios maestros,
u Listas de trabajo departamentales,
u Listas de trabajo en equipo,
u Fechas de vencimiento de los entregables,
u Gráficos de dependencia de tareas,
u Grabar gráficos, y
u Kanban.
Hay muchas otras posibles presentaciones de horarios. Estos varían significativamente según el enfoque del cronograma, la herramienta utilizada y los
requisitos de comunicación de las partes interesadas. Las presentaciones del modelo de cronograma pueden tomar la forma de un cronograma de inicio
temprano, un cronograma de inicio tardío, un cronograma de referencia, un cronograma de recursos limitados o un cronograma objetivo. Otros tipos de
presentaciones son derivados de estos cinco tipos básicos de programación. Dichos derivados incluyen calendarios maestros, calendarios de hitos y
calendarios resumidos. El uso de estos términos puede variar de un proyecto a otro y de una organización a otra. Para enfoques ágiles, consulte la Sección
2.6.
2.6 ÁGIL
Ágil es un término general para muchos enfoques adaptativos. Agile es una mentalidad definida por valores, guiada por principios y manifestada a
través de muchas prácticas diferentes. Hay más planificación en los enfoques ágiles que en los tradicionales, pero la planificación se distribuye de manera
diferente a lo largo del ciclo de vida del proyecto. Siempre hay una cantidad responsable de planificación por adelantado que se debe hacer. Se debe tener
cuidado cuando hay poca planificación por adelantado porque el riesgo de supervisión y retrasos debido a la repetición del trabajo es alto. Si hay demasiada
planificación por adelantado, aumenta el riesgo de crear un plan muy detallado e inexacto. El enfoque óptimo es hacer suficiente planificación por
adelantado para minimizar el riesgo de duplicación y reelaboración.
31
Agile se enfoca en ciclos de construcción más cortos y resultados tangibles a intervalos frecuentes e incrementales. Se centra
en la realización de beneficios provisionales en lugar de la finalización de las actividades. Un elemento importante de un enfoque
ágil incluye tener múltiples iteraciones en lugar de pasar de una fase a otra.
Scrum y Kanban son dos términos que a menudo se usan indistintamente, pero existen diferencias significativas entre estos
dos marcos ágiles. Scrum se usa con más frecuencia y se usa para organizar el trabajo en piezas pequeñas y manejables
expresadas como historias. Las historias brindan valor desde la perspectiva del usuario final y las completa un equipo multifuncional
dentro de un período de tiempo prescrito llamado sprint o iteración. Estas iteraciones generalmente duran de 1 a 4 semanas y
están establecidas por la metodología de gestión de proyectos de la organización o determinadas por el equipo. El equipo del
proyecto mantiene que la duración de la iteración es a lo largo de la vida del proyecto para establecer una cadencia.
Al igual que Scrum, Kanban fomenta que el trabajo se divida en partes manejables. Donde Scrum limita la cantidad de tiempo
permitido para realizar una cantidad particular de trabajo, Kanban limita la cantidad de trabajo permitido en cualquier condición
(solo pueden estar en curso tantas tareas y solo tantas tareas pueden estar en la lista de tareas pendientes). Tanto Scrum como
Kanban permiten que los requisitos grandes y complejos se dividan en características para completarse de manera eficiente.
Puntos de historia
ID de característica Prioridad comienzo Finalizar Duración Estado
(Esfuerzo)
Iteración 1 10 3 de febrero 28 de febrero 20
A 2 3 de febrero 21 de febrero 15 Hecho
B 2 10 de febrero 28 de febrero 15 Hecho
C 6 3 de febrero 28 de febrero 20 Hecho
Iteración 2 14 2 de marzo 27 de marzo 20
D 5 6 de marzo 27 de marzo dieciséis Hecho
mi 6 2 de marzo 27 de marzo 20 Hecho
F 3 16 de marzo 27 de marzo 10 Hecho
Iteración 3 8 30 de marzo 24-abr 20
GRAMO
3 30 de marzo 24-abr 10 En progreso
H 5 7-abr 24-abr 5 En progreso
Iteración 4 0 27 de febrero 22 de mayo 20
yo
0 0 No empezado
Reserva 30 0
j Alto 17 0 Reserva
k Bajo 4 0 Reserva
L Bajo 7 0 Reserva
METRO Medio 2 0 Reserva
Figura 2-18. Ejemplo de Múltiples Iteraciones o Sprints
32 Sección 2
En la Figura 2-18, las iteraciones 1 y 2 están completas (terminadas), la iteración 3 está en progreso y la iteración 4 está en desarrollo (no
iniciada). Todos los elementos del trabajo pendiente priorizado necesarios para completar la iteración no se han agregado a una iteración.
Los elementos que todavía están en el backlog priorizado nunca tendrán una estimación de duración.
Del backlog del producto, según la prioridad, el equipo selecciona los elementos que cree que se pueden completar en la iteración. Como
parte de la planificación de la iteración, el equipo crea una acumulación de iteraciones que consta de funciones y tareas. Una vez que el
equipo se compromete con una acumulación de iteraciones, comienza el trabajo de iteración. Estos componentes se reflejan en la Figura 2-19.
Durante la iteración, el equipo se comunica diariamente entre sí en forma de una reunión de 15 minutos conocida como reunión diaria de pie.
A lo largo de los ciclos de iteración, el equipo mantiene una presentación del modelo de cronograma en forma de tablero de información que
comunica visualmente el progreso del cronograma hacia los objetivos de la iteración. Al final de la iteración, el equipo demuestra el trabajo
que ha realizado a las partes interesadas y recopila comentarios que afectan en qué trabajarán en iteraciones futuras. El equipo también lleva
a cabo una reunión retrospectiva para determinar qué mejorar para futuras iteraciones. Este proceso se representa en la Figura 2-19.
Planificación de proyectos Iteración Iteración Iteración Iteración

Reunión Planificación (1-4 Semanas) Revisar Retrospectivo
Establecer Revisar
Manifestación
Liberar Producto
Características
Metas Reserva
Estimar discutir qué

Iteración Es y
Carga de trabajo no esta hecho
Diariamente
Ponerse de pie
Producto
Reserva
Iteración Potencialmente
Envío
Reserva
Producto
Figura 2-19. Ciclo de vida adaptativo típico
33
Scrum Sprint 1 3 problemas (cantidad total de tareas para cada Sprint): •••
14/feb/18 21:16 • 28/feb/18 21:16 (Tiempo de iteración) Páginas vinculadas
Crear documentación de cocina KPT-1
Crear archivos CAD KPT-2
Crear narrativa para documentación de cocina KPT-3
Scrum Sprint 2 2 problemas •••
28/feb/18 21:16 • 14/mar/18 21:16 Páginas vinculadas
Crear especificaciones KPT-4
Verificar Materiales y Productos KPT-5
Tareas pendientes 5 Crear Sprint
Crear dibujos de taller KPT-6
Obtener números de pieza para materiales/productos KPT-7
Crear plan de prueba de verificación de diseño KPT-8
Preparar datos de construcción KPT-9
Crear BOM (Lista de materiales) KPT-10
Figura 2-20. Resultados de la reunión de planificación de Sprint (iteración)
Se lleva a cabo una reunión el primer día de cada iteración. Todo el equipo se reúne para acordar el conjunto de funciones que pueden completar dentro
de la iteración y determinar las tareas asociadas para el conjunto de funciones acordado. El equipo revisa las estimaciones de trabajo para ver si tienen
tiempo suficiente para completar todas las funciones solicitadas en la iteración. Si es así, el equipo se compromete con la iteración (consulte la Figura 2-20).
De lo contrario, las funciones de menor prioridad vuelven a la cartera de productos hasta que la carga de trabajo de la iteración sea lo suficientemente
pequeña como para obtener el compromiso del equipo. Una vez que se lleva a cabo la planificación de la iteración y el equipo se compromete con el trabajo
planificado, el equipo comienza a realizar un seguimiento de su progreso mediante paneles de información visibles. Estos tableros incluyen el gráfico de
quemado, el gráfico de quemado y el tablero de tareas. Las categorías más comunes utilizadas son por hacer, en progreso y terminado.
34 Sección 2
Tablero de Scrum
Scrum Carrera 1 9 días restantes Sprint completo •••
Filtros rápidos Cesionario Scrum Carrera 1
QUE HACER EN PROGRESO HECHO
Crear archivos CAD Crear documentación de cocina
KPT-2 KPT-1
Crear narrativa para documentación de cocina

KPT-3
Figura 2-21. Scrum Board Mostrando Sprint (Iteración) 1
Si bien son similares, existen diferencias entre un tablero scrum y un tablero kanban:
u En un tablero de scrum, las etiquetas de las columnas reflejan períodos en el flujo de trabajo que comienzan con el trabajo
pendiente del sprint y terminan con lo que cumpla con la definición de hecho del equipo. Todas las historias agregadas al tablero
al comienzo de cada iteración aparecen en la última columna al final de esa iteración. Después de la iteración, el equipo limpia
el tablero y se prepara para la próxima iteración. El trabajo progresa de izquierda a derecha hasta que todo el trabajo en el sprint
está en la columna Listo Ver Figura 2-21.
u En un tablero kanban, las etiquetas de las columnas también muestran las etapas del flujo de trabajo, pero con una diferencia: se
identifica la cantidad máxima de historias permitidas en cada columna en cualquier momento. Esto hace cumplir las limitaciones
determinadas por el equipo que Kanban prescribe para cada condición. Dado que cada columna tiene un número limitado de
historias permitidas y no se requieren iteraciones, no hay razón para restablecer el tablero kanban a medida que avanza el
trabajo. Continuará fluyendo mientras el proyecto continúe, con nuevas historias que se agregarán a medida que surja la
necesidad, y las historias completas se reevaluarán si es necesario. Consulte la Figura 2-22.
35
Tablero Kanban
Filtros rápidos Cesionario Liberar •••
CARTERA 9 PARA HACER 0 EN CURSO 1 HECHO 0
Crear archivos CAD Crear documentación de cocina
••• KPT-2 KPT-1
Crear narrativa para documentación de cocina
••• KPT-3
Crear especificaciones
••• KPT-4
Verificar Materiales y Productos
••• KPT-5
Crear dibujos de taller
••• KPT-6
Obtener números de pieza para materiales/productos
••• KPT-7
Crear plan de prueba de verificación de diseño
••• KPT-8
Preparar datos de construcción
••• KPT-9
Crear BOM (Lista de materiales)
••• KPT-10
Figura 2-22. Tablero Kanban
Las dependencias son otro tema importante en un enfoque ágil. Agile intenta evitar dependencias entre requisitos, pero esto ocurre
en la práctica. Las dependencias ocurren entre los requisitos por varias razones, tales como:
u Dependencias impulsadas por el usuario final (que ocurren naturalmente en el dominio comercial como resultado de las actividades del usuario final),
u Dependencias de descomposición de requisitos (cuando los requisitos grandes se descomponen en otros más pequeños, hay
dependencias desde el requisito grande original hasta los subrequisitos más pequeños), o
u Dependencias impulsadas por la tecnología (algunos equipos optan por identificar los requisitos para una plataforma, subsistema o
o capa arquitectónica).
36 Sección 2
La figura 2-23 muestra una situación simple donde hay un proyecto ágil organizado en cinco equipos (A a E). los
las flechas entre los requisitos representan dependencias funcionales. En este ejemplo:
u El requisito 2 del backlog del equipo A depende del requisito 4.
u El requisito 4 depende del requisito 3 del equipo B, que a su vez depende del requisito 5 del equipo C,
que depende del requisito del equipo D 2.
u El requisito 2 del equipo D depende del requisito 2 del equipo E, que depende del requisito 4 del equipo D,
que depende del requisito del equipo C 7.
También podría haber dependencias entre otros requisitos.
equipo A equipo B Equipo C equipo D Equipo E
Requisito 1 Requisito 1 Requisito 1 Requisito 1 Requisito 1
Figura 2-23. Ejemplo de Dependencias Funcionales entre Requerimientos
Las dependencias se pueden abordar utilizando estrategias como volver a priorizar uno o ambos requisitos, usar una
maqueta para representar la funcionalidad que falta hasta que esté disponible y volver a trabajar los requisitos para eliminar
la dependencia.
37
2.6.1 SEGUIMIENTO Y PRESENTACIÓN
Los gráficos Burndown son los mecanismos de seguimiento ágiles más comunes que utiliza el equipo. Su aplicación y uso varía según los
proyectos ágiles, pero el factor clave es realizar un seguimiento del trabajo restante a lo largo del tiempo. Graficar el trabajo pendiente
utilizando el trabajo restante es la forma más efectiva y eficiente de usar gráficos de trabajo pendiente. El primer paso es tener una estructura
de desglose del trabajo para impulsar el trabajo pendiente, una entrada clave para la planificación de la iteración. Esto generalmente se hace
durante la reunión de planificación de la iteración. Cada historia debe tener una unidad de medida asociada, que el equipo decide durante la
reunión de planificación. Una vez que se establece el desglose del trabajo, se traza el gráfico de trabajo pendiente planificado. El esfuerzo
planificado refleja el progreso asumiendo que todas las tareas se completarán dentro de la iteración a un ritmo uniforme. Por ejemplo, si la
duración de la iteración es de 2 semanas, el esfuerzo total de la iteración es de 420 puntos de historia. En el día 1 de la iteración, una vez que
se establece el desglose de tareas, se traza el trabajo pendiente planificado como se muestra en la Figura 2-24.
Gráfico de evolución de la iteración

450
400
350
300
250 Planificado
Esfuerzo
200
150
100
50
0
0 1 2 3 4 5 6 7 8 9
Días de iteración
Figura 2-24. Gráfico de evolución típico con trabajo planificado
38 Sección 2
El eje Y de la figura 2-24 muestra el total de puntos de la historia en la iteración (420), que debe completarse al final de la iteración. Se
traza el esfuerzo planificado, lo que supone que todo el trabajo se completará al final de la iteración. Cada miembro elige trabajo para
completar del desglose de trabajo. Al final del día, el equipo actualiza el desglose del trabajo con el trabajo restante.
A medida que se avanza durante la iteración, la Figura 2-25 representa el avance con el trabajo restante.

450
400
350
300 Planificado
Esfuerzo
250
Restante
200 Esfuerzo
150
100
50
0
0 1 2 3 4 5 6 7 8 9
Días de iteración
Figura 2-25. Gráfico Burndown con trabajo restante
En la Figura 2-25, cuando el esfuerzo restante está por encima de la línea del esfuerzo planificado, significa que el equipo avanza a un
ritmo más lento y es posible que no pueda completar todos los compromisos. Se espera que la línea de esfuerzo restante esté por encima
de la línea de esfuerzo planificada al comienzo del proyecto o iteración a medida que el equipo aprende a trabajar en conjunto e interactuar
con las partes interesadas.
La Figura 2-26 muestra un gráfico de evolución en el que se cumplen los compromisos de iteración y el progreso ha sido fluido
sobre la iteración.
39

450
400
350
300 Planificado
Esfuerzo
250
Restante
200 Esfuerzo
150
100
50
0
0 1 2 3 4 5 6 7 8 9
Días de iteración
Figura 2-26. Gráfico de avance con iteración suavizada de progreso
En la Figura 2-27, no se cumplieron los compromisos de iteración. Aproximadamente 100 puntos de trabajo de la historia no
se completaron en la iteración. El trabajo restante se convierte en parte de la cartera de productos y se traslada a iteraciones
posteriores.

450
400
350
300 Planificado
Esfuerzo
250
Restante
200 Esfuerzo
150
100
50
0
0 1 2 3 4 5 6 7 8 9
Días de iteración
Figura 2-27. Gráfico de trabajo pendiente: compromiso no cumplido
40 Sección 2
En la Figura 2-28 se muestra otro ejemplo del gráfico de trabajo pendiente. En este ejemplo, el equipo trabajó a un ritmo lento.
en los primeros días de la iteración y empujado hacia el final de la iteración para cumplir con el compromiso.

450
400
350
300 Planificado
Esfuerzo
250
Restante
200 Esfuerzo
150
100
50
0 1 2 3 4 5 6 7 8 9
Días de iteración
Figura 2-28. Gráfico Burndown con trabajo restante
En la Figura 2-29, aunque al final se cumple el compromiso, el desempeño del equipo no fue consistente. Este podría ser el
caso de alcanzar metas semanales extendiéndolas hacia el final de cada semana.

450
400
350
300 Planificado
Esfuerzo
250
Restante
200 Esfuerzo
150
100
50
0 1 2 3 4 5 6 7 8 9
Días de iteración
Figura 2-29. Gráfico de evolución con compromisos cumplidos
41
Burndown se puede trazar en el nivel de iteración o el nivel de lanzamiento. Si bien los trabajos pendientes de iteración generalmente se rastrean
utilizando el esfuerzo restante, es una práctica común usar puntos de historia para rastrear el trabajo pendiente de la versión. Un punto de la historia es
una medida del esfuerzo requerido para implementar una historia.
Como se muestra en la Figura 2-30, los mismos datos se pueden representar en un gráfico diferente llamado gráfico de quemado. Los gráficos de
avance muestran los puntos de la historia completados en lugar del trabajo restante como en un gráfico de avance. Los puntos de la historia solo se
consideran completos cuando se completan las historias o las funciones. Algunos equipos intentan medir los puntos de la historia sin completar la
función o la historia real. Cuando los equipos miden solo los puntos de la historia, miden la capacidad, no el trabajo terminado, lo que viola un principio
ágil de que "la medida principal del progreso es un producto en funcionamiento". Cada equipo tiene su propia capacidad. Cuando un equipo usa puntos
de historia, tenga en cuenta que la cantidad de puntos de historia que un equipo completa en un tiempo determinado es exclusiva de ese equipo.
Puntos de historia hechos

35
30
25
LEYENDA
20
Historia
Puntos
15 Hecho
10
0
Día Día Día Día Día Día Día Día Día Día
1 2 3 4 5 6 7 8 9 10
Figura 2-30. Ejemplo de un gráfico de quemado
El progreso de la iteración se rastrea mediante el gráfico de trabajo pendiente, el panel de tareas y la reunión de trabajo diaria. En combinación,
estas tres herramientas brindan una imagen clara de en qué se está trabajando, qué se completa, qué se debe hacer, si se completará a tiempo o no, y
qué puede estar impidiendo que el equipo cumpla con su sprint y/o o soltar el gol.
Independientemente de si el equipo utiliza gráficos de trabajo pendiente o de trabajo pendiente, el equipo puede ver el trabajo completado a medida que
avanza la iteración. Al final de la iteración, el equipo puede basar la siguiente medida de capacidad (cuántas historias o puntos de historia) en lo que se
completó en esta iteración. Eso le permite al equipo estimar lo que es más probable que entregue
42 Sección 2
en la próxima iteración. La velocidad, la suma de los tamaños de puntos de la historia para la característica realmente completada en esta
iteración, permite al equipo planificar su próxima capacidad con mayor precisión al observar su rendimiento histórico.
La planificación de versiones es una forma de planificar a largo plazo que consta de varias iteraciones. Esto a menudo se realiza cada 3 a 6
meses, y el resultado no necesita ser un lanzamiento para el cliente, pero puede ser un lanzamiento interno para confirmar la integración y
validación del sistema. El equipo no asigna estas características; en cambio, el equipo proporciona estimaciones de nivel bruto para determinar
qué funciones se pueden realizar en qué iteración y cuántas de estas funciones se pueden completar. La planificación de la versión puede
basarse en funciones, en tiempo o en costes. La figura 2-32 muestra la relación entre la visión del producto, la planificación de lanzamientos y
la planificación de iteraciones.
Unidades de visión del producto
hoja de ruta del producto Lanzamiento 1 Lanzamiento 2 Lanzamiento 3
hoja de ruta del producto
impulsa los planes de lanzamiento
Plan de lanzamiento
plan de lanzamiento
establece las
iteración 0 Iteración 1 Iteración 2 Iteración 3 Iteración n
iteraciones
Plan de iteración
Planes de iteración
función de horarios
desarrollo Característica A Característica A Característica B Característica C Destacados
(Historia de usuario 1) (Historia de usuario 2) (Historia de usuario 3) (Historia de usuario 4) (Historia de usuario 5)
Funciones prioritarias
entregado por el usuario
historias (estimado Tarea A 5 horas

en puntos de la historia)
Tarea B 8 horas
Tareas (estimadas en
Tarea C 4 horas
horas) creado para
entregar historias de usuario
Tarea D 12 horas
Figura 2-31. Relaciones entre la visión del producto, la planificación de la versión y la planificación de la iteración
Agile se basa en gráficos de trabajo pendiente/quemado, tableros de tareas, trabajos pendientes, planes de iteración, planes de lanzamiento,
hojas de ruta y otras métricas para comunicar formalmente el progreso, el estado y las previsiones. Todas las demás formas de documentación
se dejan en manos del equipo para decidir. La regla general ágil es que si los documentos agregan valor y el cliente está dispuesto a pagar por
ello, entonces se debe crear el artefacto. Es posible que todavía sea necesario crear los documentos necesarios para cuestiones de gobernanza
(auditorías, contabilidad y otros).
43
RESUMEN DE BUENAS PRÁCTICAS DEL MODELO DE CRONOGRAMA
Esta sección proporciona orientación e información sobre las buenas prácticas generalmente aceptadas asociadas con los procesos de planificación,
desarrollo, mantenimiento, comunicación y presentación de informes de un enfoque de modelo de cronograma de CPM efectivo.
Esta sección cubre lo siguiente:
3.1 Gestión de horarios
3.2 Creación del modelo de cronograma
3.3 Programar el mantenimiento del modelo
3.4 Análisis del modelo de cronograma
3.5 Comunicación e informes
Esta sección proporciona requisitos comunes, terminología y funcionalidad asociada. Esta sección vincula la discusión de los procesos de
programación descritos en la Sección 2 a los componentes de programación definidos en la Sección 4.
Esta sección proporciona una descripción general, con ejemplos, de cómo crear y mantener un modelo de programación eficaz.
3.1 GESTIÓN DE HORARIOS
La gestión del cronograma abarca los esfuerzos relacionados con la programación del equipo del proyecto como parte del proceso Desarrollar el
plan de gestión del proyecto. La gestión del cronograma garantiza que todos los grupos de procesos de gestión de proyectos y las áreas de conocimiento
aplicables se integren correctamente en el modelo de cronograma general. El plan de gestión del cronograma guía el desarrollo del modelo de
cronograma.
Un modelo de cronograma requiere planificación y diseño de la misma manera que se planifica y diseña cada entregable del proyecto. El equipo del
proyecto debe considerar una variedad de factores para crear un modelo de cronograma que pueda ser una herramienta útil para el proyecto. El equipo
del proyecto utiliza el modelo de cronograma para monitorear el desempeño del proyecto, comunicar información sobre el trabajo y comparar el trabajo
planificado con el progreso real. Estos conceptos se desarrollan en apoyo del Desarrollo del Plan de Gestión del Proyecto de acuerdo con la Guía del
PMBOK®.
45
La gestión de horarios aborda lo siguiente:
u Requisitos de capacitación para los miembros del equipo del proyecto, que deben incluir el establecimiento de un entendimiento común de las políticas
de programación, los procedimientos y las tecnologías de software. Por ejemplo, los requisitos deben abordar los informes de progreso, capturando
los riesgos del proyecto y reflejando las actividades de mitigación en el modelo de cronograma;
u Procesos y procedimientos para la gestión de datos del modelo de cronograma, como formato de datos, control de versiones,
accesibilidad, almacenamiento y recuperación de datos, recuperación ante desastres y continuidad del negocio;
u Políticas relacionadas con la metodología que se utilizará en el desarrollo y mantenimiento del modelo de cronograma,
como:
n Umbrales de desempeño aplicables típicamente definidos por indicadores clave de desempeño (KPI),
n Contenido y frecuencia de presentaciones e informes,
n Gestión del valor ganado (EVM) e implementación e integración del cronograma ganado,
n Compatibilidad con otros planes subsidiarios relacionados con el proyecto,
n Coherencia con el ciclo de vida aplicable y la estructura de desglose del trabajo resultante (WBS),
n Seguimiento de riesgos,
n Granularidad de la actividad,
n Consideraciones de obligaciones contractuales,
n Consideración de los requisitos o limitaciones de recursos, y
n Posibles responsabilidades contractuales (reclamaciones, mediaciones, arbitrajes, litigios, etc.).
u Se deben considerar procesos y procedimientos para las siguientes áreas:
n Planificación, actualización y mantenimiento del modelo de cronograma durante el ciclo de vida del proyecto;
n Determinar un ciclo apropiado para obtener el estado del proyecto;
n Actualización del modelo de cronograma; y
n Publicar los resultados a todos los interesados en el proyecto de acuerdo con el plan de gestión de la comunicación.
3.1.1 PLAN DE GESTIÓN DE DATOS DEL PROGRAMA
El enfoque inicial para desarrollar un buen modelo de cronograma está en los aspectos de diseño del modelo para el proyecto específico.
Cada proyecto es único y el modelo de cronograma varía de un proyecto a otro. El equipo del proyecto debe definir algunas entradas del modelo de
cronograma básico y los resultados esperados para garantizar que se implemente la infraestructura mínima necesaria para respaldar los requisitos de las
partes interesadas, las copias de seguridad y las restauraciones, la recuperación ante desastres y la continuidad del negocio. El alcance del proyecto, la
estructura de desglose del trabajo (WBS), las definiciones de recursos (cuando sea necesario) y otros componentes del cronograma
46 Seccion 3
ya debería haberse definido para que el equipo no tenga que definir estos elementos mientras desarrolla el plan de gestión de datos del cronograma. Sin
embargo, si estos elementos del proyecto no se han definido o desarrollado en este momento, el equipo del proyecto debe centrarse en estas áreas antes de
considerar el plan de gestión de datos del cronograma.
Como mínimo, el equipo del proyecto debe considerar lo siguiente al desarrollar el plan de gestión de datos del cronograma:
u Definir la lista de usuarios de horarios, derechos de acceso y responsabilidades que tendrá cada usuario. Por ejemplo, algunos usuarios brindan el
progreso, mientras que otros tienen mayor acceso a la programación y son responsables de las funciones administrativas. Otros pueden ser usuarios
de solo lectura que no pueden agregar ni modificar datos, pero pueden revisarlos y generar informes.
u Determine la frecuencia (es decir, diaria, semanal o mensual) para la copia de seguridad de los datos del programa. Las copias de seguridad son una
parte importante de la gestión de configuración de datos de programación. Las frecuencias requeridas para las copias de seguridad a menudo se
establecen según las expectativas de las partes interesadas. Esto es fundamental para el concepto de continuidad del negocio, ya que establece
períodos de recuperación válidos en caso de que ocurra una falla catastrófica de datos. Determina qué tan precisos serán los datos recuperados en
un período determinado.
u Determine cómo se recuperarán las instancias anteriores del cronograma, por quién, a qué intervalos, y verifique que los procedimientos para la
recuperación de datos sean precisos. Un error común que se comete es que se realizan copias de seguridad, pero no existe un procedimiento de
recuperación. Esto se convierte en parte del plan de continuidad del negocio.
u Determinar los requisitos de retención de datos para los datos del modelo de cronograma. Para algunos proyectos, los requisitos legales o locales
determinan cómo se deben almacenar los datos del proyecto y durante cuánto tiempo. Debe ser de fácil acceso en cualquier momento para fines de
auditoría.
u Identificar los riesgos asociados con el desarrollo del modelo de cronograma relacionados con la gestión de datos del cronograma.
Para proyectos donde los usuarios están distribuidos globalmente, los privilegios de los usuarios para acceder a los datos en diferentes zonas
horarias podrían generar un conflicto entre la disponibilidad de la infraestructura y la capacidad de aplicar actividades de mantenimiento de la
infraestructura (es decir, parches y actualizaciones). La copia de seguridad, la replicación de datos y la alta disponibilidad como contingencia en un
desastre y la infraestructura de recuperación también podrían verse afectadas.
La protección de los datos en el proyecto es clave para garantizar la disponibilidad, accesibilidad y capacidad de recuperación de los datos en caso de
de falla del equipo, destrucción intencional o no intencional de datos, o desastre de cualquier tipo.
3.1.2 PLAN DE GESTIÓN DEL HORARIO
El plan de gestión del cronograma es una colección de procesos, enfoques, plantillas y herramientas que comprenden la estrategia y los objetivos de
ejecución del proyecto, tal como se refleja en el modelo del cronograma del proyecto. El plan de gestión del cronograma es único para cada proyecto y se
compone de requisitos definidos por la organización implementadora, así como
47
los documentos de alcance del proyecto. El plan de gestión del cronograma define cómo se desarrollará, actualizará, progresará y compartirá el
modelo de cronograma. El modelo de cronograma predice cómo reaccionará el proyecto a factores específicos del proyecto, ya sean conocidos
ahora o anticipados en el futuro. Las buenas prácticas dictan que, para garantizar la calidad, todos los modelos de cronograma deben guiarse
por una metodología que proporcione una lista de verificación de requisitos para el modelo de cronograma.
Determinar los requisitos de jerarquía de datos para propósitos de informes (como se define en el plan de gestión de comunicaciones) y
cómo estos requisitos afectan el proceso de gestión de datos del cronograma y el modelo de datos. Por ejemplo, los tipos de actividades que se
muestran al comité directivo son diferentes de los que se muestran al director del proyecto.
El plan de gestión del cronograma requiere componentes que permitan el logro exitoso de un proceso de programación eficiente. Dicho plan
también permite que los miembros del equipo del proyecto se desempeñen de manera consistente. Los proyectos que no tienen un plan de
gestión del cronograma tienden a ser ineficientes, lo que resulta en costos más altos, mayor riesgo y duración más prolongada del proyecto. El
plan de gestión del cronograma incluye los elementos descritos en las Secciones 3.1.2.1 a 3.1.2.12. Se debe crear una lista maestra de los
documentos y datos requeridos para garantizar que se cubran todos los aspectos.
3.1.2.1 ENFOQUE DE PROGRAMACIÓN
El equipo del proyecto debe tener acceso a la documentación del proyecto que define los enfoques del cronograma aprobados por la
organización para cumplir con los requisitos organizacionales y del proyecto. Con base en esta información, el programador implementa el
enfoque de programación según lo determine el equipo del proyecto. Para obtener más información sobre los enfoques de programación,
consulte la Sección 2.2.
3.1.2.2 HERRAMIENTA DE PROGRAMACIÓN
La selección de la herramienta de programación se basa en el enfoque de programación seleccionado y debe cumplir con los requisitos
organizacionales y del proyecto relacionados con la herramienta. Se debe considerar detenidamente cualquier requisito que pueda imponer una
herramienta seleccionada para garantizar la compatibilidad.
3.1.2.3 PLAN DE CREACIÓN DEL MODELO DE CRONOGRAMA
El director del proyecto, junto con el equipo del proyecto y las partes interesadas clave, determina el plan para la creación del modelo de
cronograma. Esto se centra en cómo se creará el modelo de cronograma y cómo encajarán todas las partes.
Las consideraciones clave incluyen: el enfoque del cronograma y la participación de las partes interesadas en el proceso de desarrollo del
cronograma de acuerdo con la Guía del PMBOK® .
48 Seccion 3
3.1.2.4 ID DEL MODELO DE HORARIO
Cada modelo de cronograma debe tener una identificación única que sea específica para el proyecto y no cambie. Esto permite realizar un seguimiento
de los modelos de programación a lo largo del tiempo y permite el análisis y la discusión de cada modelo sin confusión.
También proporciona un excelente catálogo histórico para su análisis en una fecha posterior. La mayoría de las organizaciones establecen convenciones
de nomenclatura estándar que permiten que cada proyecto se identifique de forma única durante el ciclo de vida del proyecto.
3.1.2.5 INSTANCIA DE MODELO DE HORARIO
Cada instancia del modelo de programación tiene un identificador único. La ubicación de este identificador varía y depende de los activos del proceso
organizacional y las herramientas utilizadas para controlarlo. Un identificador de instancia de modelo de cronograma único es esencial para permitir el
archivo adecuado de los documentos del proyecto y los procesos de auditoría. El plan de gestión de la programación y/o el plan de gestión de la
configuración proporcionan el formato para este componente a fin de garantizar convenciones de nomenclatura de archivos adecuadas, que se cree y
mantenga el control de versiones y que no se produzca una nomenclatura redundante.
3.1.2.6 CALENDARIOS Y PERIODOS DE TRABAJO
Se define un calendario de proyecto predeterminado. También se pueden definir calendarios para actividades específicas o partes del proyecto.
incluyendo recursos. Algunos de los elementos del calendario que se definirán incluyen:
u Días laborables en una semana,
u Número de turnos a trabajar cada día,
u Número de horas a trabajar cada turno o día,
u Cualquier período de horas extraordinarias programadas,
u Tiempo no laborable (p. ej., feriados, cierres, fechas restringidas, horarios restringidos, etc.), y
u Zonas horarias para equipos distribuidos geográficamente. Este elemento se relaciona con la forma en que deben funcionar los proyectos
internacionales cuando los productos se desarrollan y entregan desde otros lugares. Hay un problema de tiempo que se debe planificar en el
modelo. Deben crearse calendarios internacionales especiales.
Estos elementos de calendario desempeñan un papel importante en la determinación del número y la estructura de los calendarios de proyectos
necesarios para la programación. El uso de calendarios múltiples introduce una complejidad significativa en el cálculo de la flotación y la ruta crítica. Esto
puede ser aún más complejo en un proyecto distribuido geográficamente. Sin embargo, aunque la programación se simplifica mediante el uso de un solo
calendario, un calendario puede ser inadecuado para administrar un proyecto distribuido en zonas horarias (por ejemplo, un equipo de proyecto distribuido
geográficamente con días festivos locales asociados), o donde el equipo del proyecto tiene diferentes horarios de trabajo.
49
La práctica generalmente aceptada es utilizar un calendario de proyecto predeterminado que sea adecuado y razonable para realizar el trabajo,
en función de los tiempos de trabajo normales del proyecto. Este calendario de proyecto se utiliza como calendario predeterminado para las
actividades del proyecto. Esta práctica le permite al equipo del proyecto establecer y programar diferentes períodos de trabajo o calendarios, si es
necesario, para ciertas actividades.
3.1.2.7 CICLO DE ACTUALIZACIÓN DEL PROYECTO Y GRANULARIDAD DE LA ACTIVIDAD
El ciclo de actualización es el intervalo regular en el que se informa el estado actual del proyecto. La frecuencia apropiada para realizar
actualizaciones y reportar el estado contra el cronograma se define como parte del plan de gestión del cronograma. Esto incluye determinar en qué
punto del ciclo ocurre la actualización y con qué frecuencia se informa el estado. El ciclo de actualización refleja cómo la administración pretende
utilizar los datos generados a partir del modelo de cronograma.
El momento de las reuniones de revisión, los requisitos de informes de gestión y los ciclos de pago a menudo están vinculados a las actualizaciones.
El ciclo de actualización seleccionado debe proporcionar a la gerencia un nivel óptimo de información de control sin ser demasiado oneroso para
quienes realizan el informe y el análisis. El ciclo de actualización óptimo varía según la industria y el proyecto, desde actualizaciones por hora para
proyectos de interrupciones planificadas en instalaciones de fabricación/producción, hasta actualizaciones semanales o mensuales para proyectos
importantes de construcción o desarrollo de software. El ciclo de actualización seleccionado tiene una relación directa con la duración de las
actividades contenidas en el cronograma.
Los profesionales experimentados a menudo dividen el ciclo de actualización en dos partes separadas: (a) incorporación del progreso en el
modelo y (b) mantenimiento (problemas descubiertos en el cronograma que ya no son compatibles o se ingresaron incorrectamente, etc.). Esto sirve
para reducir el tiempo de informe de progreso a un período mínimo.
La elección del ciclo de actualización está influenciada por varios factores, como la tasa de cambio en el proyecto, el impacto potencial que los
cambios pueden tener en el proyecto y la duración del proyecto. Para proyectos relativamente estables, a largo plazo y de bajo riesgo, puede ser
apropiado un ciclo de estado mensual o bimensual. Para proyectos volátiles y de alto riesgo, es posible que se requieran actualizaciones para cada
cambio de turno o cada hora. Para obtener la máxima visibilidad y exposición, la información de estado de estos proyectos se puede mostrar en
grandes salas de reuniones. También se debe tener en cuenta el tiempo de ciclo entre actualizaciones. Debería ser suficiente para que el equipo del
proyecto emita, analice y actúe sobre la información proporcionada desde la última actualización antes de la próxima actualización. El ciclo de
actualización establecido debe coordinarse con el contrato o procesos organizacionales.
El equipo del proyecto debe considerar qué escala de tiempo usar: horas, días, semanas o meses. El cronograma seleccionado depende de la
frecuencia de los procesos de control y el nivel de detalle necesario en las actividades. La mayoría de las veces, los plazos de las actividades se
mantienen constantes a lo largo del proyecto. Sin embargo, las evoluciones de proyectos específicos pueden requerir diferentes escalas de tiempo
que sean efectivas para esa evolución.
50 Seccion 3
También se debe tener en cuenta la granularidad de las actividades del proyecto. La granularidad considera cuántas actividades contiene y
mantiene el modelo de programación. Al determinar la granularidad deseada del cronograma, tenga en cuenta que demasiados detalles producen
un modelo de cronograma confuso y demasiado grande que es difícil y costoso de administrar. Sin embargo, la falta de detalles da como resultado
un flujo de información insuficiente y dificulta el control continuo del proyecto. El equipo del proyecto debe determinar el detalle óptimo, que podría
ser diferente para cada proyecto.
Los requisitos de programación de recursos también pueden afectar la granularidad de la programación. El nivel de detalle del cronograma también
afecta el plan de gestión de comunicaciones del proyecto.
3.1.2.8 ESTRUCTURA DE CODIFICACIÓN DE HITOS Y ACTIVIDADES
Comprender los tipos de informes, análisis, demandas de los interesados/clientes y planes de gestión para administrar y controlar los datos del
proyecto obtenidos del modelo de cronograma tiene un gran impacto en la estructura de codificación del proyecto.
La codificación permite la creación de presentaciones (consulte la Sección 3.5) del modelo de cronograma y brinda orientación sobre las estructuras
de codificación que están integradas en el modelo de cronograma. Debido a los avances en las herramientas y el software de análisis de proyectos,
a menudo se utilizan campos de código específicos para mostrar la ubicación única del trabajo dentro del proyecto, de modo que los modelos 4D, la
programación basada en la ubicación (LBS) y otras herramientas de informes puedan mostrar visualmente el progreso del proyecto.
Las estructuras de codificación bien diseñadas también son útiles para analizar los datos de rendimiento del proyecto mediante la agrupación,
selección y clasificación para resaltar tendencias y anomalías. La codificación brinda asistencia en el desarrollo y mantenimiento del modelo de
cronograma como se identifica en el plan de gestión de comunicaciones y ayuda a cumplir con los requisitos de informes del proyecto.
Es esencial el uso de una estructura de codificación de actividad sólida y bien concebida que esté separada del identificador de actividad.
Las actividades se pueden codificar con más de un código para cada actividad, y cada código tiene un valor separado, lo que permite personalizar
los resultados para diferentes propósitos. Por ejemplo, los códigos se pueden usar para identificar las fases y subfases del proyecto, las ubicaciones
de trabajo, los eventos del proyecto, las puertas, los logros significativos, las fuentes de suministro, las fuentes de diseño y la persona u organización
responsable de realizar la actividad. Estos códigos se pueden usar solos o en múltiples combinaciones. Para lograr flexibilidad y funcionalidad
mejorada, la mayoría del software de programación admite varios códigos para cada actividad.
Una numeración estructurada de actividades o un esquema de identidad debe formar parte del diseño de codificación general. El uso de un
sistema estructurado de identificación de actividades proporciona a los usuarios del cronograma una mejor comprensión de cómo una actividad en
particular encaja en el panorama general al comprender la importancia del identificador de actividad en sí. Por ejemplo, el esquema de identificador
puede vincularse con la EDT del proyecto. Como mínimo, un identificador de actividad debe ser único y seguir un esquema apropiado para el
proyecto.
51
3.1.2.9 PLANIFICACIÓN DE RECURSOS
El modelo de cronograma debe incluir la identificación de los recursos necesarios para llevar a cabo las actividades. Los recursos pueden ser
de cualquier tipo (por ejemplo, recursos humanos, máquinas, materiales, ubicación, etc.). El plan de gestión del cronograma identifica los
elementos necesarios para la planificación y gestión de recursos. Los elementos a considerar son la disponibilidad de recursos, los calendarios
de recursos y los conjuntos de habilidades de recursos. Comprender los recursos críticos para un proyecto y cómo su disponibilidad puede afectar
el cronograma permite una mejor gestión del proyecto en general.
La disponibilidad de recursos, los niveles de habilidad de los recursos humanos y las fechas y la cantidad de períodos de trabajo (en unidades
de calendario) en que un recurso determinado está disponible tienen un impacto importante en los proyectos. Al cargar recursos específicos en el
modelo, es fundamental identificar las necesidades específicas a lo largo del tiempo para incluir incrementos al comienzo del proyecto, períodos
de máxima demanda y disminuciones razonables al final del proyecto. Cualquiera de estos factores puede tener un impacto en el proyecto.
Estos factores también ayudan a identificar y comprender los problemas críticos y mitigar los impactos negativos en el proyecto en general.
Los informes y las curvas de carga de recursos permiten a la gerencia observar las proyecciones resultantes para determinar si el plan es factible
o si se debe ajustar la fecha de finalización. Estas curvas de recursos y los datos generados por el modelo también ayudan a comprender los
impactos que el proyecto puede experimentar debido a influencias externas (p. ej., huracanes, etc.).
Aunque no se requiere la carga de recursos del modelo de programación, es una buena práctica. El equipo del proyecto debe considerar los
recursos al determinar la duración y la secuencia de las actividades. Un cronograma nivelado y cargado de recursos indica claramente las
interdependencias y los impactos que la disponibilidad de recursos tiene en la duración y el costo del proyecto.
3.1.2.10 INDICADORES CLAVE DE RENDIMIENTO
Para que las partes interesadas sepan cómo se está desempeñando el proyecto, muchos proyectos incorporan indicadores clave de
rendimiento (KPI). Esto permite que el equipo del proyecto mida el progreso y controle el desempeño hacia los objetivos predefinidos del proyecto
(p. ej., calificaciones de desempeño, salud del cronograma, EVM y cronograma ganado). Los problemas de rendimiento y el estado del cronograma
pueden incluir el seguimiento de lo siguiente:
u Número de inicios y finales de actividad frente al número esperado de actividades en un período determinado,
u Backlog de actividades en curso,
u Porcentaje de crecimiento en la duración de las actividades,
u Número de actividades añadidas o eliminadas, y
u Cualquier otro tipo de indicador que explique y describa el desempeño del proyecto.
EVM puede combinar medidas de alcance, cronograma y costo dentro de un solo sistema integrado, que proporciona indicadores basados en
costos. La aplicación del análisis EVM en las primeras etapas de un proyecto aumenta la validez y la eficacia de la línea base de cronograma y
costo. Una vez establecida, esta línea de base sustenta la comprensión de
52 Seccion 3
desempeño del proyecto durante la ejecución del proyecto. EVM se puede ampliar para incluir el concepto de cronograma ganado, que
proporciona indicadores basados en tiempo para complementar los indicadores basados en costos para el desempeño del proyecto. Para
obtener más información sobre EVM y el cronograma ganado, consulte la Sección 3.4.12 y el Estándar para la gestión del valor ganado [5].
El plan de gestión de comunicaciones del proyecto también puede indicar áreas específicas de enfoque con indicadores que necesitan ser
monitoreados. Por lo general, estos son entregables específicos del proyecto o aspectos que la administración cree que están directamente
relacionados con el éxito o el fracaso final del proyecto.
3.1.2.11 MODELO DE PROGRAMA MAESTRO
El modelo de cronograma está diseñado y construido como un proyecto maestro que contiene subproyectos. Los subproyectos se
pueden estructurar de acuerdo con los diversos equipos responsables de subproyectos específicos del alcance del proyecto maestro más
grande que comprende el proyecto. Los ejemplos de subproyectos incluyen la ejecución por etapas (ingeniería, producción, pruebas e
integración), equipos distribuidos globalmente o la estrategia de contratación (p. ej., múltiples proyectos o múltiples gerentes de proyectos).
Estos subproyectos deben estar vinculados entre sí en ciertos puntos identificados de entrega/aceptación o interfaz para garantizar que
haya una integración entre los planes. El plan de gestión del cronograma define los pasos utilizados para crear, administrar y controlar el
cronograma maestro, los subproyectos y las interdependencias del proyecto.
3.1.2.12 CONTROL DE CAMBIOS
El cambio de proyecto es inevitable, por lo que es fundamental planificar cómo afrontar el cambio (consulte la Parte 1, Sección 4.6 de
la Guía del PMBOK®). Debido a que los proyectos son muy dinámicos y el cambio puede ocurrir con frecuencia dentro del proyecto, el
equipo del proyecto necesita planificar y gestionar el cambio. Las buenas prácticas de programación aseguran que, a medida que se
realizan revisiones o ajustes al cronograma como resultado de cambios en el proyecto, las actividades del cronograma afectadas y los
riesgos subsiguientes se identifican y marcan como asociados con un cambio específico de acuerdo con el plan de gestión de la configuración.
Esto es especialmente importante cuando el cambio genera trabajo adicional y puede afectar el cronograma o el costo del proyecto.
También es fundamental cuando se utiliza la línea de base del cronograma (que se analiza más adelante) para la evaluación comparativa.
3.2 CREACIÓN DEL MODELO DE HORARIO
Esta sección ofrece una descripción general de los elementos esenciales para desarrollar un modelo de horario sólido.
Las buenas prácticas para cada componente están contenidas en la lista de componentes en la Sección 4 de este estándar de práctica. Se
recomienda encarecidamente una revisión de la Sección 4 para comprender todos los aspectos asociados con cada componente. Es
fundamental tener en cuenta toda la información, los procedimientos y las restricciones documentadas en la sección de gestión del modelo
de cronograma.
53
Un modelo de cronograma proporciona un plan detallado útil que puede ser utilizado por el gerente del proyecto y el equipo del proyecto para ayudar
a completar el proyecto con éxito. El equipo del proyecto desarrolla el modelo de cronograma como una herramienta que está alineada con el plan de
gestión del cronograma. El modelo de cronograma captura la visión del equipo de cómo se realizará el proyecto y cómo se espera que el proyecto
reaccione a los cambios a lo largo del tiempo. El equipo del proyecto modifica el modelo de cronograma adecuadamente para reflejar los cambios (p.
ej., progreso, alcance, etc.) a lo largo del ciclo de vida del proyecto. Un modelo de cronograma bien desarrollado es una herramienta dinámica que
proporciona una predicción razonable de cuándo se espera que se complete el trabajo restante del proyecto. Permite que el equipo del proyecto observe
el desempeño del proyecto hasta la fecha y use esos datos para hacer pronósticos precisos para las evoluciones del proyecto que quedan por lograr.
Una vez que se ha completado el proyecto, el modelo de cronograma forma la base para las actividades de lecciones aprendidas que se convierten en
la base para proyectos similares en el futuro. El modelo de programación también es un componente crítico en cualquier análisis de programación
forense que pueda ser necesario en el proyecto.
El modelo de programación describe:
u Trabajo por hacer (qué),
u Recursos necesarios para hacer el trabajo (quién, qué y cuándo),
u Duración de las actividades (cuánto tiempo) en función de la disponibilidad de recursos y la productividad, y
u Secuencia de actividad óptima (cuándo) basada en relaciones lógicas entre las actividades del cronograma, la disponibilidad de recursos y los
calendarios.
La forma de hacer el trabajo (cómo) está definida por otros documentos en el plan general de gestión del proyecto. Establecer un modelo de
cronograma realista y alcanzable es una de las acciones iniciales críticas. Algunos puntos importantes a considerar durante la creación del modelo de
cronograma son:
u Asegúrese de que los requisitos del proyecto se comprendan y se cumplan. El equipo del proyecto revisa y comprende el alcance del
proyecto, lo que brinda orientación para el desarrollo de una estructura de desglose del trabajo (EDT). El alcance del proyecto proporciona los
antecedentes, la información y la comprensión necesarios para desarrollar el modelo de cronograma. El objetivo es garantizar que todos los
aspectos de la ejecución del proyecto se hayan definido e incluido adecuadamente en el modelo de cronograma. Las actividades en el modelo
de cronograma representan el trabajo que produce los entregables o paquetes de trabajo identificados en la EDT. Por lo tanto, todos los
paquetes de trabajo en la WBS deben ser rastreables directamente a una actividad del cronograma o grupo de actividades. Las actividades del
cronograma a menudo se pueden organizar para reflejar la jerarquía de la EDT. Por el contrario, cada actividad debe acumularse en un solo
elemento WBS.
u Verificar la disponibilidad de recursos y las asignaciones. El equipo del proyecto se beneficia enormemente de un cronograma cargado de
recursos. Durante el proceso de creación del modelo de programación, es importante que se verifiquen la disponibilidad de recursos y las
asignaciones. La mano de obra, el material, el equipo y la infraestructura necesarios para llevar a cabo el proyecto.
54 Seccion 3
las actividades pueden planificarse por adelantado y los problemas previstos pueden mitigarse. Un modelo de cronograma factible asume
que hay suficientes recursos disponibles para realizar las actividades según lo programado. Esto se vuelve mucho más fácil cuando el
modelo de programación está cargado de recursos, ya que las curvas de requisitos de recursos, la tasa de consumo y otros informes
centrados en los recursos están disponibles. Para obtener más información sobre los recursos, consulte la Sección 9 del PMBOK®
Guía sobre Gestión de Recursos de Proyectos. De la misma manera que los códigos de actividad se utilizan para clasificar y organizar
actividades, los códigos de recursos (atributos) se pueden asignar para clasificar los recursos según la organización, el nivel o tipo de
habilidad, la estructura de informes, etc. Además, los identificadores de recursos (ID de recursos) pueden estructurarse en un esquema
significativo, similar a los identificadores de actividad (identificadores de actividad).
3.2.1 DESARROLLAR LA LÍNEA DE BASE DEL MODELO DE CRONOGRAMA
El desarrollo de un buen modelo de horario se logra a través de la aplicación consistente de buenas prácticas.
La experiencia adquirida con el tiempo ayuda a seleccionar las respuestas adecuadas a los requisitos de diseño para el modelo de cronograma.
Los pasos clave se explican a continuación en las Secciones 3.2.1.1 a 3.2.1.9.
3.2.1.1 DEFINIR HITOS
Una vez que haya una comprensión de la estructura general de los datos del proyecto discutidos anteriormente, comience a diseñar los hitos
del proyecto. Un hito tiene duración cero, no tiene recursos asignados, se utiliza como punto de referencia para medir el progreso y también
puede reflejar los puntos de inicio y finalización de varios eventos del proyecto. Generalmente, un hito representa el inicio o la finalización de una
parte o entrega del proyecto. También puede estar asociado con restricciones externas, como la entrega de aprobaciones o entregables
específicos requeridos. Cada proyecto debe tener un hito de inicio y un hito de finalización. Consulte la Sección 3.5 para ver un ejemplo de un
hito de inicio y un hito de finalización. El proyecto contiene una lista de hitos desarrollados inicialmente cuando se crea el modelo de cronograma.
Estos pueden haberse originado en el cliente, los miembros del equipo u otras partes interesadas. A medida que se desarrolla el modelo de
cronograma, se agregan hitos adicionales según sea necesario. Es un proceso iterativo. (Tenga en cuenta que, en algunos casos, las actividades
pueden definirse antes que los hitos).
3.2.1.2 DEFINIR LAS ACTIVIDADES DEL PROYECTO
Cree la lista de actividades que deben realizarse para completar el proyecto con base en la EDT y elaborada por el equipo responsable de la
ejecución del trabajo. Estas actividades deben representar la secuencia esperada de las actividades y representar la forma en que se realizará el
trabajo. Una actividad es un elemento medible y discreto.
55
(o bloque) de trabajo que es un elemento tangible del alcance del proyecto. Las actividades son acciones específicas que se realizan para
producir los entregables del proyecto. Las características de una actividad bien definida incluyen:
u Propietario de la actividad. Es posible que se requieran múltiples recursos para realizar la actividad; sin embargo, una sola persona
es responsable y rinde cuentas por su desempeño. Esa persona también debe informar sobre el progreso de la actividad.
u Descripción de la actividad. Las actividades describen el trabajo que debe realizarse. Como tal, la descripción de cada actividad
comienza con un verbo y contiene un objeto único y específico. Aunque “verter pared” puede ser descriptivo de una tarea, la
descripción de la actividad debe ser más específica. Los adjetivos pueden ser útiles para aclarar ambigüedades.
Por ejemplo, "vierta los cimientos del muro este de x a y" o "revise la terminología de la Sección 3". Cada descripción de actividad
debe ser única y no dejar lugar a confusión; es decir, se puede identificar sin ambigüedad y debe ser independiente de la
agrupación u organización de presentación del cronograma.
u Continuidad de la actividad laboral. El trabajo representado por una actividad, una vez iniciado, debe ser capaz de continuar hasta
su finalización sin interrupción (excepto en los períodos de no trabajo que ocurren naturalmente en el calendario). Cuando el
trabajo de una actividad se suspende o retrasa, a menudo es beneficioso que la actividad se divida en dos o más actividades en
los puntos de interrupción naturales.
u Duración de la actividad. Normalmente, la duración de una actividad debe ser inferior al doble del ciclo de actualización. Esto
permite informar el inicio y el final de una actividad dentro de uno o dos ciclos de actualización, lo que permite que la administración
se centre en el desempeño y las acciones correctivas, si es necesario. Se exceptúan de esta regla general las actividades
continuas, algunas de las cuales se definen a continuación:
n Resumen de la actividad. Una actividad de resumen es una representación única de actividades agregadas por atributos
comunes dentro del modelo de cronograma y se puede crear de varias maneras:
m El primer ejemplo es cuando la actividad describe, en términos generales, el esfuerzo a realizar, y el proyecto no tiene
suficiente información para desglosarlo en mayor detalle o no desea rastrearlo a un nivel de detalle más bajo. Ejemplos de
esto son perforar un túnel de 2 millas de largo o pavimentar varias millas de carretera. Vea la primera actividad en la Figura
3-1. En este ejemplo, la actividad refleja la duración total del trabajo del túnel y nada más.
m El segundo método es cuando las actividades se acumulan automáticamente para crear un resumen de todas las actividades
similares, como se muestra en la Figura 3-1. En este ejemplo, las actividades del Grupo A y del Grupo B se resumen en
una sola barra que se muestra arriba de las actividades para reflejar lo que se muestra debajo de esa barra y se codifica
para el grupo apropiado. Tenga en cuenta que las fechas de inicio y finalización reflejan la fecha de inicio anticipada y la
fecha de finalización anticipada y no las fechas tardías; además, la duración reflejada en la barra de resumen coincide con
el tiempo transcurrido desde el inicio hasta el final de las actividades del grupo. Algunos programas de software realizan
este resumen automáticamente dentro del software. Al hacerlo, el software acumula los datos de acuerdo con reglas
específicas y los representa como una barra que se extiende durante un tiempo. Es importante entender completamente
cómo el software en particular está logrando este resumen para que no se desarrollen y presenten datos inexactos o confusos.
56 Seccion 3
m Un tercer ejemplo de una actividad de resumen es una actividad que puede llevar más de dos o tres períodos de actualización, como
una actividad de adquisición realizada por alguien fuera del proyecto y esperada en el sitio en una fecha determinada. El estado del
esfuerzo de trabajo no se puede incorporar en el cronograma más que contabilizar el tiempo hasta que ocurra el evento. Vea la
última actividad en la Figura 3-1.
Proyecto de ejemplo
Original
2019 noviembre 2019 diciembre 2019 enero 2020 febrero 2020 marzo 2020
Nombre de la actividad comienzo Finalizar
Duración
20 27 03 10 17 24 01 08 15 22 29 05 12 19 26 02 09 16 23 01 08 15 2
Resumen 75 04-nov-19 14-feb-20 14-feb-20, Resumen
Bore un dos millas de largo... 75 04-nov-19 14-feb-20 Perforó un túnel de dos millas de largo
Grupo A 36 04-nov-19 23-dic-19 23-dic-19, Grupo A
Inicio de un Proyecto 0 04-nov-19 Inicio del proyecto, 04-nov-19
Tarea A 10 05-nov-19 18-nov-19 Tarea A
Tarea C 15 03-dic-19 23-dic-19 Tarea C
Tarea B 10 19-nov-19 02-dic-19 Tarea B
Grupo B 21 04-nov-19 02-dic-19 02-dic-19, Grupo B
Tarea E 10 19-nov-19 02-dic-19 Tarea E
Tarea F 10 19-nov-19 02-dic-19 Tarea F
Tarea D 20 04-nov-19 29-nov-19 Tarea D
Obtención 50 04-nov-19 10-ene-20 10-ene-20, Adquisiciones
Fabricar y entregar... 50 04-nov-19 10-ene-20 Fabricar y entregar un componente especial
Figura 3-1. Resumen de actividades
n Actividad de nivel de esfuerzo (LOE). Se incorpora una actividad de nivel de esfuerzo (LOE) en el cronograma para
rastrear, contabilizar y distribuir los recursos durante un período de tiempo. Sin embargo, esto no logra un producto
entregable discreto y específico. Un ejemplo de esto es la contabilización de las horas del proyecto asociadas con el
apoyo administrativo. En este caso, la duración de la actividad debe reflejar el tiempo previsto para la actividad. En
general, las actividades LOE no deben aparecer en la ruta crítica del proyecto ni impulsar la fecha de finalización del
proyecto. Se debe tener cuidado con las actividades de LOE, porque cuando se les asigna una duración estática igual
a la duración de todo el proyecto, nunca deben terminar en la ruta crítica ni impulsarla. Por su propia naturaleza de
apoyar actividades de trabajo detalladas, las LOE no pueden determinar la duración del proyecto y no pueden ser
críticas; son de naturaleza solidaria. Es una buena práctica definir las actividades LOE de tal manera que tomen su
duración de las actividades detalladas que soportan. Generalmente, la duración de una LOE está determinada por sus
relaciones lógicas que determinan cuándo comienza y termina. Por lo general, se muestran como una relación de
predecesor de comienzo a comienzo (SS) y una relación de sucesor de fin a fin (FF) y ninguna otra (consulte la Figura 3-2). Al finalizar, la
57
Construcción 113d
A1050 Deberes 11d
A1060 Excavación 15d LOE

A1070 Base 16d
A1075 EQUIPO: Grúa 17d
A1080 Acero estructural 21d
A1090 Techo 11d
A1100 ventanas 19d
A1110 Sobre 25 días
Figura 3-2. Actividad LOE
La lista describe el 100 % del trabajo que debe completarse para el proyecto, aunque no es necesario detallar completamente
todas las actividades cuando se usa la planificación de ondas continuas como se describe en la Sección 2.2.4. La nivelación de
recursos no debe realizarse en actividades tipo LOE. No se deben aplicar restricciones a las actividades de la LOE. Las
actividades LOE pueden tener asignados recursos y calendarios específicos para determinar sus fechas de inicio y finalización.
n Actividad de hamacas. Una actividad hamaca es una actividad puente que usa y está confinada por las relaciones SS y FF a
actividades de apoyo. Una actividad LOE es diferente a una actividad hamaca porque las actividades LOE pueden tener muchos
tipos de relaciones asociadas con ellas. Consulte la Figura 3-3.
Proyecto de ejemplo
Original 2019 noviembre 2019 diciembre 2019 enero 2020

Nombre de la actividad comienzo Finalizar
Duración
20 27 03 10 17 24 01 08 15 22 29 05 12 19
Grupo B 21 04-nov-19 02-dic-19 02-dic-19, Grupo B
Tarea E 10 19-nov-19 02-dic-19 Tarea E
Tarea F 10 19-nov-19 02-dic-19 Tarea F
Tarea D 20 04-nov-19 29-nov-19 Tarea D
Grupo C 30 19-nov-19 30-dic-19 30-dic-19, Grupo C
Tarea J 10 17-dic-19 30-dic-19 Tarea J
Tarea G 10 19-nov-19 02-dic-19 Tarea G
Tarea H 10 02-dic-19 13-dic-19 Tarea H
Hamaca 40 05-nov-19 30-dic-19 30-dic-19, Hamaca
Actividad de hamaca 40 05-nov-19 30-dic-19 Actividad de hamaca
Figura 3-3. Actividad de hamaca
58 Seccion 3
3.2.1.3 ACTIVIDADES DE SECUENCIA
La secuenciación de actividades e hitos junto con la lógica es la base de cualquier modelo de cronograma. El método de conexión se define
como una relación. Cada actividad e hito excepto el primero (sin predecesor) y el último (sin sucesor) deben estar conectados al menos con
una actividad predecesora y una sucesora. Con la excepción del hito de inicio, una actividad anterior debe finalizar o comenzar antes de que
comience cualquier actividad y, a su vez, esa actividad debe completarse total o parcialmente para permitir que comience otra actividad.
Consulte la Figura 3-4 para ver ejemplos de estos diversos tipos de relaciones. Por lo general, cada actividad predecesora finaliza antes del
inicio de su actividad (o actividades) sucesora. Esto se conoce como una relación de fin a comienzo (FS). A veces es necesario superponer
actividades. En este caso, se puede seleccionar una opción para usar relaciones de inicio a inicio (SS), de fin a fin (FF) o de comienzo a fin
(SF). La Figura 3-4 proporciona ejemplos de los cuatro tipos de relaciones en CPM. La mayoría (o en algunos casos, todas) las relaciones en
un modelo de cronograma detallado serán relaciones FS. Las relaciones FS dan como resultado los cálculos más simples y menos complicados
para el modelo de cronograma. Cuando se usan otros tipos de relaciones, deben usarse con moderación y con una comprensión de cómo se
han implementado las relaciones en el software de programación. Idealmente, la secuencia de todas las actividades se configura de modo que
el inicio de cada actividad tenga una relación lógica con un predecesor y el final de cada actividad tenga una relación lógica con un sucesor.
Estas prácticas evitan que el cronograma esté plagado de extremos abiertos. Consulte la Sección 3.4.6 para ver ejemplos de apertura
puntas y puntas abiertas virtuales.
También se pueden asignar retrasos a algunas relaciones. Un retraso impone un retraso entre su actividad anterior y su actividad posterior.
Un retraso en una dependencia SS retrasa el inicio del sucesor, y un retraso en una dependencia FF retrasa el final del sucesor. Por ejemplo,
si una actividad tiene una dependencia de SS con un retraso de +5 días, retrasaría el inicio de la actividad sucesora hasta 5 días después de
que haya comenzado la actividad predecesora. El programador debe usar los retrasos con cuidado y comprender sus impactos. Los retrasos
solo deben usarse para representar retrasos que son físicamente necesarios, no representan trabajo y tienen duración pero no recursos
asignados. Los retrasos no se deben utilizar para representar un período de tiempo en el que se está realizando el trabajo, como la revisión de
un documento antes de que avance la siguiente fase. Se recomienda que este tipo de trabajo se muestre como una actividad en el modelo de
cronograma en lugar de usar un retraso. Cuando se incluyen, dichas actividades pueden codificarse para mostrar que son actividades de las
que es responsable otra parte (p. ej., el cliente). Estas actividades a veces se denominan tareas de visibilidad del cronograma (SVT). Esta
práctica permite un mejor control del proyecto y hace evidente cuando una entidad específica está impactando el proyecto.
El uso de más de un calendario en un modelo de horario puede afectar los resultados de retraso calculados dentro del modelo de horario.
Además, es extremadamente importante comprender cómo los diferentes paquetes de software manejan múltiples calendarios.
También es posible asignar restricciones a actividades e hitos que requieren que una actividad o hito comience o finalice en puntos
específicos en el tiempo. Es imperativo estudiar los diversos tipos de restricciones que se utilizan y comprender
59
Terminar para comenzar
El inicio de la actividad sucesora.

FS depende de la finalización de la actividad
anterior.
Actividad X Actividad Y
En este ejemplo, la actividad X debe estar completa
antes de que la Actividad Y pueda comenzar.
Final a Final
La finalización de la actividad sucesora.

FF depende de la finalización de la actividad
Actividad X anterior.
En este ejemplo, la actividad X debe estar completa

antes de que la Actividad Y pueda terminar.
Actividad Y
Comienzo a Comienzo
El inicio de la actividad sucesora.

depende del inicio de la actividad
Actividad X predecesora.
SS En este ejemplo, la actividad Y puede comenzar después de

que haya comenzado la actividad X.
Actividad Y
Empezar a acabar
La finalización de la actividad sucesora.

depende del inicio de la actividad
Actividad X predecesora.
En este ejemplo, la Actividad Y no puede completarse

hasta que la Actividad X haya comenzado.
SF
Actividad Y
Figura 3-4. Ilustraciones de tipos de relaciones en la metodología CPM
los efectos y matices que su uso tiene sobre el modelo de cronograma. La práctica generalmente aceptada es que las restricciones y
los retrasos no deben usarse para reemplazar la adición de actividades y relaciones. Sin embargo, el uso de restricciones
generalmente se reconoce como necesario para cumplir con las obligaciones contractuales.
Cada actividad, excluyendo el hito de inicio inicial, debe tener una relación de predecesor impulsor, un predecesor FS o SS
(relación ?S), que determina lógicamente cuándo debe comenzar la actividad. De manera similar, cada actividad, excepto el hito final
final, también debe impulsar una actividad sucesora a través de un sucesor FS o FF.
60 Seccion 3
relación (F? relación). Consulte la Figura 3-5. Tenga en cuenta que el "?" en las declaraciones anteriores y en la figura 3-5 puede representar
un tipo de relación de inicio (S) o final (F).
La actividad requiere en
menos una relación "?S"
Cualquier actividad típica
La actividad requiere en
menos una "F?" relación
Figura 3-5. Relaciones de actividad requeridas
Cuando este tipo de relaciones lógicas no se encuentran en el cronograma, las actividades se conocen como colgantes o abiertas. Esto
crea incertidumbre y probablemente presenta datos no válidos en el modelo de cronograma, lo que da como resultado la producción de
información del proyecto inexacta. Consulte la Sección 3.4.5 para obtener más detalles que ayudarán a aclarar la condición.
3.2.1.4 DETERMINAR RECURSOS PARA CADA ACTIVIDAD
Estimar los recursos de la actividad es el proceso para determinar el tipo y las cantidades de material, mano de obra, equipo o
infraestructura necesarios para realizar cada actividad. Cuando un proyecto está limitado en términos de recursos y la duración del proyecto
podría verse afectada, los recursos deben incorporarse al modelo de cronograma. Aunque a veces se realizan juntos, el proceso Estimar
recursos de actividad debe completarse antes que Estimar duración de actividades (consulte la Guía del PMBOK® para obtener más
información y claridad sobre los problemas de disponibilidad de recursos). Las horas que necesita un diseñador senior para realizar la
actividad en comparación con un diseñador junior para realizar la misma actividad pueden ser considerablemente diferentes, lo que afecta la
duración y la calidad de los resultados de la actividad y, en última instancia, el costo del proyecto.
En algunos proyectos, especialmente los de menor alcance, las siguientes actividades están tan estrechamente vinculadas que se ven como
un solo proceso: definición de actividades, secuenciación de actividades, estimación de recursos, estimación de la duración de las actividades
y desarrollo del modelo de cronograma. Además, los recursos pueden afectar la ruta crítica cuando el equipo del proyecto no los tiene en
cuenta.
61
3.2.1.5 DETERMINAR LA DURACIÓN DE CADA ACTIVIDAD
La duración es una estimación del tiempo de trabajo necesario para realizar el trabajo representado por la actividad.
En el caso de los recursos del equipo, la cantidad de recursos que se espera que estén disponibles para realizar una actividad, junto con la productividad
estándar o esperada de esos recursos, a menudo determina la duración de la actividad. Un cambio en un recurso impulsor asignado a la actividad tendrá un
efecto sobre la duración, pero esta no es una relación simple y lineal. Otros factores que influyen en la duración son el tipo o el nivel de habilidad de los
recursos disponibles para realizar el trabajo, los calendarios de recursos, el riesgo asociado con el trabajo y la naturaleza intrínseca del trabajo. Algunas
actividades (p. ej., una prueba de estrés de 24 horas) tardan un tiempo determinado en completarse, independientemente de la asignación de recursos.
Si bien es factible estimar la duración de una actividad en cualquier momento, las buenas prácticas generalmente aceptadas recomiendan (a) definir
primero la actividad, (b) vincularla lógicamente a la secuencia general del cronograma y (c) centrarse en los recursos y la duración de la actividad. . En este
momento, se comprende mejor la relación entre la duración de la actividad y el trabajo en el horario; por lo que se pueden comenzar a determinar los flujos de
recursos, el tamaño de los equipos de actividades, etc. La relación entre la duración de la actividad y su costo se explicita en base a estimaciones o supuestos
tanto para el costo como para el cronograma. Este documento debe mantenerse actualizado a medida que cambien las duraciones del cronograma durante el
mantenimiento del modelo de cronograma.

Consulte las Secciones 3.3 y 3.4 para obtener más información.
El programador debe comprender el método utilizado por el modelo de programación para planificar las actividades relacionadas con
estimación de la duración de cada actividad del cronograma. Hay dos tipos de métodos de modelo de cronograma:
u Modelos de horario deterministas. Los modelos de programación deterministas son redes de actividades conectadas con dependencias que
describen el trabajo a realizar, la duración estática y la fecha planificada para completar el proyecto si todo sale según lo planeado.
u Modelos de horario probabilístico. Los modelos de horario probabilístico son redes con todos los elementos de un modelo de horario determinista,
donde la duración de la actividad de las tareas son variables aleatorias con duraciones mínimas y máximas asignadas y una distribución de
probabilidad apropiada.
Para obtener más información sobre la estimación de la duración de la actividad, consulte el Estándar de práctica para la estimación de proyectos [7]. Para
obtener más información sobre las mejores prácticas para el análisis de riesgos de proyectos utilizando modelos de cronograma probabilístico, consulte el
Estándar para la gestión de riesgos en carteras, programas y proyectos [6].
3.2.1.6 ANALIZAR LA SALIDA DEL PROGRAMA
Una vez completado, el modelo de cronograma contiene un conjunto de actividades únicas que tienen duraciones variables y están conectadas por
relaciones lógicas definidas. El modelo de cronograma proporciona al equipo del proyecto información sobre lo que debe lograrse y la secuencia requerida
para lograr los entregables del proyecto. Sin embargo, el modelo de cronograma no indica cuándo se deben realizar estas diversas actividades. Para adquirir
esa información, el
62 Seccion 3
La herramienta de programación se activa para calcular las fechas y otros valores dentro del modelo de programación de acuerdo con el
método de programación elegido. La función de programación siempre requiere tres procesos distintos para el análisis de tiempo, y requiere un
cuarto proceso cuando se utiliza la nivelación o nivelación de recursos. Los pasos discretos son:
u Paso 1. Asigne una fecha de inicio al hito de inicio. Luego, moviéndose a lo largo de la red de actividad a actividad (de izquierda a
derecha) y en la secuencia definida por las relaciones lógicas, asigne fechas de inicio y finalización para cada actividad e hito, según
lo determinen las duraciones definidas. Esto se llama un pase hacia adelante. Las fechas de inicio y finalización de cada actividad se
denominan fechas de inicio anticipado y finalización anticipada. Cuando el análisis llega al final del modelo de cronograma, el software
determina la fecha de finalización más temprana posible para el proyecto y la duración más corta del proyecto en función de las
duraciones estimadas de la actividad y las relaciones lógicas definidas.
u Paso 2. Asigne una fecha de finalización al hito de finalización. Esta podría ser la misma fecha que la calculada por el pase de
avance o una fecha diferente que se aplicó como una restricción debido a los requisitos contractuales, etc. El proceso de análisis luego
retrocede a través de la red de derecha a izquierda hasta que llega de nuevo a la hito de inicio, y el software asigna otro conjunto de
fechas de inicio y finalización para cada actividad. Esto se denomina paso hacia atrás y establece las fechas de inicio tardío y
finalización tardía para cada actividad e hito. Las fechas de inicio tardío y finalización tardía representan las fechas más tardías en que
cada tarea puede comenzar y finalizar sin causar un retraso en la fecha de finalización del proyecto.
u Paso 3. Calcule los valores flotantes comparando las fechas tempranas y tardías (consulte la Sección 3.4.2 para obtener más detalles):
n Flotación total. Calcule la flotación total restando la fecha de finalización anticipada de la fecha de finalización tardía (o el inicio
temprano de la fecha de inicio tardía). Flotación total negativa significa que las fechas no son factibles sin cambiar el plan.
Nota: la flotación total se refleja en cada actividad, pero se deriva del proyecto como un todo. Indica el número de días que la ruta
crítica del proyecto puede deslizarse (o necesita recuperarse) para cumplir con la fecha de finalización deseada. El valor es un
valor compartido entre todas las actividades en una ruta específica para el proyecto. Por lo tanto, cualquier actividad en ese
camino puede usar una parte o la totalidad, o recuperar una parte o la totalidad, según sea necesario.
n Flotación libre. Calcule la flotación libre restando la fecha de finalización anticipada de la actividad del comienzo anticipado de la
el primero de sus sucesores. El free float nunca es un valor negativo.
Nota—Free float indica la cantidad de tiempo que un predecesor puede deslizarse antes de impactar a su sucesor.
u Paso 4. Llevar a cabo la nivelación de recursos. Una vez que se hayan calculado los valores flotantes, realice la nivelación de recursos
para minimizar las sobreasignaciones de recursos o reducir las fluctuaciones en la demanda de recursos. Si este proceso se realiza de
forma automática, determine los procesos y algoritmos a utilizar.
La mayoría de los paquetes de software de programación de proyectos tienen múltiples opciones y configuraciones que pueden tener
un impacto significativo en la programación nivelada de recursos resultante. Independientemente de la configuración del software de
programación, existe un equilibrio entre permitir que la solución de nivelación amplíe la duración total del proyecto y permitir el uso de
más recursos de los permitidos inicialmente. La disponibilidad de recursos se puede aumentar agregando más recursos al equipo o
usando horas extras.
63
Revise la vista completa de la asignación de recursos en todas las actividades antes de finalizar la nivelación general de recursos. Cuando se
determina una solución a nivel de recursos, realice ajustes manuales a la lógica del cronograma (p. ej., aumente o disminuya la duración,
agregue o elimine relaciones, o inserte o elimine retrasos en relaciones o recursos) según sea necesario para capturar este esfuerzo de
nivelación. El uso de restricciones para bloquear la imagen nivelada no se considera una buena práctica, ya que interfiere con los cálculos de
programación normales.
3.2.1.7 APROBAR EL MODELO DE HORARIO
El equipo del proyecto revisa los resultados de este proceso de programación inicial para determinar la aceptabilidad del programa.
modelo. La revisión debe considerar:
u Fecha de finalización del proyecto analizada,
u Fechas de finalización de hitos,
u Rutas críticas (la ruta más larga para el proyecto o según las restricciones),
u Valores flotantes totales y requisitos de recursos (tasas de consumo de recursos durante el ciclo de vida del proyecto), y
u Tasas de aumento de recursos en comparación con la disponibilidad de recursos, etc.
Cuando se requieren modificaciones, el equipo del proyecto realiza cambios en la lógica del cronograma, las asignaciones de recursos y/o
o duraciones, y luego vuelve a analizar la programación. La alteración más común requerida involucra acciones para reducir la duración total del
cronograma o ajustes a la carga de recursos. Las técnicas clave utilizadas para comprimir el cronograma son el bloqueo y el seguimiento rápido.
chocando . Crashing consiste en agregar recursos a actividades críticas para acortar su duración (lo que puede o no aumentar el costo) o gastar
dinero de otras maneras para reducir la duración de las actividades (por ejemplo, acelerar partes). Al agregar recursos para reducir la duración
de la actividad, el bloqueo solo funciona para las actividades impulsadas por el esfuerzo. El bloqueo solo debe realizarse en actividades en la
ruta crítica y luego solo en aquellas actividades que producen el resultado más rentable. El bloqueo generalmente aumenta los costos del
proyecto por algún factor.
Seguimiento rápido. El seguimiento rápido consiste en cambiar la lógica superponiendo actividades críticas en lugar de trabajarlas estrictamente en
secuencia. El seguimiento rápido aumenta el riesgo de repetición del trabajo porque las actividades se inician antes de que se completen sus
predecesores iniciales (consulte la Sección 6.5.2.6 de la Guía del PMBOK®) y posiblemente contribuya a un mayor número de órdenes de
cambio en el trabajo contratado.
64 Seccion 3
Ambas acciones pueden resultar en una compensación de costo versus fechas de programación. Estas iteraciones continúan hasta que se
desarrolla un modelo de cronograma aceptable, uno que las partes interesadas clave del proyecto puedan acordar que es alcanzable y asequible.
El proceso formal para la aprobación del modelo de cronograma de referencia se define en el plan de gestión del cronograma.
3.2.1.8 LÍNEA BASE DEL MODELO DE HORARIO
Una vez acordado y aprobado, la primera instancia del modelo de cronograma se denomina modelo de cronograma de referencia del proyecto.
Esta es la versión que tiene un desarrollo completo y está aprobada para su captura o copia para futuras referencias.
Esta línea de base se convierte en el punto de referencia contra el cual se mide el desempeño del proyecto. Es una práctica generalmente aceptada
que cada proyecto tenga un modelo de cronograma de referencia antes de que comience el trabajo del proyecto. Una vez que la línea de base ha
sido aprobada a través de procedimientos formales, los informes se distribuyen de acuerdo con el plan de gestión de comunicaciones del proyecto,
y los cambios en la línea de base se monitorean y controlan a través del proceso integrado de control de cambios y la gestión de la configuración.
La información del modelo de cronograma de referencia permite la determinación de la ruta crítica del proyecto original y la identificación de los
riesgos del cronograma del proyecto. Consulte la Sección 3.3.5 para obtener información adicional sobre la actualización y revisión de las líneas de
base.
3.2.1.9 NIVELES DE HORARIO
Los horarios se pueden crear y definir en varios niveles. El equipo del proyecto especifica las reglas para la granularidad relativa de las
actividades del cronograma del nivel en el modelo de cronograma general. Cabe señalar que los niveles de programación pueden cambiar según el
enfoque (p. ej., ágil), el profesional y los requisitos de programación de la organización.
La Sección 3.5 contiene informes de muestra que se pueden producir para audiencias de varios niveles de programación. Cada nivel tiene un
propósito general y un contenido de la siguiente manera:
u Nivel 0—Resumen del proyecto. Este informe es una sola línea que representa todo el proyecto y, a menudo, se usa para comparar
proyectos en un programa o cartera. Las audiencias para este nivel de cronograma incluyen, entre otros, socios estratégicos (p. ej.,
clientes), altos ejecutivos, gerentes de cartera/programas y gerentes de operaciones.
u Nivel 1—Resumen ejecutivo. Este informe es un cronograma de alto nivel que incluye hitos clave y actividades resumidas por fase principal,
etapa o proyecto en ejecución. Por lo general, se representa en formato de gráfico de barras y puede originarse en una tabla de elementos
clave o un gráfico, pero en última instancia debe estar respaldado por un cronograma que contenga evoluciones de trabajo integradas
durante el ciclo de vida del proyecto. Los cronogramas de nivel 1 brindan información de alto nivel que ayuda en el proceso de toma de
decisiones (priorización y criticidad de los proyectos). Las audiencias para este nivel de programación incluyen, entre otros, clientes, altos
ejecutivos y gerentes generales.
sesenta y cinco
u Nivel 2—Resumen de gestión. Este informe generalmente se prepara para comunicar la integración del trabajo a lo largo del
ciclo de vida de un proyecto. Los cronogramas de nivel 2 pueden reflejar interfaces entre los entregables clave y los
participantes del proyecto (por ejemplo, contratistas, consultores, arquitectos, ingenieros, etc.), que se requieren para completar
los entregables identificados. Normalmente presentados en formato de gráfico de barras, los cronogramas de Nivel 2 brindan
información de alto nivel que ayuda en el proceso de toma de decisiones del proyecto (repriorización y criticidad de los
entregables del proyecto) y se acumula a partir de datos de cronograma más detallados. Las audiencias para este tipo de
cronograma incluyen, entre otros, clientes, gerentes generales, patrocinadores y gerentes de programas o proyectos.
u Nivel 3—Calendario de publicación. Este informe generalmente se prepara para comunicar la ejecución de los entregables
para cada una de las partes contratantes. El cronograma debe reflejar las interfaces entre los grupos de trabajo clave, las
disciplinas o los oficios involucrados en la ejecución del proyecto en un gráfico de barras o formato de red CPM.
Los cronogramas de nivel 3 ayudan al equipo a identificar rutas y actividades críticas que podrían afectar el resultado de una
etapa o fase de trabajo. Los cronogramas de nivel 3 permiten la mitigación y la corrección del curso al tiempo que permiten
informes completos del período de informe. Estos informes incluyen informes mensuales, curvas de materias primas e
histogramas. Las audiencias para este tipo de diseño incluyen, entre otros, gerentes de programas o proyectos y supervisores.
u Nivel 4—Planificación de la ejecución. Este informe está preparado para comunicar la evolución de la producción de trabajo
a nivel de entregable. El nivel del cronograma debe reflejar las interfaces entre los elementos clave que impulsan la realización
de las actividades. Normalmente presentados en formato de gráfico de barras o de red CPM, los cronogramas de Nivel 4
generalmente brindan suficientes detalles para planificar y coordinar actividades multidisciplinarias/artesanales. El período
cubierto por un diseño o informe de Nivel 4 suele ser de 1 semana a 1 mes, lo que respalda los hitos y duraciones
representados en un programa de Nivel 3. La base del cronograma de Nivel 4 son los diseños definidos en una base de datos
de paquetes de trabajo, listas u otro método de diagramación detallado donde los pasos detallados, los entregables y las
acciones se pueden comunicar durante la vida útil de los elementos programados. Las audiencias para este tipo de cronograma
incluyen, pero no se limitan a, gerentes de proyecto y supervisores responsables de realizar las actividades.
u Nivel 5—Planificación detallada. Este informe está preparado para comunicar los requisitos de las tareas para completar las
actividades identificadas en un cronograma detallado. Un cronograma de nivel 5 generalmente se considera un cronograma
de trabajo que refleja los requisitos de trabajo por hora, por día o por semana. Dependiendo de estos requisitos, los horarios
del Nivel 5 generalmente se preparan con 1 día o 1 semana de anticipación. El período cubierto por un diseño de Nivel 5 suele
ser de 1 día a 1 semana, lo que respalda los hitos y duraciones representados en los programas de Nivel 3 o 4. Por lo general,
los cronogramas de Nivel 5 se presentan en un formato de lista de actividades sin representaciones gráficas de escala de
tiempo del trabajo a realizar. Los cronogramas de nivel 5 se utilizan para planificar y programar el uso de recursos (mano de
obra, equipos y materiales) para cada tarea. Las audiencias para este tipo de horario incluyen, entre otros, supervisores y
miembros del equipo responsables de realizar el trabajo.
66 Seccion 3
3.3 PROGRAMAR EL MANTENIMIENTO DEL MODELO
Para asegurar la ejecución exitosa del proyecto, son necesarios un control de cambios efectivo y procedimientos de actualización disciplinados.
Casi todos los proyectos inevitablemente experimentan cambios. La clave es determinar la manera en que el proyecto aprueba y realiza un
seguimiento de los cambios a medida que ocurren a lo largo del ciclo de vida del proyecto. El cambio puede ocurrir cuando el trabajo avanza más
rápido o más lento de lo planeado, cuando ocurren cambios en otros elementos del proyecto (por ejemplo, cambios en el alcance) y/o cuando el
equipo del proyecto modifica su enfoque del trabajo del proyecto. El cambio también puede ser impulsado por problemas externos del proyecto
sobre los que el equipo no tiene control pero a los que debe reaccionar.
El seguimiento del progreso comienza después de que se establece la línea de base del modelo del proyecto, comienza el trabajo y se
implementan los procesos regulares de seguimiento y control. Estos procesos son importantes para ayudar a identificar los problemas lo antes
posible y minimizar su impacto en la finalización exitosa del proyecto. Los pasos principales para el seguimiento del progreso son los siguientes:
u Paso 1. Guarde un modelo de cronograma de referencia que contenga las fechas contra las cuales se compara el progreso. El modelo de
cronograma actual se puede copiar y aprobar como línea de base, o se puede aprobar un modelo de cronograma más adecuado como
línea de base.
u Paso 2. Informe el progreso del cronograma a partir de una fecha de datos específica, también conocida como fecha de estado, fecha de
actualización, fecha actual, fecha actual o fecha actual. La fecha de datos es un punto en el tiempo cuando se registra el estado del proyecto.
La fecha de los datos incluye la fecha (incluida la hora del día) a través de la cual se determina e informa el estado y el progreso del
proyecto. Cualquier dato a la izquierda de la fecha de datos (anterior) se considera información histórica.
Cualquier dato a la derecha de la fecha de datos (posterior) es el pronóstico del trabajo restante. La fecha de los datos es también el punto
en el que se llevan a cabo los análisis de medición del rendimiento y la programación. Este progreso informado, como mínimo, debe incluir
las fechas reales de inicio y finalización, las duraciones o el trabajo restante y el porcentaje completado.
u Paso 3. Asigne la nueva fecha de datos y vuelva a calcular todas las fechas de actividad como el último paso para avanzar en la
modelo de horario.
Los pasos 2 y 3 del proceso de estado/actualización ocurren regularmente, lo cual se determina durante el proceso de planificación del proyecto.
Los pasos necesarios para mantener la programación en cada estado/actualización se describen en las Secciones 3.3.1 a 3.3.7.
3.3.1 RECOPILAR ACTUAL Y TRABAJO O DURACIÓN RESTANTE
Recopile el estado real de las actividades del proyecto que deben ocurrir dentro del período de tiempo específico del proyecto que se está
midiendo. La información de estado recopilada incluye las fechas de inicio reales de todas las actividades que han comenzado y las fechas de
finalización reales de todas las actividades que se han completado a partir de la fecha de los datos. Cuando una actividad está en curso,
67
determinar la cantidad de trabajo real, el valor ganado, la duración real lograda, la cantidad de trabajo restante y la duración del tiempo
necesario para completar el esfuerzo restante. El estado también puede incluir cambios en la duración o relaciones para actividades futuras,
suponiendo que estos cambios futuros se modifiquen de acuerdo con el proceso de control de cambios del proyecto discutido en la Sección
3.3.8. Otra información recopilada en este momento puede incluir datos sobre el uso de recursos y los costos incurridos, siempre que los datos
hayan sido rastreados a nivel de actividad. Recopile los datos a partir de una fecha de datos específica (fecha/hora). Esta fecha de datos es el
final del último día del intervalo de tiempo predeterminado y refleja el último día del ciclo de actualización para garantizar que todo el progreso
se informe hasta esta fecha.
3.3.2 ACTUALIZAR EL MODELO DE HORARIO SEGÚN LOS ACTUALES
Incorpore el progreso real logrado durante el ciclo de actualización actual. Incorpore la información recopilada durante el proceso de
actualización periódica en el modelo de cronograma, analice cualquier esfuerzo de trabajo futuro y luego cree el nuevo pronóstico del modelo
de cronograma. También en este momento, ingrese cambios a los flujos de trabajo futuros debido a cambios de alcance y otros problemas que
fueron aprobados por el proceso de control de cambios (consulte la Sección 3.3.8.) y que pueden tener un impacto significativo en el pronóstico
del nuevo modelo. Vuelva a programar todas las actividades incompletas en función de las duraciones o el trabajo restantes recién asignados
a partir de la fecha de los datos. Tenga cuidado al actualizar el progreso porque muchos programas de software de programación permiten
aplicar las fechas reales al trabajo futuro. Asegúrese de que se implementen prácticas de control de calidad para identificar la entrada de fechas
reales más allá de la fecha de los datos y los valores de porcentaje completo que se informan que no son válidos en relación con las fechas.
3.3.3 COMPARAR Y ABORDAR CUALQUIER DESVIACIÓN
Revise y compare los resultados del modelo de cronograma recién actualizado con la línea de base almacenada. Identifique y explique las
variaciones de costos y cronogramas (p. ej., actividades que no comenzaron o no terminaron a tiempo), desviaciones cuantificables, salidas o
divergencias con respecto a una línea de base conocida o un valor esperado. Utilice umbrales de variación e identifique los rangos aceptables
definidos en el plan de gestión del cronograma para determinar qué actividades y condiciones requieren informes y más análisis y acción. Este
análisis debe incluir discusiones sobre las formas de mitigar las tendencias desfavorables y los deslizamientos de rendimiento. Las discusiones
también pueden incluir procesos que aborden el control de cambios. Una variación de fecha comúnmente utilizada es la variación de finalización
entre la finalización anticipada y la finalización de referencia, que generalmente se expresa en unidades como días hábiles.
Puede ser útil comparar el estado de una actividad con más de un objetivo. Por ejemplo:
u Calendario actual frente al plan original (la línea de base) para ver el retraso en comparación con el plan original.
u Calendario actual frente al último período de actualización para ver los cambios desde la última actualización con el fin de
identificar deslizamientos y tendencias incrementales.
68 Seccion 3
3.3.4 ACTUALIZAR EL MODELO DE CRONOGRAMA CON LOS CAMBIOS APROBADOS
Actualice el modelo de cronograma con cualquier cambio aprobado que resulte del proceso general de control de cambios para garantizar que
el modelo de cronograma represente el 100 % del alcance conocido actual del proyecto y el plan de gestión del proyecto actual.
Para obtener detalles adicionales sobre este proceso, consulte la Sección 3.3.8. Los procesos de actualización y ajuste pueden necesitar varias
iteraciones para mantener un modelo de cronograma que siga siendo realista y alcanzable.
3.3.5 ACTUALIZAR EL MODELO DE HORARIO BASE
Revise el modelo de programación de referencia a intervalos regulares y periódicos. Siempre que el proyecto se vea afectado por cambios
importantes en el alcance, ya sea (a) a través del proceso formal de control de cambios o (b) por eventos (p. ej., un rediseño importante o un
desastre natural) que cambien significativamente el modelo de cronograma del proyecto, puede ser necesario realizar una nueva línea de base.
Se necesita una nueva línea de base cuando el proyecto ya no se alinea bien con sus indicadores clave de rendimiento predefinidos.
Es esencial explicar adecuadamente por qué se necesita el esfuerzo de rebaseline. Esto generalmente incluye una explicación de los problemas
del proyecto y los impactos relacionados con el cambio que está impulsando un esfuerzo de rebase como se documenta en el proceso de control
de cambios. Un esfuerzo de rebaseline requiere que las causas de los cambios del proyecto sean identificadas y acordadas por las partes
interesadas clave del proyecto. Una vez que todos estén de acuerdo en que este nuevo modelo de cronograma refleja con precisión el camino a
seguir del proyecto, captúrelo y utilícelo para realizar un seguimiento del rendimiento a partir de ese momento. Por lo general, esta nueva línea
base se nombra secuencialmente después de la primera línea base. Archive la línea de base original y consérvela para registros y fines históricos
(nunca se elimina). También se debe tener en cuenta que cuando se realiza una nueva línea de base, se acepta el rendimiento de todas las
actividades completadas y, por lo tanto, todo el trabajo restante ahora se muestra según lo programado en ese momento. Esto significa que las
estadísticas de rendimiento pasadas (buenas o malas) se ponen a cero y comienzan de nuevo desde ese punto en adelante.
3.3.6 COMUNICAR
Cuando se complete el ciclo de actualización del cronograma actual, distribuya los informes (consulte las Figuras 2-7 y 2-18 para ver las
presentaciones del modelo de cronograma) de acuerdo con el plan de gestión del cronograma y el plan de gestión de las comunicaciones del
proyecto. Consulte la Sección 3.5 para obtener más información y ejemplos de informes y presentaciones típicos que se pueden emitir de acuerdo
con el plan de gestión de comunicaciones asociado con el modelo de cronograma.
69
3.3.7 MANTENER LOS REGISTROS
La gestión adecuada de registros es parte del control de configuración. Detallar la lógica inicial y los principales puntos de decisión del
proyecto y el proceso de pensamiento que se llevó a cabo para crear la lógica del flujo del cronograma de referencia. Esto ayuda a respaldar
las acciones realizadas y las lecciones aprendidas. Es importante mantener registros que expliquen todos los cambios en la duración o la
lógica de las actividades a medida que se realizan modificaciones en el modelo de cronograma. Las notas de registro de actividad se utilizan
a menudo para este propósito. Estos registros proporcionan datos valiosos si es necesario reconstruir qué sucedió y por qué. El uso adecuado
de varios componentes (como registros de actividad/notas/comentarios) es importante para documentar el contexto de por qué una tarea se
retrasó o tomó más tiempo de lo esperado. Esta información se puede usar para (a) explicar más completamente por qué las actividades se
restringieron a una fecha determinada o (b) registrar cualquier otra información que explique lo que ocurrió en esta actividad. Compare el
cronograma de línea de base con la última actualización del cronograma para documentar los cambios que se han producido a lo largo del
tiempo y para determinar la precisión de la línea de base original. Esta información puede ser útil para futuros proyectos de similar alcance.
Muchas de las buenas prácticas y elementos descritos también se incluyen en la Sección 4 dentro de los detalles de cada componente
contenido en la lista de componentes del modelo de cronograma. Se necesita una comprensión completa de los diversos componentes para
maximizar el potencial de su aplicación adecuada y el desarrollo de un programa sólido.
3.3.8 CONTROL DE CAMBIOS
Controlar los cambios del proyecto es uno de los aspectos más importantes para mantener el proyecto dentro del cronograma y garantizar
que el modelo de cronograma siga siendo relevante en términos de su capacidad para realizar pronósticos precisos. Para obtener información
y orientación adicionales, consulte el Estándar de práctica para la gestión de la configuración del proyecto [8]. El cambio del proyecto puede
ser impulsado por (a) factores internos como un cambio de alcance o (b) factores externos sobre los cuales el equipo no tiene control. En
cualquier situación, el control de cambios adecuado debe ser una parte integral del proceso continuo de mantenimiento del modelo de cronograma.
Utilice componentes como registros de actividad, notas o comentarios para documentar el contexto, identificar por qué una tarea se retrasó o
tomó más tiempo de lo esperado y documentar los cambios en la lógica del modelo de programación. Es importante que el analista de
programación pueda comprender la trazabilidad hacia adelante y hacia atrás del modelo de programación desde la línea de base y determinar
cómo el cambio aceptado se corresponde con cualquier cambio en la lógica de programación. Cada instancia del modelo de cronograma
captura cualquier cambio entre las instancias anteriores del cronograma, incluidos los registros/notas/comentarios de actividades existentes
cuando se captura y archiva cada instancia. Estos registros/notas/comentarios proporcionan una excelente fuente de historial para cualquier
persona que intente determinar qué ocurrió durante la ejecución del proyecto y por qué.
70 Seccion 3
3.4 ANÁLISIS DEL MODELO DE HORARIO
El análisis del cronograma utiliza herramientas y técnicas comunes a lo largo del ciclo de vida del proyecto para identificar las desviaciones del modelo
de cronograma de referencia. El análisis del modelo de cronograma es responsabilidad del equipo del proyecto. El objetivo principal del análisis es la
identificación temprana de amenazas y oportunidades para los objetivos del proyecto. Para lograr este análisis, el modelo de cronograma debe ser capaz
de pronosticar los impactos/resultados de cualquier cambio, ya sea externo o interno, a los resultados deseados del proyecto. Estos impactos pueden ser
positivos o negativos, pero se reflejan como cambios en los puntos de finalización intermedios o finales previstos del proyecto.
Hay varias herramientas y técnicas disponibles para realizar el análisis del modelo de cronograma. Los procedimientos y políticas específicos que se
utilizarán para un proyecto se describen en el plan de gestión del cronograma del proyecto. Los elementos más comunes que se revisan durante el análisis
del cronograma se describen en las Secciones 3.4.1 a 3.4.13.
3.4.1 RUTA CRÍTICA Y ACTIVIDADES CRÍTICAS
Esta sección presenta y explica la diferencia entre la ruta crítica de un proyecto y las actividades críticas en un enfoque de CPM. Estos son términos que
a menudo se malinterpretan y se usan incorrectamente cuando se habla del proyecto.
Establecer, identificar y mantener la ruta crítica del proyecto es un elemento clave para monitorear su desempeño.
Es fundamental para los procesos forenses.
La Sección 3.4.1.1 analiza la ruta crítica con mayor detalle, y la Sección 3.4.1.2 se centra en las actividades críticas.
3.4.1.1 RUTA CRÍTICA
La ruta crítica del proyecto es uno de los componentes clave para comprender el desempeño del proyecto y monitorear con precisión
sus movimientos pronosticados con base en las entradas hechas a lo largo del tiempo al proyecto.
La ruta crítica (project Critical Path) es la secuencia de actividades que predice o define la ruta más larga y la duración más corta calculada para el
proyecto. Es el camino más largo a través del proyecto, comenzando en el primer hito y terminando al finalizar el proyecto. La ruta crítica determina la
duración del proyecto. Los cálculos de la ruta crítica consideran actividades y restricciones para determinar la ruta más larga del proyecto. Sin embargo, una
ruta crítica (ruta crítica especificada) puede terminar, por ejemplo, en un hito del cronograma que ocurre en cualquier punto dentro del modelo de cronograma
y que tiene una restricción de fecha de finalización no posterior al. (Tenga en cuenta que las restricciones se utilizan de forma selectiva en los modelos de
cronograma y solo después de comprender completamente sus impactos). También se puede solicitar un informe de ruta crítica para un subproyecto, fase,
oficio/disciplina, etc., que puede o no estar relacionado con el proyecto. camino critico.
71
A veces es necesario elevar la importancia de evoluciones de trabajo aparentemente menos significativas debido a problemas de riesgo u otros
requisitos específicos del proyecto. En estos casos, la aplicación de restricciones puede alterar la ruta crítica natural o sin restricciones del proyecto, lo
que provoca cambios inesperados en la duración y el costo del proyecto.
Un proyecto puede tener varias rutas críticas siempre que tenga varios hitos de subnivel críticos. Un proyecto con múltiples rutas críticas tiene un
mayor nivel de riesgo, ya que el incumplimiento de cualquiera de estas podría resultar en la imposibilidad de completar todos los hitos del proyecto.
Independientemente de cómo se definan las rutas o cuántas existan, siempre se puede determinar y monitorear la ruta desde un punto de inicio
dentro del proyecto hasta ese punto final específico. Una vez que se define una ruta, debe revisarse y analizarse después de cada actualización para
comprender y documentar cualquier cambio.
Las actividades que caen en la ruta crítica son actividades de la ruta crítica.
3.4.1.2 ACTIVIDADES CRÍTICAS
Es importante distinguir entre las actividades de la ruta crítica y las actividades críticas:
u Actividades de la ruta crítica. Aquellas actividades contenidas en la(s) ruta(s) crítica(s).
u Actividades críticas. Aquellas actividades vitales para el éxito de un proyecto, incluso cuando no están en la ruta crítica o la cadena crítica. Las
actividades críticas normalmente son de alto riesgo en términos de alcance, cronograma, recursos, seguridad, medio ambiente y/o costo y
pueden causar un retraso en la fecha de finalización del proyecto y una mayor probabilidad de fracaso del proyecto.
Todas las actividades contenidas dentro de cualquier ruta crítica son actividades de ruta crítica y también se consideran actividades críticas.
Sin embargo, las actividades críticas también pueden estar fuera de la ruta crítica.
3.4.2 FLOTACIÓN TOTAL Y FLOTACIÓN LIBRE
Free float (FF) representa la cantidad de tiempo que la fecha de finalización anticipada de una actividad puede retrasarse sin afectar ningún
fecha de inicio temprano de la actividad sucesora. FF es una propiedad de una actividad individual.
La flotación total (TF) representa la cantidad de tiempo que se puede retrasar la fecha de inicio anticipada o la fecha de finalización anticipada de
una actividad sin afectar el punto final del proyecto. El valor TF se comparte entre todas las actividades en una ruta específica hasta un punto donde las
rutas se fusionan o hasta el punto final del proyecto. Cuando una actividad en una ruta usa parte del TF disponible, esa cantidad de TF también se usa
para el resto de las actividades hasta el punto de fusión o el punto final del proyecto. Por ejemplo,
72 Seccion 3
en la Figura 3-6, cada actividad en este diagrama muestra el TF y FF después de cada barra de actividad. El TF aparece en primer lugar y el FF en
segundo lugar. Por ejemplo:
u La actividad A refleja (0, 0), lo que indica que tanto TF como FF son cero. Esto significa que esta actividad se encuentra en la ruta crítica.
Cualquier retraso en el desempeño de la Actividad A causará un impacto no solo en su sucesor, sino también en el punto final del proyecto o
el hito asociado.
u La actividad B refleja (10, 10), lo que indica que TF es de 10 días y FF es de 10 días. Esto significa que la Actividad B
el rendimiento podría descender 10 días antes de que se produzca un impacto en su sucesor.
u La actividad E refleja (10, 0), lo que indica que TF es 10 días y FF es 0 días. Esto significa que cualquier retraso en el rendimiento de la
actividad E tendrá un impacto en la fecha de inicio de la actividad sucesora, pero puede retrasarse 10 días antes de que se produzca un
impacto en la fecha de finalización tardía de la sucesora.
Flotación libre de 10 días

Día 1
A 0,0
15
Día 15
B 10,10
día 16
5
C 0,0
10
D 0,0
flotación libre
15
Flotación total
mi 10,0
2
Duración F 10,10
3
GRAMO
0,0
10
Figura 3-6. Flotación total y flotación libre
La flotación total y la flotación libre deben monitorearse y revisarse después de cada actualización del proyecto para determinar si han cambiado
desde la actualización anterior.
u Los cambios en la flotación total indican una amenaza para lograr la finalización del proyecto o hitos específicos.
u Los cambios en la flotación libre indican que la falta de progreso puede afectar a los sucesores inmediatos y hacer que comiencen
o terminar más tarde de lo esperado.
73
La flotación total y la flotación libre también pueden verse afectadas por las dependencias externas y otras fechas de restricciones estrictas
enumeradas en el modelo de cronograma. Estas dependencias externas deben explicarse en registros de actividad/notas/comentarios o vincularse a
hitos externos siempre que se apliquen para que todos puedan comprender qué cambios se han realizado y por qué.
El seguimiento y la gestión de estos dos componentes vitales son fundamentales para completar el proyecto a tiempo y cumplir los objetivos
previstos. Las reducciones en el capital flotante total y el capital flotante libre son fuertes indicadores de los lugares en los que es posible que sea
necesario desarrollar planes de recuperación.
3.4.3 ESTIMACIÓN DE LA DURACIÓN DE LAS ACTIVIDADES
Los datos de la información histórica disponible se pueden utilizar para desarrollar las estimaciones de duración.
Cuando hay mucha incertidumbre en la duración de la actividad, una técnica de estimación comúnmente utilizada es la estimación de tres puntos.
Estos tres puntos corresponden a duraciones de actividad definidas como duraciones optimista, más probable y pesimista.
Además, el registro de riesgos también se puede utilizar para apoyar la estimación de la incertidumbre en la duración de las actividades. Para cuantificar
la incertidumbre sobre la duración total del proyecto, a partir de la estimación de tres puntos de cada actividad, se suele utilizar PERT (técnica de
revisión y evaluación de programas), que utiliza una aproximación de la distribución beta. La duración de la actividad PERT se calcula como [duración
optimista + (4 × duración más probable) + duración pesimista]/6 en una distribución promedio ponderada y [duración optimista + duración más probable
+ duración pesimista]/3 en una distribución triangular.
PERT se centra en la duración de la actividad. Permite la duración aleatoria de la actividad y pondera la duración estimada de la actividad en el
rango de estimaciones de duración proporcionadas por las partes interesadas.
En la Figura 3-7, comenzando con un diagrama de precedencia, PERT permite determinar estimaciones de duración de actividad, teniendo en
cuenta la incertidumbre contenida en el proceso de estimación de duración. Se requieren tres estimaciones de duración para cada actividad:
u Duración optimista. La duración mínima de la actividad en las condiciones más favorables.
u Duración más probable. La duración de la actividad que ocurrirá con más frecuencia.
u Duración pesimista. La duración de la actividad en las condiciones menos favorables.
Las duraciones determinadas por la ecuación de referencia se utilizan como duraciones estimadas de actividad. Generalmente, las duraciones se
establecen en un nivel estadístico específico de significación (por ejemplo, un nivel de confianza del 95 %). La ponderación en la ecuación es una
aproximación manual de la distribución estadística. Con cálculos más sofisticados (p. ej., usando computadoras), es posible una implementación de
simulaciones estadísticas o múltiples de PERT, que se acerca a los métodos y resultados del análisis de Monte Carlo (consulte la Sección 3.4.11).
El grado de sesgo de la distribución lo sugiere la forma de la curva que representa las tres duraciones estimadas (como beta, uniforme o triangular).
La distribución que relaciona las tres estimaciones de duración (o estimaciones de costos) debe seleccionarse para que se ajuste mejor a los datos de
respaldo para actividades similares.
74 Seccion 3
Más
alto
Más probable
Promedio ponderado PERT =

Optimista + 4 x Más probable + Pesimista
6
Probabilidad
ocurrencia
de
bajo
Más
Distribución Beta
Pesimista
Optimista
Corto Más extenso
Posibles duraciones
Figura 3-7. Ejemplo de diagrama de precedencia con estimaciones de duración de actividad PERT
La desviación estándar de una actividad se refleja en la Figura 3-8:
u Grado de variación del promedio (media),
u Indica el error estándar en la estimación y da una idea de su precisión, y
u Cuanto mayor sea la desviación estándar (diferencia entre las estimaciones optimistas y pesimistas), mayor será la
riesgo en la estimación:
n ± 1 desviación estándar = 68,26 %, n ± 2
desviaciones estándar = 95,46 %,
n ± 3 desviaciones estándar = 99,73 %, y
n ± 6 desviaciones estándar = 99,999998%.
Se proporciona información adicional sobre técnicas de estimación en el Estándar de práctica para la estimación de proyectos [7].
75
68,26%
95,44%
99,73%
99,99%
Media + Seis Sigma
Figura 3-8. Ejemplo de desviación estándar de una actividad
Las restricciones de fecha restringen el flujo natural y la lógica de un proyecto y su capacidad para reaccionar a los cambios (tanto
planificados como no planificados), ignoran los efectos del riesgo y limitan la utilidad del análisis de riesgo del cronograma. Esto a veces se
denomina flexibilidad del modelo de cronograma: la capacidad de absorber cambios y aún así mantener las fechas de finalización del
proyecto y/o los hitos principales. Las restricciones de fecha deben evitarse siempre que sea posible. Las restricciones de fecha solo deben
usarse en aplicaciones limitadas después de una cuidadosa consideración y comprensión de cómo afectarán al proyecto durante todo su ciclo de vida.
Finalmente, deben usarse solo cuando sean compatibles con el curso de desarrollo esperado de un proyecto. El plan de gestión del
cronograma puede proporcionar instrucciones sobre el uso de restricciones de fecha.
76 Seccion 3
Un uso para una restricción de fecha es establecer una fecha no anterior o posterior a para actividades que no
tener un predecesor o sucesor efectivo en el cronograma. Un ejemplo de esto es la entrega de una pieza de equipo por parte de un proveedor cuando no
es práctico o deseable incluir las actividades del proveedor en el modelo de cronograma. Incluso en este ejemplo, se debe tener cuidado para no inyectar
una ruptura en la ruta crítica.
Las restricciones específicas hacen que el modelo de cronograma reaccione de manera diferente. Por ejemplo, una restricción de tipo tan pronto como
sea posible proporciona una flexibilidad completa sin una restricción impuesta. Sin embargo, un tipo de restricción de inicio no anterior a proporciona menos
flexibilidad ya que afecta los cálculos de fecha de inicio temprano en algunos escenarios. Finalmente, una restricción de inicio obligatorio elimina toda
flexibilidad y fuerza una fecha, lo que hace que sea muy difícil identificar los impactos de los cambios normales experimentados durante el ciclo de vida de
un proyecto. Debido a que las restricciones en última instancia limitan la flexibilidad de programación, deben usarse solo cuando la lógica de programación
no puede abordar correctamente la situación. Cuando se hace necesaria una restricción de fecha, se prefieren restricciones más flexibles.
Finalmente, siempre que se incorpore una restricción en un modelo de cronograma, también se debe incluir en la documentación del cronograma una
nota que explique el tipo de restricción agregada, su propósito previsto y la razón de su uso (por ejemplo, en la nota de actividad/
comentario/registro). Esto proporciona un registro para su uso en un momento posterior para explicar la lógica que se aplicó anteriormente en el proyecto.
3.4.5 ACTIVIDADES ABIERTAS
Una actividad abierta es una actividad que carece de un predecesor o un sucesor o ambos. Las actividades abiertas oscurecen las relaciones lógicas
entre las actividades del proyecto, crean una apariencia falsa de flotación en un proyecto y reducen el impacto aparente del riesgo durante un análisis de
cronograma. En tales casos, se cuestiona la relación lógica de lo que se requiere para iniciar la actividad o lo que esta actividad logra para que puedan
ocurrir evoluciones posteriores del trabajo.
Esta falta de lógica daña la validez de todo el modelo de programación. Las únicas actividades abiertas en un proyecto deben ser los hitos de inicio y
finalización al principio y al final del proyecto. A menos que estén vinculados a otros proyectos, los hitos de inicio y finalización de un proyecto siempre
contienen extremos abiertos.
Los extremos abiertos ocurren ya sea por omisión (el usuario no puede asignar una relación) o por el resultado del informe de progreso en el proyecto
o las relaciones que no cierran un camino (consulte la Figura 3-5), a veces denominados extremos abiertos virtuales.
La Figura 3-9 muestra dos ejemplos de extremos abiertos causados por omisión, resaltados por las flechas en negrita. En este ejemplo, la Actividad C
no tiene un predecesor y la Actividad F no tiene un sucesor. En ambos casos, se creó el ejemplo de cronograma y el usuario no cumplió con los requisitos
relacionados con las relaciones (es decir, cada actividad debe tener un predecesor FS o SS y un sucesor FS o FF). Sin este tipo de relaciones lógicas, las
actividades se denominan colgantes o abiertas. La incertidumbre en la duración de las actividades pendientes o abiertas no se transmite necesariamente al
resto del modelo de programación. Cuando se informa sobre el progreso del proyecto, el resultado puede hacer que las actividades se comporten como si
fueran abiertas.
77
A
B
mi
GRAMO
F Z
Figura 3-9. Ejemplo de extremos abiertos por omisión
Los casos de omisión se pueden resolver fácilmente asegurando la atención al detalle, el cumplimiento de las buenas prácticas y
cuidado deliberado al construir el horario.
Los extremos abiertos virtuales o las actividades colgantes ocurren con mayor frecuencia cuando las actividades del cronograma están
lógicamente vinculadas con relaciones que, una vez completadas, no proporcionan una relación de conducción real para una actividad
restante. Consulte la Figura 3-10. En este ejemplo, la flecha grande muestra que la Actividad B estaba vinculada a la Actividad C con una
relación SS. Una vez que pasó la fecha de los datos y se informó que la actividad B había comenzado, la actividad C también debería haber
comenzado; sin embargo, no lo hizo. Ahora la Actividad C no tiene relación de conducción excepto el tiempo (está manejando la fecha de
los datos). En este ejemplo (como en la mayoría de los casos que involucran extremos abiertos virtuales), cuando las actividades se
secuencian utilizando relaciones SS y FF como los únicos predecesores o sucesores, aumenta la probabilidad de que se desarrollen
extremos abiertos virtuales. Dados estos tipos de relaciones, el desempeño de la actividad sucesora puede ocurrir una vez que la actividad
predecesora comienza o finaliza con cualquier retraso asignado. Una vez que pasa este período de retraso, la actividad sucesora no tiene
una relación de conducción lógica. A menudo, la actividad predecesora se informa como completa y la duración del tiempo pasa. Sin
embargo, la actividad en cuestión no comienza ni termina como implicaría la relación. En una fecha posterior, la actividad en cuestión podría
tener un impacto crítico en el proyecto, pero nadie recuerda por qué.
78 Seccion 3
Fecha de Datos
A
B
mi
GRAMO
F Z
Figura 3-10. Ejemplo abierto virtual
3.4.6 LÓGICA FUERA DE SECUENCIA (OOS)
La lógica OOS surge cuando se informa sobre el progreso de un proyecto. Una instancia OOS puede ocurrir en una variedad de situaciones como
descrito en esta sección. La Figura 3-11 muestra la lógica antes y después de la actualización.
En la Figura 3-11, la Actividad B se informa como iniciada antes de que su predecesora se informe como finalizada en una relación de fin a
comienzo (FS), lo que provoca la lógica OOS. En esta situación, la actividad A tiene una relación de fin a comienzo (FS) con la actividad B, pero la
actividad B se actualiza y se le asigna una fecha de inicio real antes de que a la actividad A se le asigne una fecha de finalización real. Esto viola la
relación lógica FS y el resultado es la lógica OOS. Este caso plantea la cuestión de si la actividad predecesora debe completarse antes de que
comience la actividad sucesora de acuerdo con la lógica asignada. La flecha 1 muestra la violación de la lógica al principio de la actividad B, mientras
que la flecha 2 muestra que esta brecha se producirá cuando se utilice el método de programación de lógica retenida.
De manera similar, también se pueden informar las actividades vinculadas con las relaciones de inicio a inicio (SS) y de fin a fin (FF).
como OOS al comenzar o terminar la actividad sucesora antes de que se haya producido la relación de conducción.
La lógica OOS debe corregirse (p. ej., mediante una mayor descomposición de una de las actividades involucradas) o eliminarse para preservar
la integridad del análisis del modelo de cronograma. Los informes de análisis del modelo de programación pueden identificar situaciones de OOS e
identificar adecuadamente cómo resolver mejor los problemas de lógica de OOS. No se recomienda confiar únicamente en la herramienta de
programación para corregir el problema porque solo el equipo puede determinar mejor la resolución lógica de OOS. En algunos casos, la relación
definida creada durante la etapa de planificación puede no ser correcta y debe corregirse para este proyecto y para futuras referencias.
79
Antes de la actualización
Despúes de actualizar
Fecha de Datos
B B
1 2
Figura 3-11. Ejemplo de lógica fuera de secuencia
Según el software de programación que se utilice y las opciones de programación seleccionadas, una condición OOS da como resultado cálculos de programación
como se refleja en la Figura 3-12. Un enfoque de lógica retenida utiliza la lógica original provista y no permite que el resto de la actividad comience de nuevo hasta que
la actividad predecesora esté totalmente completa. Como se muestra, esto da como resultado que las fechas de actividad aguas abajo sean posteriores o se retrasen.
Un enfoque de anulación del progreso, por otro lado, ignora la lógica original y permite que las actividades continúen según lo informado, lo que permite que el trabajo
se realice en paralelo. El resultado final es que se pronostica que las actividades informadas terminarán antes de lo previsto anteriormente, lo que puede no ser válido.
La principal diferencia entre la lógica retenida y la anulación del progreso es si la lógica original era correcta o si los cálculos resultantes son válidos. Esto tiene un
impacto directo en la capacidad de analizar con precisión el rendimiento del proyecto resultante. El sistema proporciona dos fechas de finalización previstas diferentes
para las actividades según los cálculos elegidos. Por lo general, el método de anulación de progreso proporciona una fecha de finalización anterior y la lógica retenida
proyecta una fecha de finalización posterior. Se recomienda como buena práctica abordar siempre cada aparición de OOS y utilizar el método de lógica retenida. El
usuario debe resolver la ocurrencia de OOS cada vez que ocurra, ya que esto aumentará la validez del modelo de programación general.
80 Seccion 3
Anulación de progreso Lógica retenida
ANUNCIO ANUNCIO
RD = 12 Días RD = 12 Días
ANUNCIO ANUNCIO
RD = 18 Días RD = 18 Días
Fecha de Datos Fecha de Datos
Duración real de AD RD Duración restante norte
Figura 3-12. Anulación de progreso frente a lógica retenida
La lógica OOS también es la causa de los indicadores clave de rendimiento del proyecto inexactos. Dependiendo de las reglas del programa
de software, la lógica OOS puede alterar la fecha de finalización proyectada de los diversos hitos del proyecto en función de cómo se calcule
el modelo de programación. En algunos casos, identificar la causa de este deslizamiento puede ser muy difícil de determinar y resolver. Esta
es otra razón para resolver estas condiciones de OOS tan pronto como se identifiquen.
3.4.7 Adelantos y retrasos
El riesgo puede consumir o extender retrasos fijos con consecuencias imprevistas para la duración general del proyecto. Figura 3-13
muestra la diferencia entre un adelanto y un atraso.
tu plomo. Una modificación de una relación lógica que permite una aceleración de la actividad sucesora (que se muestra bajo el
encabezado Plomo en la figura como un valor negativo).
tu retraso Una modificación de una relación lógica que impone un retraso de la actividad sucesora (que se muestra bajo el encabezado
Lag en la figura). Esto puede introducir un riesgo de cronograma y debe modelarse como una actividad discreta con su propia
incertidumbre de duración siempre que sea posible.
Los clientes potenciales también introducen riesgos, especialmente en la gestión de inventario justo a tiempo (JIT). Esto puede tener un
efecto en cascada en el modelo de cronograma cuando el proyecto se administra con un espacio de inventario limitado. Adicionalmente, promover
81
Guiar Retraso
Lista completa de golpes escribir borrador
FS (–2) Semanas SS (15) Días
Realizar Paisajismo Editar borrador
El trabajo de paisajismo comienza 2 semanas antes de El trabajo de edición comienza 15 días después
terminando los esfuerzos de Complete Punch List comienza el trabajo de escribir borrador
Figura 3-13. Adelantos frente a retrasos
un adelanto/retraso de una actividad completa permite que se le asigne atributos adicionales (es decir, nombre, duración restante, etc.).
La falta de visibilidad del adelanto/retraso y la distorsión del cálculo de la ruta crítica contribuyen al riesgo de cronograma. Existe un
riesgo específico asociado con los adelantos y retrasos que se aplican a las actividades en las que se utilizan diferentes calendarios
(actividad o recurso). Por lo tanto, es importante tener una comprensión clara de las consecuencias que los adelantos y los retrasos
pueden tener en un modelo de cronograma. Muchos programas de software permiten que los adelantos y retrasos se definan como una
duración fija o como un porcentaje de la duración de la actividad. Se utiliza el juicio para determinar el método correcto que mejor
represente la naturaleza de la actividad y el adelanto o retraso.
3.4.8 RELACIÓN DE INICIO A META
Las relaciones de principio a fin (SF) rara vez se usan en la planificación determinista porque involucran la circunstancia inusual de
que una tarea sucesora ocurra antes que su predecesora lógica. Revise cualquier relación SF para asegurarse de que no sea el resultado
de errores de programación y modifíquelos cuando sea necesario.
Este ejemplo de una relación SF proporciona una mejor comprensión de esta rara relación. Suponga que el proyecto requiere la
entrega de un equipo para apoyar las actividades de construcción. Puede que no sea práctico proporcionar una lógica para las actividades
de fabricación y entrega de equipos, pero el equipo desea que las actividades de construcción determinen las fechas de entrega. En este
caso:
u El antecesor siempre conduce al sucesor. Por lo tanto, la relación SF proporciona la solución.
u La fabricación del equipo puede concluir en la fecha de inicio de la actividad que requiera la instalación del equipo.
82 Seccion 3
3.4.9 ENLACES HACIA/DESDE ACTIVIDADES RESUMEN
Generalmente, no se recomienda usar enlaces en actividades resumidas porque la lógica puede ser difícil de seguir. Además, es difícil
identificar las tareas específicas que impulsan la ruta crítica. El uso de enlaces en actividades de resumen puede producir errores lógicos y crear
una lógica circular dentro del modelo de cronograma. Es una buena práctica evitar el uso de enlaces en actividades de resumen.
3.4.10 PROGRAMAR ANÁLISIS DE RECURSOS
Un buen modelo de horario contiene actividades/elementos de trabajo que se establecen con una cuidadosa consideración para
los recursos que serán necesarios para llevar a cabo el esfuerzo. Estos recursos pueden incluir varios tipos de recursos humanos (por ejemplo,
programadores, escritores, obreros, soldadores, herreros, albañiles, carpinteros, etc.). Los recursos también pueden incluir necesidades de equipos
críticos (p. ej., grúas, impresoras, camiones, etc.).
Una vez que se identifican los recursos, los valores de productividad, la escasez/disponibilidad de esos tipos de recursos y las interfaces con
otros tipos de recursos pueden convertirse en un factor en la duración de las actividades. La duración de las actividades tiene una relación integral
con la duración del proyecto, así como con el costo.
El software existente a menudo permite ajustar el proyecto en función de la disponibilidad de uno o más recursos definidos.
Esto se llama nivelación de recursos. Este esfuerzo de nivelación aborda la cantidad de recursos que pueden estar disponibles durante cualquier
período de tiempo. Las duraciones y los plazos de las actividades del cronograma se pueden ajustar según los umbrales de recursos predefinidos
(consulte la Figura 3-14). Tenga en cuenta que en este ejemplo, las actividades se han movido debido a la disponibilidad limitada de recursos y la
fecha de finalización de la cadena de actividades ahora es posterior. Generalmente, esto da como resultado proyectos de mayor duración o la
decisión de poner más recursos a disposición. Algunos productos de software cumplen esta función de nivelación dentro de los parámetros
asignados, pero no guardan el resultado. El programador y el personal del proyecto deben revisar el resultado del esfuerzo de nivelación y realizar
cambios específicos en la lógica del modelo del proyecto para guardar el resultado deseado.
3.4.11 PROGRAMAR EVALUACIÓN DE RIESGOS
El análisis de riesgos del cronograma se utiliza para establecer y validar las contingencias del cronograma, identificar los riesgos prioritarios y
los eventos relacionados con el riesgo, y monitorear continuamente los cambios en los riesgos relacionados con el proyecto. PERT no reconoce
que las rutas flotantes paralelas pueden contribuir al riesgo, especialmente en los puntos de fusión (también conocido como sesgo de fusión o
convergencia de rutas). Es demasiado complejo realizar un análisis profundo de este sesgo sin hacer una simulación como Monte Carlo, que
determina la magnitud del sesgo. Cuanto más grande y complejo es un proyecto, mayor es el impacto acumulativo del riesgo en el proyecto. Las
circunstancias que dictan la frecuencia, el rigor y el uso de la identificación y el análisis de los riesgos del cronograma se documentan en el plan
para la dirección del proyecto u otros documentos contractuales. Para obtener más información sobre los conceptos de riesgo, consulte la Guía del
PMBOK® y el Estándar para la gestión de riesgos en carteras, programas y proyectos [6].
83
Actividades antes de la nivelación de recursos
Tom: 8 horas
Actividad A Sue: 8 horas
comienzo
Actividad B Sue: 8 horas
Actividad C Tom: 8 horas
Día 1 Dia 2 Día 3
Tom: 8 horas Tom: 8 horas

Sue: 16 hrs
Actividades posteriores a la nivelación de recursos
Tom: 8 horas
Actividad A Sue: 8 horas
comienzo
Actividad B Sue: 8 horas
Actividad C Tom: 8 horas
Día 1 Dia 2 Día 3
Tom: 8 horas Sue: 8 horas Tom: 8 horas

Sue: 8 horas
Figura 3-14. Nivelación de recursos
La simulación de Monte Carlo considera la incertidumbre en la duración, el costo, los recursos, las relaciones y los riesgos, etc. de una
actividad. Utiliza los riesgos del registro de riesgos para impulsar la incertidumbre en la duración de la actividad. Alternativamente, las
duraciones pueden identificarse directamente como estimaciones optimistas, más probables y pesimistas para las actividades. A cada actividad
se le puede asignar una distribución de probabilidad, que considera el nivel de confianza que los interesados tienen en las estimaciones. A
cada actividad se le puede asignar una distribución de probabilidad, la cual considera el nivel de confianza que tienen los stakeholders en las
estimaciones. Cuando hay más confianza en la estimación, se selecciona una distribución de probabilidad con una desviación estándar menor
y viceversa. Se requiere expresar adelantos o retrasos como actividades discretas cuando el software de simulación de Monte Carlo no
permite la asignación de la incertidumbre de duración a un adelanto/retraso.
84 Seccion 3
Después de asignar estimaciones y distribuciones de probabilidad, se ejecuta la simulación de Monte Carlo. Una simulación se compone de
muchas iteraciones, cada una de las cuales representa un posible resultado del proyecto. Para cada iteración, las duraciones (también los costos
resultantes, etc.) son seleccionadas por el software de simulación Monte Carlo para que sean consistentes con las distribuciones de probabilidad
y los tipos de actividad especificados por el equipo del proyecto. Esto produce una instancia de modelo de programación registrada con atributos
para la ruta crítica, la duración y el costo. Luego, este proceso se repite varias veces, lo que da como resultado una distribución de probabilidad
de duración, costo, fechas de inicio y fechas de finalización para cada actividad seleccionada y, en última instancia, el proyecto.
Un análisis más profundo puede determinar la frecuencia de actividades específicas que caen en la ruta crítica y la identidad de los riesgos
más influyentes para impulsar los resultados al nivel deseado de certeza. Para aumentar la probabilidad de que el proyecto se complete a tiempo,
las actividades que se encuentran con mayor frecuencia en la ruta crítica y aquellas que tienen riesgos de alta prioridad se pueden monitorear de
cerca. Se utiliza un software de aplicación especial para completar la simulación de Monte Carlo.
Fecha: 30/5/2019 5:41:32 a. m. Desviación estándar de finalización: 1,19

Muestras: 1,000 días Intervalo de confianza del 95 %: 0,07
Identificación única: 0 días Cada barra representa 1 día
Nombre: Actividad #1
Tabla de probabilidad de finalización
0.35 1.0
Fecha de prueba Fecha de prueba
0.9
0.30 0,05 9/6/2019 0,55 11/6/2019
0.8
0,10 9/6/2019 0,60 11/6/2019
Frecuencia
0.25 0.7
0,15 9/6/2019 0,65 11/6/2019
0.6
0.20 0,20 10/6/2019 0,70 11/6/2019
0.5 Probabilidad
acumulada
0,25 10/6/2019 0,75 14/6/2019

0.15 0.4
0,30 10/6/2019 0,80 14/6/2019
0.10 0.3
0,35 10/6/2019 0,85 14/6/2019
0.2
0,40 10/6/2019 0,90 14/6/2019
0.05
0.1
0,45 11/6/2019 0,95 15/6/2019
0,50 11/6/2019 1,00 16/6/2019

7/6/2019 11/06/2019 16/06/2019
Fecha de Terminación
Figura 3-15. Ejemplo de distribución de probabilidad de duración para una sola actividad
3.4.12 HORARIO GANADO
La gestión del cronograma ganado (ESM) es un método para calcular las variaciones del cronograma, el rendimiento y los resultados probables
dado el rendimiento actual. Mientras que la gestión del valor ganado (EVM) utiliza ecuaciones y análisis basados en costos, ESM está asociado
con el análisis basado en el tiempo. ESM trabaja con EVM para brindarle al gerente del proyecto una comprensión precisa del tiempo y el costo
de su proyecto durante la etapa de ejecución. Mientras que EVM calcula la variación del horario y el rendimiento del horario
85
índices utilizando entradas denominadas en dinero (valor ganado y valor planificado), ESM calcula la variación del cronograma y los
índices de desempeño del cronograma usando entradas denominadas en tiempo (calendario ganado y tiempo real). Esto permite a los
analistas del cronograma calcular un indicador preciso del desempeño del cronograma y hacer estimaciones más precisas de los
tiempos de finalización esperados dado el desempeño actual del proyecto. El cronograma ganado (ES) aprovecha los conceptos de
valor ganado (EV) para obtener una mejor comprensión de la dimensión temporal de un proyecto. En primer lugar, se observa EV a
partir del momento de la comparación, que se denomina tiempo real (AT). Luego, AT se compara con el punto específico en el tiempo
en el cronograma (en el futuro o en el pasado) en el que se planeó ganar la cantidad actual de EV. Ese punto en el tiempo es el programa ganado (ES).
Restar AT de ES da una variación de tiempo real del cronograma versus real, la variación del cronograma (SV). Dividir AT en ES da un
verdadero índice de rendimiento de programación basado en el tiempo (SPI(t)). Con este método de observación y análisis del
cronograma, las técnicas de control de proyectos se pueden usar junto con las metodologías de valor ganado existentes.
El cronograma ganado es una extensión del concepto de valor ganado (EV) y actúa como otra técnica de control de proyectos que
se utilizará junto con las metodologías de valor ganado existentes. El concepto básico del cronograma ganado es identificar el momento
en el que se debería haber ganado una cantidad específica de valor ganado (EV) de acuerdo con el cronograma.
El desarrollo más importante en el cronograma ganado es la capacidad de determinar con mayor precisión la fecha de finalización
de los proyectos. El cronograma ganado usa datos de desempeño EV para generar la información basada en el tiempo y usa cálculos
similares para predecir el desempeño futuro (vea la Figura 3-16). Por lo tanto, el horario ganado es una traducción simple del
1 2 7
3 4
5
8
BAC
6
fotovoltaica
ps
VE
SV(t)
ES A PD
Tiempo
Figura 3-16. Relación entre ES, PV y EV
86 Seccion 3
unidades de tiempo que deberían haberse ganado en el cronograma de referencia en este punto en el tiempo en comparación con lo que
realmente ocurrió. La métrica del cronograma ganado mide el progreso del proyecto en una dimensión de tiempo y varía entre 0 unidades de
tiempo (al comienzo del proyecto) y la duración total planificada del proyecto de referencia, X unidades de tiempo (al finalizar el proyecto). El
valor planificado es una línea de base presupuestaria con fases de tiempo que resulta directamente del cronograma de línea de base, traducido
en términos monetarios. Además, cuando se utilizan los principios de EVM, se supone que las medidas de desempeño de costos y tiempo del
proyecto son una indicación representativa del desempeño futuro del proyecto, y se pueden usar para pronosticar la duración y el costo finales del proyecto.
El cronograma ganado se puede usar para desglosar la estructura de desglose del trabajo (WBS) del proyecto de la misma manera que se
usa el valor ganado. Al hacer esto, el planificador identifica dónde pueden existir deficiencias o restricciones y dónde puede ser necesario un
retrabajo en el futuro.
Otro beneficio clave de usar el cronograma ganado es su capacidad para identificar cuándo las actividades previstas del proyecto no se
están realizando en la secuencia adecuada (cumplimiento de la lógica y la secuencia de cronograma adecuadas). Realizar el trabajo fuera de
secuencia es un problema crítico del proyecto porque apunta a problemas de rendimiento que el proyecto puede estar experimentando. Por
ejemplo, EVM permite acumular y obtener las métricas del proyecto de manera acumulativa, incluso cuando los valores acumulados o ganados
son el resultado de actividades de trabajo adelantadas a lo programado y fuera de secuencia. Las métricas resultantes implican para las partes
interesadas del proyecto que el valor acumulado acumulado se alinea con el valor acumulado planificado para el proyecto.
Desafortunadamente, las métricas sugieren que el rendimiento va bien cuando a menudo no es así. Consulte la Figura 3-17.
Proyecto
Presupuesto
US $ 8 millones
US $ 5 millones
Actual
Planificado
Costo (CA)
Valor (VP) US $ 4 millones
Trabajar
Listo (VE)
6 meses 10 meses
18 meses
Duración planificada (PD)
Hora real (AT)
Calendario Ganado (ES)
Figura 3-17. Informes de horarios ganados
87
Realizar el trabajo fuera de secuencia da como resultado que ciertas tareas comiencen antes de tiempo y se reivindique algún valor (a menudo
usando una técnica de medición diferente) para mantener las cifras saludables. Los profesionales a veces usan esta técnica cuando los paquetes de
trabajo no ganan valor al ritmo que deberían. Al iniciar otro paquete de trabajo antes de lo previsto, la organización puede reclamar un valor adicional. El
método de programa ganado debería proporcionar una mejor integridad a este proceso de informes.
Las fórmulas utilizadas en el programa ganado se muestran a continuación en la Tabla 3-1.
Tabla 3-1. Fórmulas de horario ganado
Escribe Nombre Abreviatura Ecuación
ES = C + yo
Calendario ganado escum número de períodos completos (C)

Métrica más una porción incompleta (I)
Tiempo actual A semen AT = número de períodos ejecutados
Variación de horario SV(t) SV(t) = ES – EN
% de variación del programa VS(t)% SV(t)% = (ES – AT) / ES
Indicadores
Índice de rendimiento del horario (tiempo) Escupir) SPI(t) = ES / EN
TSPI = (PD – ES) / (PD – AT)

Para completar el índice de rendimiento TSPI
TSPI = (PD – ES) / (ED – AT)
IEAC(t) = PD / SPI(t)
Estimación independiente al finalizar (tiempo)
IEAC(t)
predictores IEAC(t) = AT + (PD – ES) / PF(t)
Variación al finalizar VCA(t) VCA(t) = PD – IEAC(t) o ED
3.5 COMUNICACIÓN E INFORMES
Una comunicación clara genera credibilidad con las partes interesadas. El director del proyecto, junto con el equipo del proyecto, debe identificar a
las partes interesadas y sus necesidades de información y crear un plan de gestión de las comunicaciones (consulte la Guía del PMBOK®) al principio
del ciclo de vida del proyecto para cumplir con las expectativas identificadas de las partes interesadas clave.
88 Seccion 3
El modelo de cronograma es un elemento estratégico en el conjunto de herramientas de un gerente de proyecto para guiar un proyecto con éxito hasta
la fecha de finalización prevista. Un modelo de cronograma proporciona un cronograma de lo que se logrará y cuándo, al reflejar las actividades del
proyecto con fechas de inicio y finalización. Un modelo de cronograma se puede superponer con diferentes detalles para:
u Permita que los gerentes de proyecto dirijan y administren los recursos de manera más fluida,
u Controlar la evolución del proyecto día a día,
u Proporcionar visibilidad para permitir que el director del proyecto supere las amenazas y aproveche las oportunidades para el
proyecto,
u Comunicarse con mayor frecuencia y eficacia con las partes interesadas, y
u Identifique y controle las dependencias y restricciones entre las tareas para minimizar el impacto de los problemas prevenibles.
retrasos en el proyecto.
La instancia del modelo de cronograma puede producir múltiples formatos de informe según la etapa de desarrollo del
proyecto, informes requeridos por el proyecto y el usuario principal. Los informes de programación pueden incluir:
u Informes de ruta crítica,
u Informes WBS,
u Horarios detallados semanales y/o mensuales,
u Informes de recursos,
u Informes de supuestos,
u Informes de dependencias,
u Informes de temas críticos,
u Programar informes de riesgo,
u Informes de progreso, y
u Informes de cantidad, etc.
89
Además, los clientes pueden requerir varios niveles de presentaciones de instancias del modelo de cronograma. La Tabla 3-2
refleja los distintos niveles del proyecto. La Figura 3-18 refleja el contenido típico de los informes utilizados en estos niveles. Para
obtener más información, consulte la Sección 3.2.1.9, donde se analizan con mayor detalle los distintos tipos de niveles de cronograma,
y la Sección 4, donde se describe el nivel del modelo de cronograma de componentes. En la Figura 3-18 se muestran algunos informes
de ejemplo para varios niveles.
Tabla 3-2. Niveles de presentaciones de instancias de modelo de programación
Nivel Recipiente Contenido Ejemplo

0 Socios Estratégicos, Altos Ejecutivos, Resumen de todo el proyecto en una sola línea Una sola línea que representa información sobre este
Gerente de Portafolio/Programa (empezar y terminar) proyecto para compararlo con otros proyectos en la
cartera
1 Dirección Ejecutiva y Patrocinador Solo información clave Fechas de inicio y finalización del proyecto y costo
2 Gestión de Proyectos y Equipo de Proyecto Hitos clave del proyecto Progreso de todos los hitos del proyecto
3 Coordinadores de Proyectos Resumen de tareas Necesita proporcionar información suficiente para

definir el alcance del trabajo del proyecto para
cada grupo, controlar el progreso y pronosticar los
entregables
4 Administradores de paquetes de trabajo o contrato Información detallada por cada paquete de Similar al nivel 3, excepto que los datos están
Gerentes trabajo segregados por paquete de trabajo del contrato
5 Líderes de tareas Información detallada por tarea Datos detallados del cronograma del proyecto
90 Seccion 3
Calendario de hitos
Plazo del cronograma del proyecto

Actividad Calendario
Descripción de la actividad
identificador Unidades Periodo 1 Período 2 Período 3 Período 4 Período 5
1.1 MB Comenzar nuevo producto Z 0
1.1.1.M1 Componente completo 1 0
1.1.3.M1 Integración completa de los componentes 1 y 2 0
1.1.3.MF Terminar Nuevo Producto Z 0
Fecha de Datos
Horario resumido
Plazo del cronograma del proyecto

Actividad Calendario
Descripción de la actividad
identificador Unidades
Periodo 1 Período 2 Período 3 Período 4 Período 5
1.1 Desarrollar y entregar nuevos productos Z 120
1.1.1 Paquete de Trabajo 1: Componente 1 67
1.1.3 Paquete de Trabajo 3: Componentes Integrados 1 y 2 53
Fecha de Datos
Calendario detallado
Calendario Plazo del cronograma del proyecto

Actividad
identificador Descripción de la actividad Unidades
Periodo 1 Período 2 Período 3 Período 4 Período 5
1.1 MB Comenzar nuevo producto Z 0
1.1 Desarrollar y entregar el Producto Z 120
1.1.1.D Componente de diseño 1 20

FS
1.1.1.B Componente de construcción 1 33
1.1.1.T Componente de prueba 1 14

SS
1.1.2.D Componente de diseño 2 14
1.1.2.B Componente de construcción 2 28
1.1.2.T Componente de prueba 2 11
1.1.3 Paquete de Trabajo 3: Componentes Integrados 1 y 2 53
1.1.3.G Integrar los Componentes 1 y 2 como Producto Z 14
1.1.3.T Integración Completa de los Componentes 1 y 2 32
1.1.3.M1 Probar componentes integrados como producto Z 0
1.1.3.P Entregar Producto Z 7
1.1.3.MF Terminar Nuevo Producto Z 0
Fecha de Datos
Figura 3-18. Ejemplos de presentaciones del cronograma del proyecto
91
COMPONENTES DE PROGRAMACIÓN
Esta sección proporciona un catálogo detallado de los componentes potenciales de una herramienta de programación de CPM. Cada entrada incluye
ocho tipos posibles de información relacionada con el componente e indica si este estándar de práctica considera que el componente es obligatorio,
condicional u opcional. Los componentes necesarios se dividen en cuatro grupos:
u Componentes básicos necesarios (CRC, que se muestra como "R" en la Tabla 4-1),
u Componentes de recursos requeridos (RRC),
u Componentes requeridos por EVM (ERC), y
u Componentes requeridos por el riesgo (KRC).
Los requisitos del proyecto determinan qué componentes necesarios deben estar presentes en un modelo de cronograma antes de que se pueda
realizar una evaluación de madurez. La evaluación de la madurez y el índice de conformidad se explican en detalle en la Sección 5. Esta sección está
organizada de la siguiente manera:
4.1 Cómo utilizar la lista de componentes. En esta sección se define el tipo de información que se puede mostrar para cada componente.
4.2 Lista de Componentes por Categoría. Esta sección muestra un desglose de los componentes dentro de una categoría específica. Esta información
facilitará la localización de un componente específico. Cada componente se identifica como requerido, condicional u opcional.
4.3 Lista detallada de componentes. Esta sección enumera cada componente del cronograma y sus tipos de información asociados.
en orden alfabético.
93
4.1 CÓMO UTILIZAR LA LISTA DE COMPONENTES
El diseño de una entrada de componente típica se muestra a continuación. Las secciones 4.1.1 a 4.1.8 definen el contenido de cada
elemento de datos dentro del elemento componente.
Nombre del componente Uso obligatorio, condicional u opcional Manual o Calculado
Formato de datos:
Comportamiento:
Buenas practicas:
Nota condicional/componente asociado:
Definición:
4.1.1 NOMBRE DEL COMPONENTE
Este elemento de datos contiene el nombre del componente, que puede diferir dentro de varias herramientas.
4.1.2 USO OBLIGATORIO, CONDICIONAL U OPCIONAL
Este elemento de datos indica si el uso de un componente es: (a) requerido para cualquier modelo de cronograma (CRC); (b) requerido
condicionalmente (RRC, ERC, KRC), basado en el estado o acción de otro componente o proceso; o (c) opcional (puntuado o no puntuado).
4.1.3 MANUAL O CALCULADO
Este elemento de datos indica si los datos dentro del componente son ingresados manualmente o calculados por el
herramienta de programación. La configuración del atributo manual/calculado puede depender de la herramienta de programación.
94 Sección 4
4.1.4 FORMATO DE DATOS
Este elemento de datos describe cómo se formatean los datos dentro del componente como parte de la herramienta de programación. El formato de los
datos puede variar entre las herramientas de programación.
4.1.5 COMPORTAMIENTO
En la lista de componentes, este elemento de datos describe cómo reacciona el componente y/o habilita la reacción dentro de la herramienta de
programación. Es importante tener en cuenta que, por lo general, las descripciones de comportamiento comienzan con un verbo que indica la acción.
El comportamiento real de un componente puede variar entre herramientas de programación o configuraciones dentro de la misma herramienta.
4.1.6 BUENAS PRÁCTICAS
En esta lista, buenas prácticas significa que existe un acuerdo general de que, cuando se aplica junto con el componente mencionado, la aplicación correcta
de habilidades, herramientas y técnicas puede mejorar las posibilidades de éxito en una amplia gama de proyectos diferentes. Las buenas prácticas no
significan que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos. El equipo de gestión del proyecto es responsable
de determinar lo que es apropiado para cualquier proyecto dado.
4.1.7 NOTA CONDICIONAL/COMPONENTE ASOCIADO
Este elemento de datos indica si un componente está relacionado con otro componente o con cualquier nota importante.
eso debe ser considerado.
4.1.8 DEFINICIÓN
Este elemento de datos describe el uso general y la función del componente dentro de la herramienta de programación. La definición
proporcionada es la misma que se proporciona en el Glosario, cuando corresponda.
95
4.2 LISTA DE COMPONENTES POR CATEGORÍA
Esta sección contiene una lista de los componentes organizados por categorías. La columna de uso identifica si un componente es:
u Componente básico requerido (R);
u Componente de recursos requeridos (RRC);
u Componente requerido por EVM (ERC);
u Componente de riesgo requerido (KRC);
u Componente opcional (O); o
u Componente sin puntuar (NS).
Todos los componentes requeridos deben estar presentes para lograr un puntaje en el proceso de evaluación de madurez descrito
con mayor detalle en la Sección 5.
96 Sección 4
Tabla 4-1. Lista de componentes por categoría
Categoría Componente Categoría de uso Componente Usar
CALENDARIO Calendario de actividades O RELACIÓN Final a Final O
Calendario del proyecto R Terminar para comenzar R
Calendario de recursos CRR Empezar a acabar NS
RESTRICCIÓN Lo más tarde posible NS Comienzo a Comienzo O
Lo antes posible NS
RECURSO Actividad Esfuerzo O
Final esperado NS
Actividad Recurso Cantidad real CRR
Terminar no antes de NS
Actividad Recurso Cantidad restante CRR
Terminar no más tarde de NS
Actividad Recurso Cantidad total CRR
Terminar en NS
Recurso de conducción O
Fecha de finalización obligatoria NS
Cantidad real del recurso del proyecto CRR
Fecha de inicio obligatoria NS
Cantidad restante de recursos del proyecto CRR
Restricción de finalización del proyecto O
Cantidad total de recursos del proyecto CRR
Restricción de inicio del proyecto O
Asignación de recursos CRR

Empezar no antes de NS
Disponibilidad de recursos CRR

Empezar no más tarde de NS
Descripción del recurso CRR

Comienza en NS
DURACIÓN R ID de recurso CRR

Actividad Duración real
R Retraso de recursos O
Actividad Duración original
Duración restante de la actividad R Biblioteca de recursos/Diccionario CRR
Actividad Duración total R Tarifas/precios de recursos O
Duración real del proyecto R CRR

Tipo de recurso
Duración restante del proyecto R KRC

RIESGO DEL PROGRAMA Distribución de riesgo de probabilidad acumulada de actividad
Duración total del proyecto R KRC

Actividad Duración más probable
VALOR AGREGADO Costo real de la actividad ERC
Actividad Optimista Duración KRC
Hora real (AT) O

Actividad Pesimista Duración KRC
Presupuesto al finalizar (BAC) ERC

Índice de Criticidad del Riesgo de Actividad KRC
Identificador de solicitud de cambio O

Distribución de riesgo de probabilidad KRC
ID de cuenta de control ERC
Identificación de riesgo KRC
Gerente de Cuentas de Control (CAM) O
FECHA DE INICIO Actividad Fecha de inicio real R
Índice de rendimiento de costos (IPC) O
Actividad Fecha de inicio temprano R
Variación de costo (CV) O
Actividad Fecha de inicio tardío R

% de variación del costo (CV%) O
Actividad Nivel de recursos Fecha de inicio O

Calendario Ganado (ES) O
Fecha de inicio real del proyecto R

Valor ganado (EV) ERC
Fecha de inicio anticipado del proyecto R

Tipo de medición de valor ganado O
O Fecha de inicio tardío del proyecto R

Peso del valor ganado
Estimación al finalizar (EAC) ERC Fecha de inicio nivelada de recursos del proyecto O
Duración estimada (ED) O MISCELÁNEAS Código de actividad O
Estimación para completar (ETC) ERC Categoría de costo de actividad O
Tiempo estimado para competir (ETC(t)) O O

Estimación del costo de la actividad
Identificador de paquete de trabajo de EVMS ERC R

ID de actividad
Valor planificado ERC
R
Etiqueta de actividad
Índice de rendimiento del cronograma (SPI) O

Actividad Nota / Comentario / Registro O
Tiempo de índice de rendimiento de programación (SPI(t)) O

Definición del alcance de la actividad O
Variación de horario (SV) O

Modelo de cronograma de línea base R
% de variación de horario (SV%) O
Camino critico R
Horario de variación de tiempo (SV(t)) O
Fecha de Datos R
Para completar el índice de rendimiento (TCPI) O
Hamaca O
Para completar el índice de rendimiento del cronograma (TSPI) O
Retraso
O
ID de la EDT ERC
Guiar NS
FECHA DE FINALIZACIÓN Actividad Fecha de finalización real R
Actividad de nivel de esfuerzo (LOE) O

Fecha de finalización anticipada de la actividad R
Hitos R
Actividad Fecha de finalización tardía R
O Categoría de costo del proyecto O

Fecha de finalización nivelada por recursos de actividad
R Descripción del Proyecto O

Fecha de finalización real del proyecto
Fecha de finalización anticipada del proyecto R Nombre del proyecto R
Fecha de finalización tardía del proyecto R Programar ID de modelo R
Fecha de finalización nivelada por recursos del proyecto O Programar instancia de modelo R
FLOTAR flotación libre R Programar nivel de modelo O
Flotación total R
Programación Modelo Presentación R
POR CIENTO Actividad Física % Completado O

R Resumen de actividad O
COMPLETO Actividad Duración % Completado
Modelo de cronograma objetivo O
Actividad Trabajo Porcentaje completado O
Unidad de medida R
Proyecto Físico % Completo O
R
Proyecto Duración % Completado Diferencia O
97
4.3 LISTA DE COMPONENTES DETALLADA
Esta sección identifica los componentes individuales y los ocho tipos de información definidos para cada componente. Está
organizado alfabéticamente.
Costo real de la actividad (AC) Obligatorio (ERC) Calculado/Manual
Formato de datos: Numérico
Comportamiento: Medida de coste.
Buenas Prácticas: Incluye el costo real cuando se utiliza la metodología de valor ganado en el cronograma.
Nota Condicional/Componente Asociado: Ver El Estándar para la Gestión del Valor Ganado [5]. Este término también se conoce como costo real del trabajo
realizado (ACWP). Este estándar reconoce que AC puede estar disponible solo en niveles resumidos de actividades y no para cada actividad discreta en el modelo de
cronograma.
Definición: El costo total del trabajo completado durante un período de tiempo determinado. Este valor se puede calcular en cualquier nivel de esquema del modelo de
cronograma y entre varias fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los valores se denominan
acumulativos. El costo real también puede incluir costos monetarios de materiales y otros costos fijos.
Actividad Duración real Requerido Calculado/Manual
Comportamiento: Define el tiempo que ha transcurrido desde que comenzó la actividad. La unidad de medida puede ser el tiempo transcurrido o el tiempo de trabajo.
Buenas practicas:
Definición: El número total de períodos de trabajo en unidades de calendario entre la fecha de inicio real de la actividad del cronograma y la fecha de datos del modelo del
cronograma (si la actividad del cronograma está en curso) o la fecha de finalización real de la actividad (si la actividad del cronograma está completa) .
Actividad Fecha de finalización real Requerido Manual
Formato de datos: Fecha
Comportamiento: Define la fecha en que se completó la actividad.
Buenas prácticas: todas las actividades con finalización anterior a la fecha de los datos deben tener fechas de finalización reales asignadas. Las fechas reales reemplazan las fechas
tempranas y tardías de CPM. Especifica que la actividad está completa al 100%.
Nota condicional/componente asociado: duración de la actividad porcentaje completado/actividad física porcentaje completado
Definición: El punto en el tiempo en el que se completó una actividad programada.
98 Sección 4
Actividad Fecha de inicio real Requerido Manual
Comportamiento: Define la fecha en que se inició el progreso en una actividad.
Buenas prácticas: todas las actividades con inicios anteriores a la fecha de los datos deben tener fechas de inicio reales asignadas. Las fechas reales reemplazan al CPM antes
y fechas tardías.
Nota condicional/componente asociado: el progreso debe haberse iniciado antes de la fecha actual de los datos.
Definición: El punto en el tiempo en el que comenzó una actividad del cronograma.
Calendario de actividades Opcional Manual
Formato de datos: Fecha/hora
Comportamiento: Define los periodos de trabajo de la actividad. El calendario de actividades anula el calendario del proyecto para aquellas actividades a las que
Está aplicado.
Buenas practicas:
Definición: Un calendario de periodos laborables y no laborables asignados a la actividad del cronograma, que define los periodos laborables y los periodos no laborables en formato de
calendario. El calendario de actividades, en las actividades del cronograma a las que está asignado, se usa para reemplazar el calendario del proyecto para los cálculos del cronograma. Véase
también calendario de proyectos y calendario de recursos.
Código de actividad Opcional Manual/Calculado
Formato de datos: Alfanumérico
Comportamiento: Almacena uno o más valores específicos que podrían asignarse a cada actividad dentro del modelo de cronograma. Pueden existir múltiples códigos para cada actividad y
pueden usar cualquiera de los tipos de atributos: alfa, alfanumérico, fecha, hora, etc.
Buenas prácticas: los códigos de actividad se utilizan para facilitar la clasificación, organización, resumen y agrupación en las presentaciones del modelo de cronograma.
Definición: Valores que identifican características del trabajo o de alguna manera categorizan la actividad del cronograma que permite agrupar, filtrar y ordenar actividades de la
manera que mejor represente un grupo de actividades. En algunos software de programación, los campos personalizados se utilizan para contener
esta informacion.
99
Categoría de costo de actividad Opcional Manual
Comportamiento: proporciona desgloses adicionales que se pueden asignar a una cuenta de costos específica dentro del proyecto.
Buenas prácticas: A efectos contables, los costos deben desglosarse en categorías, como directos, indirectos, mano de obra, materiales,
equipo, etc
Definición: Un desglose del costo, como costo de mano de obra, costo de equipo y costo de material.
Estimación del costo de la actividad Opcional Manual/Calculado
Comportamiento: Derivado al sumar todas las categorías de costos de actividades individuales. Puede incluir costos adicionales a los incluidos en el valor planificado (PV).
Buenas prácticas: Los costos de actividad deben calcularse sumando las categorías de costos de actividad individuales que se han asignado a la actividad.
Nota condicional/componente asociado: categoría de costo de actividad, valor planificado
Definición: El costo proyectado de la actividad del cronograma, que incluye el costo de todos los recursos necesarios para realizar y completar la actividad, incluidos todos los tipos y
categorías de costos.
Probabilidad acumulativa de actividad
Distribución de riesgos Requerido (KRC) Manual
Formato de datos: Tabla de fechas, numérica (fraccional)
Comportamiento: almacena los resultados del método utilizado para cuantificar la incertidumbre en función de la función de distribución de probabilidad elegida que representa el riesgo de
duraciones de la actividad.
Buenas prácticas: el proceso de análisis de riesgos debe usarse para proyectos en los que las variaciones del cronograma podrían tener un impacto significativo en el proyecto.
objetivos
Definición: Una tabla de fechas y sus probabilidades acumuladas de ocurrencia asociadas para la finalización de la actividad del cronograma. Las fechas se derivan utilizando técnicas
analíticas como los cálculos de Monte Carlo. Cuando se aplica a la fecha de finalización del proyecto, el valor es equivalente al del proyecto
distribución de riesgo de probabilidad acumulada.
100 Sección 4
Actividad Duración Porcentaje completado Obligatorio (ver nota condicional) Calculado/Manual
Formato de datos: Numérico (fraccional)
Comportamiento: representa la proporción de la duración real como porcentaje de la duración total esperada de la actividad completada en un punto dado
a tiempo.
Buenas prácticas: En ausencia de una gestión del valor ganado, el porcentaje de duración completo puede usarse como una indicación del progreso de la actividad.
Sin embargo, los usuarios deben reconocer que esta es una aproximación muy aproximada del verdadero progreso, y se desaconseja su uso en lugar de EVM. Es el porcentaje completo del
lapso de la actividad sin relación con la cantidad de esfuerzo de trabajo para la actividad.
Nota condicional/componente asociado: se debe usar el porcentaje completo de duración de la actividad o el porcentaje completo de actividad física.
(Ver actividad física por ciento completado.)
Definición: El porcentaje calculado que la duración real de la actividad es de la duración total de la actividad para una actividad programada que tiene trabajo
en progreso.
Fecha de finalización anticipada de la actividad Requerido Calculado
Comportamiento: identifica la fecha de finalización anticipada de la actividad, según el pase de avance de CPM.
Buenas prácticas: la fecha se derivará de los cálculos de CPM.
Definición: El momento más temprano posible en el que la parte incompleta de la actividad del cronograma se puede completar en función de la lógica del modelo de avance del cronograma
de CPM.
Actividad Fecha de inicio temprano Requerido Calculado
Comportamiento: define el inicio anticipado de la actividad, en función del pase de avance de CPM.
Buenas Prácticas: Derivadas de los cálculos del análisis de la red del cronograma.
Nota condicional/componente asociado: Comienzo anticipado, duración
Definición: el momento más temprano posible en el que la actividad del cronograma puede comenzar en función de la lógica del modelo de avance del cronograma de CPM.
Actividad Esfuerzo Opcional Calculado/Manual
Comportamiento: Cuantifica el esfuerzo requerido para una actividad. También conocido como trabajo de actividad.
Buenas Prácticas: Los recursos deben ser identificados y asignados.
Nota condicional/componente asociado: depende de la duración de la actividad y la asignación de recursos.
Definición: El número de unidades necesarias para completar una actividad del cronograma o un componente de la estructura de desglose del trabajo. El esfuerzo de actividad generalmente
se expresa como horas de personal, días de personal o semanas de personal. No es lo mismo que duración.
101
ID de actividad Requerido Calculado
Comportamiento: Identifica la actividad del cronograma.
Buenas Prácticas: Un identificador único que se puede generar automáticamente o sigue un esquema de numeración apropiado para el proyecto. Muchos
los proyectos asignan una estructura o codificación razonada al ID de la actividad.
Definición: Una identificación breve, numérica o de texto única asignada a cada actividad del cronograma para diferenciar esa actividad del proyecto de otras
actividades.
Etiqueta de actividad Requerido Manual
Comportamiento: Permite registrar información definida por el usuario sobre la actividad.
Buenas prácticas: frase o etiqueta que comienza con un verbo y un sujeto único y específico (sustantivo/adjetivo).
Definición: Una frase corta o etiqueta para cada actividad del cronograma que se usa junto con un identificador de actividad para diferenciar esa actividad del modelo de cronograma de
otras actividades del cronograma. La etiqueta de actividad normalmente describe el alcance del trabajo de la actividad del cronograma. También conocido como descripción de la actividad,
nombre de la actividad y nombre de la tarea.
Actividad Fecha de finalización tardía Requerido Calculado
Comportamiento: identifica el final tardío de la actividad en función del paso hacia atrás de CPM.
Buenas Prácticas: Derivadas de los cálculos de CPM.
Definición: El último punto posible en el tiempo cuando la actividad del cronograma se puede completar sin violar una restricción de cronograma o retrasar
la fecha de finalización del proyecto.
Actividad Fecha de inicio tardío Requerido Calculado
Comportamiento: Define el inicio tardío de la actividad, en base al pase hacia atrás.
Definición: El último momento posible en el que la actividad del cronograma puede comenzar sin violar una restricción del cronograma o retrasar la fecha de finalización del proyecto.
102 Sección 4
Actividad Duración más probable Requerido (KRC) Calculado/Manual
Comportamiento: identifica el tiempo asignado para completar la actividad del cronograma asumiendo condiciones normales. Los riesgos sólo se calculan sobre duraciones restantes.
Buenas prácticas: las duraciones más probables deben usarse para los cálculos de riesgo de cronograma.
Nota condicional/componente asociado: duración optimista de la actividad, duración pesimista de la actividad, duración original de la actividad (si se realiza un análisis de riesgo)
Definición: El número total de períodos de trabajo en unidades de calendario asignados para realizar la actividad del cronograma, considerando todas las variables que puedan afectar
el desempeño; se determina que es la duración más probable de la actividad.
Actividad Nota/Comentario/Registro Opcional Manual
Comportamiento: registra cualquier información complementaria para una actividad.
Buenas prácticas: documentación adicional sobre una actividad sobre por qué se creó, retrasó, restringió, etc.
Definición: Documentación de información adicional de apoyo a la actividad.
Actividad Optimista Duración Requerido (KRC) Calculado/Manual
Comportamiento: Identifica el tiempo asignado para completar la actividad del cronograma asumiendo las mejores condiciones posibles. Los riesgos son sólo
calculada sobre duraciones restantes.
Buenas prácticas: se deben utilizar duraciones optimistas para los cálculos de riesgo de cronograma.
Nota condicional/componente asociado: duración pesimista de la actividad, duración más probable de la actividad, duración original de la actividad (si realiza
análisis de riesgo)
Definición: El número total de períodos de trabajo en unidades de calendario asignados para realizar la actividad del cronograma, considerando todas las variables que puedan afectar
el desempeño; se determina que es la duración de actividad más corta posible.
103
Actividad Duración original Requerido Manual
Comportamiento: define el período de tiempo asignado para completar la actividad programada antes de informar cualquier progreso en la actividad. La
implementación de la duración original de la actividad depende de la herramienta de programación.
Buenas prácticas: se debe mantener un registro de cómo se determinó la duración para futuras referencias y revisiones. Generalmente, las duraciones no deben exceder
dos o tres ciclos de informes.
Definición: La duración de la actividad asignada originalmente a una actividad del cronograma; esta duración normalmente no se actualiza a medida que se informa sobre
el progreso de la actividad. Se utiliza para comparar la duración real de la actividad y la duración restante de la actividad cuando se informa sobre el progreso del cronograma.
La duración original de la actividad normalmente se desarrolla basándose en datos históricos, especialistas, disponibilidad de recursos, consideraciones financieras y volumen
de trabajo a realizar.
Actividad Pesimista Duración Requerido (KRC) Calculado/Manual
Comportamiento: identifica el tiempo asignado para completar la actividad del cronograma asumiendo las peores condiciones posibles. Los riesgos sólo se calculan sobre
duraciones restantes.
Buenas prácticas: se deben utilizar duraciones pesimistas para los cálculos de riesgo de cronograma.
Nota condicional/componente asociado: duración optimista de la actividad, duración más probable de la actividad, duración original de la actividad (si se realiza un análisis
de riesgo)
Definición: El número total de períodos de trabajo en unidades de calendario asignados para realizar la actividad del cronograma, considerando todas las variables que puedan
afectar el desempeño; se determina que es la duración de actividad más larga posible.
Actividad física Porcentaje completo Obligatorio (ver nota condicional) Manual
Comportamiento: representa la proporción del trabajo físico real completado como porcentaje del trabajo físico total esperado en un punto dado
a tiempo.
Buenas prácticas: para cualquier actividad iniciada, se debe actualizar el porcentaje físico completado. El programador del proyecto debe tomar una decisión al comienzo del
proyecto en cuanto a qué método se utilizará durante la duración del proyecto. Puede haber diferentes métodos para medir la integridad. Estos incluyen las reglas de ganancias
basadas en el valor ganado (consulte El estándar para la gestión del valor ganado [5]), como la regla 50/50, cantidades reales, porcentaje completado, no lineal por hito, etc.,
así como estimaciones de las personas que trabajan en el actividad. De estos métodos, la evaluación porcentual basada en EV se considera la mejor, ya que tiende a ser
menos subjetiva.
Nota condicional/componente asociado: se debe usar el porcentaje completo de duración de la actividad o el porcentaje completo de actividad física.
Requiere el uso de la técnica del valor ganado.
Definición: una estimación, expresada como porcentaje, de la cantidad de trabajo que se ha completado en una actividad del cronograma, medido en términos de progreso
de trabajo físico o mediante las reglas de obtención de la gestión del valor ganado.
104 Sección 4
Duración restante de la actividad Requerido Calculado/Manual
Comportamiento: define el tiempo necesario para completar la actividad a partir de la fecha de los datos.
Buenas Prácticas: Una vez que una actividad comienza pero no se completa durante un ciclo de reporte, se debe tomar una determinación en cuanto a la
tiempo que resta para completar la obra.
Nota condicional/componente asociado: las asignaciones de recursos pueden afectar la duración restante de la actividad.
Definición: El número total de períodos de trabajo en unidades de calendario, ya sea igual a la duración original de una actividad que no ha comenzado o entre la fecha de datos
del cronograma del proyecto y la fecha de finalización anticipada de CPM de una actividad del cronograma que tiene un inicio real de actividad fecha.
Esto representa el tiempo necesario para completar una actividad del cronograma donde el trabajo está en progreso. Nota: antes del inicio real, la duración restante de la actividad =
duración de la actividad.
Actividad Recurso Cantidad real Obligatorio (RRC) Manual/Calculado
Comportamiento: Medida de utilización de un recurso a nivel de actividad.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos, la cantidad real del recurso de actividad debe
ser usado.
Definición: La unidad para expresar la cantidad de un recurso utilizado para una actividad desde la fecha de inicio real de la actividad.
Fecha de finalización nivelada por recursos de actividad Opcional Calculado
Comportamiento: identifica la finalización más temprana de una actividad en función de las limitaciones de recursos.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos y existen sobreasignaciones de recursos, los recursos
se debe usar nivelación.
Definición: El punto en el tiempo asociado con la fecha de finalización programada de la actividad de una actividad del cronograma de recursos limitados en un recurso limitado.
calendario.
105
Actividad Nivel de recursos Fecha de inicio Opcional Manual
Comportamiento: identifica el inicio más temprano de una actividad en función de las limitaciones de recursos.
Definición: El punto en el tiempo asociado con la fecha de inicio programada de la actividad de una actividad del cronograma con recursos limitados en un cronograma con recursos limitados.
Actividad Recurso Cantidad restante Obligatorio (RRC) Manual/Calculado
Comportamiento: Medida de los recursos necesarios para completar una actividad a partir de la fecha de los datos.
Buenas prácticas: una vez que una actividad comienza pero no se completa durante un ciclo de presentación de informes, se debe determinar los recursos que aún se necesitan
para completar el trabajo.
Definición: La unidad para expresar los recursos necesarios para completar una actividad a partir de la fecha de los datos.
Actividad Recurso Cantidad total Obligatorio (RRC) Manual/Calculado
Comportamiento: Medida de los recursos necesarios para realizar una actividad. La cantidad es única por recurso por actividad.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos, se debe utilizar la cantidad total de recursos de actividad.
Nota condicional/componente asociado: costo
Definición: La unidad para expresar los recursos necesarios para completar la actividad independientemente de la disponibilidad o asignación.
Índice de Criticidad del Riesgo de Actividad Requerido (KRC) Calculado
Comportamiento: Representa la probabilidad de que una actividad se convierta en miembro de una ruta crítica. El cálculo puede variar según la herramienta de programación.
Buenas prácticas: se debe utilizar un proceso de análisis de riesgos para proyectos en los que las partes interesadas creen que existe un alto riesgo. El análisis de riesgos es
apropiado para proyectos en los que las variaciones del cronograma tienen un impacto significativo en los objetivos del proyecto.
Definición: La probabilidad de que la actividad del cronograma esté en una ruta crítica, calculada dividiendo la cantidad de veces que la actividad está en una ruta crítica durante la simulación
por la cantidad de iteraciones en esa simulación.
106 Sección 4
Definición del alcance de la actividad Opcional Manual
Comportamiento: Permite registrar información definida por el usuario sobre el trabajo a realizar. Puede documentarse en el campo de nota/comentario/
registro de actividad o en una ubicación personalizada.
Buenas prácticas: se debe proporcionar la definición del alcance de la actividad para cada actividad para delimitar aún más el trabajo.
Definición: Narrativa documentada que describe el trabajo representado por la actividad.
Actividad Duración total Requerido Calculado/Manual
Comportamiento: Define la duración de la actividad de principio a fin.
Buenas practicas:
Nota condicional/componente asociado: duración real, duración restante
Definición: El número total de períodos de trabajo en unidades de calendario para completar una actividad del cronograma. Para las actividades programadas en curso, incluye
la duración real de la actividad más la duración restante de la actividad. También conocida como duración de la actividad.
Actividad Trabajo Porcentaje completado Opcional Calculado/Manual
Comportamiento: representa la proporción del esfuerzo de trabajo real completado en un momento determinado.
Buenas practicas:
Definición: Una estimación, expresada como un porcentaje de la cantidad de trabajo que se ha completado en una actividad del cronograma. Por lo general, se basa en el
porcentaje completo de duración de la actividad y el perfil de horas de trabajo asignadas a la actividad.
Hora real (AT) Opcional Calculado
Comportamiento: Mide el tiempo.
Buenas prácticas: Incluya el cronograma ganado cuando utilice la metodología del cronograma ganado en el modelo de cronograma.
Definición: Es el número de períodos ejecutados.
107
Lo más tarde posible Opcional: sin puntuación Manual
Comportamiento: permite programar una actividad para que finalice en sus fechas de inicio y finalización tardías dadas las limitaciones y la lógica del modelo de programación
actual. El comportamiento de las restricciones lo más tarde posible depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. La restricción lo más tarde posible debe usarse con moderación.
Definición: Una restricción impuesta a una actividad que hará que se programe en sus fechas de inicio y finalización tardías.
Lo antes posible Opcional: sin puntuación Manual
Comportamiento: permite programar una actividad para que finalice en su fecha de finalización anticipada de CPM. La restricción lo antes posible depende de la herramienta de
programación. Puede considerarse una restricción flexible.
Buenas prácticas: normalmente, la restricción de fecha predeterminada. Debe utilizarse para la mayoría de las actividades en el modelo de programación.
Nota condicional/componente asociado: fecha de inicio del proyecto
Definición: una restricción impuesta a una actividad que hará que se programe para finalizar en la fecha más temprana después de la fecha de inicio del proyecto en
función de cualquier actividad anterior y lógica de programación.
Modelo de cronograma de línea base Requerido Calculado
Formato de datos: Varios
Comportamiento: Captura los componentes de la programación en el momento en que las partes interesadas del proyecto aprobaron el plan del proyecto. la programación
los componentes capturados dependen de la herramienta de programación.
Buenas practicas:
Nota condicional/componente asociado: El desarrollo del modelo de cronograma respalda el establecimiento y la aprobación de un
punto de análisis.
Definición: Un modelo de cronograma de referencia es una instancia de los componentes de cronograma en el momento en que los interesados aprobaron el plan del
proyecto (el último modelo de cronograma aprobado) y se utiliza para comparar con otras instancias del modelo de cronograma.
108 Sección 4
Presupuesto al finalizar (BAC) Obligatorio (ERC) Calculado
Comportamiento: Define el presupuesto autorizado del proyecto.
Buenas prácticas: Incluya recursos y costos asociados en el modelo de cronograma para definir el presupuesto por etapas.
Nota condicional/componente asociado: un BAC aprobado por la gerencia puede denominarse línea base aprobada.
Definición: La suma total de los costos de los recursos enumerados en el modelo de cronograma aprobado por la gerencia. BAC se puede calcular por actividad
y luego sumados a varios niveles.
Identificador de solicitud de cambio Opcional Manual
Comportamiento: identifica los cambios autorizados controlados por la configuración en el modelo de programación.
Buenas prácticas: como parte de la gestión de la configuración del cronograma, use el identificador de solicitud de cambio para marcar los cambios en el modelo del cronograma
aprobados por los procesos de gestión de la configuración. Este elemento normalmente se aborda en un campo personalizado.
Nota condicional/Componente asociado: Consulte el Estándar de práctica para la gestión de la configuración del proyecto [8]. Nota de actividad/comentario/registro.
Definición: El identificador de solicitud de cambio es el valor de la clave principal para los elementos en el registro de cambios del programa en relación con el modelo de programación.
ID de cuenta de control Obligatorio (ERC) Manual
Comportamiento: identifica el trabajo asociado con una cuenta de cobro de costos establecida.
Buenas prácticas: Incluya el identificador de la cuenta de control cuando utilice la metodología de valor ganado en el cronograma.
Nota Condicional/Componente Asociado: Ver El Estándar para la Gestión del Valor Ganado [5].
Definición: Un identificador de contabilidad de costos alfanumérico que normalmente se asigna en la intersección de la estructura de desglose del trabajo y la estructura de
desglose organizacional en el nivel en el que se recopilarán los costos. Las cuentas de control contienen paquetes de trabajo.
109
Gerente de Cuentas de Control (CAM) Opcional Manual
Comportamiento: identifica a la única persona responsable del desempeño de costos de una sola cuenta de control.
Buenas Prácticas: Incluya el identificador CAM cuando utilice la metodología de valor ganado en el cronograma. A veces se usa un número de referencia para una CAM sin nombrar
a un individuo.
Definición: Una designación alfanumérica de la persona única responsable de los costos y el logro del alcance del trabajo identificado por la cuenta de control; este puede ser el
nombre de un individuo o una referencia única que identifique al individuo.
Índice de rendimiento de costos (IPC) Opcional Calculado
Comportamiento: define el rendimiento de costos en relación con los logros y un presupuesto con fases de tiempo.
Buenas prácticas: Incluya el IPC cuando utilice la metodología de valor ganado en el cronograma.
Definición: EV/AC, calculado como valores desfasados en el tiempo y utilizado para medir la rentabilidad de un proyecto. Estos valores se pueden calcular en cualquier nivel de
esquema del modelo de cronograma y entre varias fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los valores
se denominan acumulativos.
Variación de costo (CV) Opcional Calculado
Comportamiento: representa la desviación en fases temporales del rendimiento logrado con respecto a los costos reales.
Buenas prácticas: Incluya la variación de costos cuando utilice la metodología de valor ganado en el cronograma.
Definición: EV ÿ AC, calculado como valores de fase temporal y utilizado para medir el desempeño de costos en un proyecto. Estos valores se pueden calcular en cualquier nivel de
esquema del modelo de cronograma y entre varias fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la
fecha de datos más actual, los valores se denominan acumulativos.
110 Sección 4
Porcentaje de variación de costo (CV%) Opcional Calculado
Comportamiento: representa la desviación en fases de tiempo del rendimiento programado del rendimiento real alcanzado expresado como porcentaje.
Buenas prácticas: Incluya el porcentaje de variación de costos cuando utilice la metodología de valor ganado en el cronograma.
Definición: 100 × (EV ÿ AC) / (EV), calculado como valores desfasados en el tiempo. Estos valores se pueden calcular en cualquier nivel de esquema del modelo de cronograma y
entre varias fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los valores se denominan acumulativos. Cuando EV
= 0, CPI = 0, independientemente de AC.
Camino critico Requerido Calculado
Formato de datos: Alfanumérico (lista de actividades)
Comportamiento: Identifica las actividades en la ruta crítica.
Buenas prácticas: Para establecer una ruta crítica significativa, es necesario desarrollar relaciones de actividad lógicas y bien definidas con duraciones derivadas
empíricamente para ejecutar todas las actividades del proyecto de manera práctica. Por lo tanto, no debe haber extremos abiertos que no sean el inicio y el final del proyecto. Las
restricciones deben restringirse solo a aquellas que representan eventos externos o internos que no pueden abordarse de manera efectiva con la lógica de la actividad.
Nota Condicional/Componente Asociado: Relaciones definidas para todas las actividades.
Definición: Generalmente, pero no siempre, la secuencia de actividades del cronograma que determina la duración del proyecto. Generalmente, es el camino más largo a través del
proyecto. Sin embargo, una ruta crítica puede terminar, por ejemplo, en un hito del cronograma que se encuentra en la mitad del modelo de cronograma y que tiene una restricción de
cronograma de fecha de terminación no posterior a la impuesta. Véase también ruta crítica del proyecto, ruta crítica especificada y método de ruta crítica.
Fecha de Datos Requerido Manual
Comportamiento: Registra la fecha hasta la cual se determina e informa el estado y el progreso del proyecto.
Buenas Prácticas: La fecha de los datos debe adelantarse al momento de informar el estado, a intervalos regulares.
Definición: Un punto en el tiempo cuando se registra el estado del proyecto. Cualquier dato a la izquierda de la fecha de datos (anterior) se considera información histórica. Cualquier
dato a la derecha de la fecha de datos (posterior) es el pronóstico del trabajo restante. La fecha de los datos es también el punto en el que se lleva a cabo el análisis de la medición
del rendimiento y la programación. También conocido como a la fecha.
111
Recursos de conducción Opcional Manual
Formato de datos: indicador (determinado por algoritmo [booleano])
Comportamiento: Identifica un recurso como impulsor para controlar la duración de las actividades. Los recursos son solo uno de los elementos que pueden afectar la duración
de una actividad.
Buenas Prácticas: Los recursos de conducción deben ser considerados dentro del cronograma.
Definición: recursos que se considera que tienen un impacto directo en la duración de la actividad durante la nivelación de recursos.
Calendario Ganado (ES) Opcional Calculado
Comportamiento: Mide el logro.
Buenas prácticas: Incluya el cronograma ganado cuando utilice la metodología del cronograma ganado en el modelo de cronograma.
Definición: Identifique el momento en que debería haberse ganado la cantidad de valor ganado (EV) acumulado. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto
y la fecha de datos más actual, los valores se denominan acumulativos.
Valor ganado (EV) Obligatorio (ERC) Calculado
Comportamiento: Mide el logro.
Buenas prácticas: Incluya el valor ganado cuando utilice la metodología de valor ganado en el modelo de cronograma.
Nota Condicional/Componente Asociado: Ver El Estándar para la Gestión del Valor Ganado [5]. Este término también se conoce como costo presupuestado del trabajo realizado
(BCWP).
Definición: El valor en fases temporales del esfuerzo realizado, independientemente del costo necesario para lograr el logro; el costo que estaría presupuestado por el monto de la
obra terminada antes de su ejecución. Cuando se completa, EV = BAC. Estos valores se pueden calcular en cualquier nivel de esquema del modelo de cronograma y entre varias
fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la
fecha de datos más actual, los valores se denominan acumulativos.
112 Sección 4
Tipo de medición de valor ganado Opcional Manual
Comportamiento: identifica para cada actividad o nivel de la EDT, uno de los tipos de medición reconocidos para recopilar el valor ganado según se define en los sistemas
de gestión del valor ganado (EVMS) del proyecto. Puede incluir, por ejemplo, 0-100, 50-50, hito ponderado, etc.
Buenas prácticas: para la integración de costos/programas, incluya el tipo de medición de valor ganado cuando utilice la metodología de valor ganado en el programa. El
método establecido en el cronograma coincide con el método de valor ganado establecido en el paquete de trabajo.
Definición: la designación alfanumérica de un tipo de medición específico para recopilar el valor ganado en el cronograma, tal como se define en el EVMS.
Peso del valor ganado Opcional Manual
Comportamiento: asigna un porcentaje del valor ganado (EV) para que un paquete de trabajo se asigne a actividades específicas.
Buenas prácticas: cuando el EV se asigna en forma de porcentaje, use el peso del EV en el cronograma cuando corresponda.
Definición: El porcentaje de EV asignado a un grupo específico de actividades.
Estimación al finalizar (EAC) Obligatorio (ERC) Calculado
Comportamiento: define el costo total, incluidos los costos reales ya incurridos, más los costos adicionales necesarios para completar el esfuerzo.
Buenas Prácticas: Asignar un valor que represente los costos totales proyectados incurridos al finalizar, independiente de un presupuesto autorizado.
Definición: AC + ETC, costos incurridos reales acumulados (AC) más costos anticipados para completar el alcance restante independientemente del presupuesto.
El EAC generalmente se calcula para cada actividad y luego se suma a varios niveles. Existen numerosos métodos para calcular el valor de
costos adicionales estimados para completar el alcance restante.
113
Duración estimada (ED) Opcional Calculado
Comportamiento: define los períodos totales, incluidos los períodos ya incurridos, más los períodos adicionales necesarios para completar el esfuerzo.
Buenas Prácticas: Asignar un valor que represente los plazos totales proyectados incurridos al término, independiente de una duración autorizada.
Definición: AT + ETC(t); es la suma de los períodos reales acumulados (AT) y los períodos previstos necesarios para completar el alcance restante independientemente de
la duración autorizada. ETC(t) normalmente se calcula para cada actividad y luego se suma a varios niveles. Existen numerosos métodos para calcular el valor de los períodos
adicionales estimados para completar el alcance restante.
Estimación para completar (ETC) Obligatorio (ERC) Calculado
Comportamiento: Define el costo requerido para completar el alcance restante identificado, sin tener en cuenta los gastos previos o el presupuesto.
Buenas Prácticas: Asignar un valor que represente el costo restante proyectado para completar, independiente del presupuesto autorizado.
Definición: Costos anticipados para completar el alcance restante independientemente del presupuesto y los costos reales previos. La ETC normalmente se calcula para
cada actividad y luego se suma a varios niveles. Existen numerosos métodos para predecir el valor de los costos restantes para el resto
alcance.
Estimación del tiempo completo (ETC(t)) Opcional Calculado
Comportamiento: Períodos previstos (anticipados) necesarios para completar el alcance restante independientemente de la duración autorizada.
Buenas Prácticas: Asignar un valor que represente los plazos restantes proyectados para completar, independiente de la duración autorizada.
Definición: Son los plazos previstos (anticipados) necesarios para completar el alcance restante independientemente de la duración autorizada. ETC(t) normalmente se
calcula para cada actividad y luego se suma a varios niveles. Existen numerosos métodos para calcular el valor de los gastos adicionales
plazos estimados para completar el alcance restante.
114 Sección 4
Identificador de paquete de trabajo de EVMS Obligatorio (ERC) Manual
Comportamiento: identifica el paquete de trabajo de EVMS en los horarios.
Buenas prácticas: para la integración de costos/programas, incluya el identificador del paquete de trabajo cuando utilice la metodología de valor ganado en el programa.
Un paquete de trabajo puede contener múltiples elementos WBS. El identificador del paquete de trabajo para una actividad contendrá un solo valor que lo asigna a un solo paquete
de trabajo.
Nota Condicional/Componente Asociado: Ver El Estándar para la Gestión del Valor Ganado [5] y el Estándar de Práctica para Estructuras de Desglose del Trabajo [4].
Definición: El identificador del paquete de trabajo es una designación alfanumérica de un paquete de trabajo específico en el EVMS.
Final esperado Opcional: sin puntuación Manual
Comportamiento: impone una fecha de finalización a una actividad que determina la duración restante de la actividad después de que se haya informado como iniciada con un
inicio real. El comportamiento de las restricciones de finalización esperadas depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. La restricción de finalización esperada debe usarse con moderación.
Definición: una restricción de fecha colocada en las fechas de finalización temprana y tardía del CPM de actividad de una actividad de cronograma en curso que afecta cuándo se
puede programar la finalización de la actividad de cronograma y, por lo general, tiene la forma de una fecha impuesta fija. Esta restricción requiere que la duración restante de la actividad
se establezca igual a la diferencia entre la fecha de finalización esperada de la actividad y la fecha de los datos para obligar a que la actividad del cronograma se programe para finalizar
en la fecha impuesta.
Terminar no antes de Opcional: sin puntuación Manual
Comportamiento: Impone una fecha al final de una actividad anterior a la cual la actividad no puede terminar. El comportamiento de terminar no antes de lo que es
depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. El acabado no anterior a la restricción debe usarse con moderación.
Definición: Una restricción de fecha colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad del cronograma y generalmente tiene la forma
de una fecha impuesta fija. Una finalización no anterior a la restricción evita que la actividad se programe para finalizar antes de la fecha impuesta. No antes de que las restricciones
afecten solo al cálculo del pase de avance de CPM; por lo tanto, solo las fechas tempranas de CPM de una actividad del cronograma.
115
Terminar no más tarde de Opcional: sin puntuación Manual
Comportamiento: Impone una fecha al final de una actividad especificando la última fecha en que una actividad puede terminar. El comportamiento de terminar a más tardar
depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. El acabado no más tarde de la restricción debe usarse con moderación.
Definición: Una restricción de fecha colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad del cronograma y generalmente tiene la forma de
una fecha impuesta fija. Una finalización no posterior a la restricción evita que la actividad se programe para finalizar más tarde de la fecha impuesta. A más tardar, las restricciones
afectan solo al cálculo del paso hacia atrás de CPM y, por lo tanto, a las fechas tardías calculadas por CPM de una actividad de programación.
Terminar en Opcional: sin puntuación Manual
Comportamiento: Impone una fecha al final de una actividad en la que debe terminar. Afecta tanto al CPM hacia adelante como al cálculo del paso hacia atrás de CPM y, por lo
tanto, tanto a las fechas tempranas como a las posteriores de CPM. Esto hace que la actividad tenga una flotación total de cero, mientras que sus predecesores y sucesores pueden
tener diferentes valores de flotación. La fecha de finalización se mueve con la fecha de los datos cuando la fecha de los datos es posterior a la fecha de finalización y cuando la
actividad no está completa. El comportamiento del acabado en las restricciones depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. Dado que esta restricción anula el cálculo de CPM, no se debe utilizar este componente.
Nota Condicional/Componente Asociado: Igual que la fecha de finalización obligatoria.
Definición: Una restricción de fecha colocada en la actividad del cronograma que requiere que la actividad del cronograma finalice en una fecha específica. Los cálculos de
programación no anulan esta restricción. Por lo tanto, un final impuesto establece las fechas tempranas del pase de avance de CPM para todas las rutas que conducen desde y las
fechas tardías de CPM en las rutas que conducen a la actividad. Esto también se conoce como must finish on.
Final a Final Opcional Manual
Formato de datos: Alfanumérico (ID de actividad)
Comportamiento: especifica para dos actividades que la actividad sucesora no se puede completar hasta que se complete la actividad predecesora.
Buenas prácticas: Todas las actividades, excepto la primera y la última actividad, deben tener al menos una relación de predecesor ?S y una F? relación de sucesor, donde “?” puede
ser una S o una F, independientemente de cualquier otra relación que pueda estar presente. (Donde S = inicio y F = final).
Definición: La relación lógica en la que la finalización del trabajo de la actividad sucesora no puede terminar hasta la finalización del trabajo de la actividad predecesora.
116 Sección 4
Terminar para comenzar Requerido Manual
Comportamiento: especifica para dos actividades que la actividad sucesora no se puede iniciar hasta que se complete la actividad predecesora.
Buenas prácticas: Todas las actividades, excepto la primera y la última actividad, deben tener al menos una relación de predecesor ?S y una F? relación de sucesor, donde “?”
puede ser una S o una F, independientemente de cualquier otra relación que pueda estar presente. (Donde S = inicio y F = final).
Por lo general, la relación más utilizada.
Definición: La relación lógica en la que el inicio del trabajo de la actividad sucesora depende de la finalización del trabajo de la actividad predecesora.
flotación libre Requerido Calculado
Comportamiento: representa la cantidad de tiempo que una actividad puede retrasar su finalización anticipada sin afectar el inicio anticipado de ninguna actividad sucesora. Es
la diferencia entre la fecha de finalización anticipada de una actividad y la fecha de inicio más temprana de la más cercana de sus sucesoras. A medida que se registra el progreso,
este valor puede cambiar. Este valor también puede cambiar cuando se revisan el trabajo restante, la lógica o las duraciones.
Buenas prácticas: la flotación libre se puede utilizar para proporcionar una indicación temprana de la actividad o el retraso en el cronograma.
Definición: La cantidad de tiempo que se puede retrasar una actividad del cronograma sin retrasar el inicio anticipado de CPM de las actividades del cronograma
inmediatamente posteriores. Véase también flotación total, un término similar pero no equivalente.
Actividad de hamaca Opcional Calculado
Comportamiento: representa una actividad que se extiende entre dos puntos en un cronograma o en paquetes WBS.
Buenas prácticas: se utiliza para respaldar los recursos que se necesitan en diferentes paquetes de WBS. Debe estar lógicamente vinculado.
Definición: Una actividad que se extiende entre dos puntos en un cronograma y generalmente se usa para transportar recursos relacionados con el tiempo y de apoyo.
117
Retraso Opcional Manual
Comportamiento: Modifica una relación lógica para imponer un retraso en el inicio o finalización de la actividad sucesora.
Buenas prácticas: los retrasos no deben reemplazar la lógica o las actividades de la red de programación. Los retrasos deben usarse con moderación. Los retrasos solo
deben usarse para un período de tiempo invariable que ocurre entre una actividad y otra. Un retraso no debe tomar recursos.
Definición: Una modificación de una relación lógica que dirige un retraso en la actividad sucesora. Por ejemplo, en una dependencia de fin a fin con un retraso de 10 días, la
actividad sucesora no puede finalizar hasta 10 días después de que haya finalizado la actividad predecesora. Véase también plomo.
Guiar Opcional: sin puntuación Manual
Comportamiento: Modifica una relación lógica para imponer una aceleración en el inicio o final de la actividad sucesora, análoga a un retraso negativo.
Buenas prácticas: los clientes potenciales no reemplazan la lógica o las actividades de la red de programación. Los cables deben usarse raramente. Los clientes
potenciales solo deben usarse durante un período de tiempo invariable que ocurre entre una actividad y otra. Un cliente potencial no debe tomar recursos.
Definición: Una modificación de una relación lógica que permite una aceleración de la actividad sucesora. Por ejemplo, en una dependencia de fin a fin con un adelanto
de 10 días, la actividad sucesora puede finalizar 10 días antes de que finalice la actividad predecesora. Un adelanto negativo es equivalente a un retraso positivo. Véase
también retraso.
Actividad de nivel de esfuerzo (LOE) Opcional Calculado
Comportamiento: Representa una actividad alineada con un paquete WBS definido.
Buenas Prácticas: Utilizado para trazabilidad vertical y roll-up de paquetes WBS.
Definición: Un grupo de actividades del cronograma relacionadas con el mismo paquete WBS y que se muestran/informan como una sola actividad. LOE se utiliza para el trabajo
paquetes donde el progreso no se puede medir fácilmente.
118 Sección 4
Fecha de finalización obligatoria Opcional: sin puntuación Manual
Comportamiento: Impone una fecha al final de una actividad en la que se requiere terminar. Afecta tanto a los cálculos de la fecha de paso anterior como posterior del
CPM y, por lo tanto, a las fechas tempranas y tardías. Esto hace que la actividad tenga una flotación total de cero, mientras que sus predecesores y sucesores pueden tener
diferentes valores de flotación. El comportamiento de las restricciones de fecha de finalización obligatoria depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. Dado que esta restricción anula el cálculo de CPM, no se debe utilizar este
componente.
Nota condicional/componente asociado: igual que finalizar.
Definición: Una restricción de fecha colocada en la actividad del cronograma que requiere que la actividad del cronograma finalice en una fecha específica. Los cálculos
de programación no anulan esta restricción. Por lo tanto, un final obligatorio impuesto impulsa las fechas tempranas de CPM para todos los caminos que conducen desde y
las fechas tardías en los caminos que conducen a la actividad. También conocido como must finish on.
Fecha de inicio obligatoria Opcional: sin puntuación Manual
Comportamiento: Impone una fecha al inicio de una actividad en la que se requiere iniciar. Afecta tanto a los cálculos de la fecha de paso hacia adelante como hacia atrás
del CPM y, por lo tanto, tanto a las fechas tempranas como a las posteriores. Esto hace que la actividad tenga una flotación total de cero, mientras que sus predecesores y
sucesores pueden tener diferentes valores de flotación. El comportamiento de las restricciones de fecha de inicio obligatoria depende de la herramienta de programación.
componente.
Nota condicional/componente asociado: Igual que el inicio.
Definición: Una restricción de fecha colocada en la actividad del cronograma que requiere que la actividad del cronograma comience en una fecha específica. Los
cálculos de programación no anulan esta restricción. Por lo tanto, un inicio obligatorio impuesto impulsa las fechas tempranas de CPM para todas las rutas que conducen
desde y las fechas tardías en las rutas que conducen a la actividad. También conocido como must start on.
Hito Requerido Calculado
Formato de datos: indicador (determinado por algoritmo [booleano])
Comportamiento: Representa una actividad que identifica un evento significativo.
Buenas Prácticas: El hito no tiene recursos asignados ni duración. Como mínimo, un hito de inicio y finalización del proyecto debe estar presente en el cronograma. El
indicador de hito debe tener una forma única, como un diamante.
Definición: Un punto o evento significativo en el proyecto. Véase también programar hito.
119
Valor planificado (PV) Obligatorio (ERC) Calculado
Comportamiento: La medición en fases temporales de los gastos anticipados.
Buenas prácticas: incluya el valor planificado cuando utilice la metodología del valor ganado en el modelo de cronograma.
Nota Condicional/Componente Asociado: Ver El Estándar para la Gestión del Valor Ganado [5]. Este término también se conoce como costo presupuestado del trabajo programado
(BCWS). PV a veces se conoce como plan de referencia.
Definición: El valor desglosado en el tiempo de los gastos previstos y necesarios aprobados por la administración para lograr el alcance definido. Cuando se completa el alcance, PV =
BAC. Estos valores se pueden calcular en cualquier nivel de esquema del modelo de cronograma y entre varias fechas de datos.
Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los valores se denominan acumulativos.
Distribución de riesgo de probabilidad Requerido (KRC) Calculado
Comportamiento: Representa un insumo clave para el análisis de riesgo cuantitativo de la duración de las actividades. Las distribuciones de riesgo de probabilidad comunes
incluyen: normal o curva de campana, logaritmo normal, uniforme, triangular, beta y discreta (definida por el usuario).
Buenas Prácticas: Se pueden encontrar en El Estándar para la Gestión de Riesgos en Portafolios, Programas y Proyectos [6]. La distribución de riesgo de probabilidad debe asignarse
a cada actividad en el modelo de cronograma. Los datos, generalmente determinados por juicio, se recopilan de los participantes del proyecto y otros expertos durante las entrevistas o
talleres de riesgo.
Definición: Define la probabilidad de que determinados atributos o rangos de atributos sean o hayan sido observados.
Duración real del proyecto Requerido Calculado
Comportamiento: Identifica el tiempo transcurrido desde que se inició el plan del proyecto.
Buenas practicas:
Definición: El número total de períodos de trabajo en unidades de calendario entre la fecha de inicio real del proyecto y la fecha de datos de la instancia del modelo de cronograma
cuando el proyecto está en progreso o la fecha de finalización real del proyecto cuando el proyecto está completo.
120 Sección 4
Fecha de finalización real del proyecto Requerido Calculado
Comportamiento: identifica la finalización real del proyecto en función de la fecha de finalización real de la última actividad.
Buenas practicas:
Definición: El punto en el tiempo asociado con la fecha de finalización real de la actividad de la última actividad del cronograma en el proyecto.
Fecha de inicio real del proyecto Requerido Calculado
Comportamiento: define el inicio real del proyecto en función de la fecha de inicio real de la actividad más antigua.
Buenas practicas:
Definición: El punto en el tiempo asociado con la fecha de inicio real de la actividad de la primera actividad programada en el proyecto.
Calendario del proyecto Requerido Manual
Comportamiento: Define los períodos de trabajo predeterminados para el proyecto.
Buenas Prácticas: A nivel de proyecto, este constituye el calendario principal o por defecto del proyecto.
Definición: Un calendario de períodos laborables y no laborables que establece cuándo se trabajan las actividades del cronograma y cuándo están inactivas las actividades del cronograma.
Por lo general, define días festivos, fines de semana y horas de turno. El calendario inicialmente asignado para programar actividades y recursos. Ver también
calendario de actividades y calendario de recursos.
Categoría de costo del proyecto Opcional Manual
Comportamiento: proporciona desgloses adicionales que se pueden asignar a cuentas de costos específicas dentro del proyecto.
Buenas prácticas: A efectos contables, los costos deben desglosarse en categorías como directos, indirectos, mano de obra, materiales, equipos, etc.
Definición: elementos contables utilizados para integrar las partidas individuales del catálogo de cuentas tradicional con la estructura de contabilidad de costos del proyecto.
121
Descripción del Proyecto Opcional Manual
Comportamiento: Describe con una frase corta, el proyecto.
Buenas prácticas: la descripción del proyecto debe resumir el alcance del trabajo para todo el proyecto.
Definición: Resumen narrativo documentado del enunciado del alcance del proyecto.
Requerido (ver Proyecto Físico
Proyecto Duración Porcentaje completado Porcentaje completo) Calculado
Comportamiento: representa el progreso del proyecto como un porcentaje de la duración total esperada del proyecto.
Buenas practicas:
Nota condicional/componente asociado: se debe usar el porcentaje completo de duración del proyecto o el porcentaje completo físico del proyecto.
Definición: Una estimación, expresada como porcentaje, de la duración total del proyecto que se ha completado en el proyecto.
Fecha de finalización anticipada del proyecto Requerido Calculado
Comportamiento: identifica el final anticipado de la última actividad, según el pase de avance de CPM.
Definición: El punto en el tiempo asociado con la fecha de finalización anticipada de la actividad de la última actividad del cronograma del proyecto.
Fecha de inicio anticipado del proyecto Requerido Calculado
Comportamiento: identifica el inicio anticipado de la primera actividad, según el pase de avance de CPM.
Definición: El punto en el tiempo asociado con la fecha de inicio temprano de la actividad de la primera actividad del cronograma del proyecto.
122 Sección 4
Restricción de finalización del proyecto Opcional Manual
Comportamiento: proporciona el punto de partida para el paso hacia atrás de CPM para el proyecto. La restricción se utiliza como punto de partida para el cálculo del
paso hacia atrás para cualquier actividad en el modelo de programación sin sucesores y sin otras restricciones de paso hacia atrás de CPM.
Esta fecha puede ser anterior o posterior a la fecha de finalización del proyecto que se calcula a partir del avance de CPM.
Buenas prácticas: la fecha de finalización, típicamente definida por el cliente e incluida en el modelo de cronograma. Es necesario hacer un esfuerzo para desarrollar un
modelo de cronograma alcanzable con flotación total no negativa. Este esfuerzo debería dar como resultado un modelo de cronograma con un nivel de riesgo aceptable para
todas las partes interesadas. Si esto no se logra, se debe informar a la parte interesada que define la restricción de terminación del proyecto y se debe acordar un plan de
mitigación.
Definición: una limitación o restricción impuesta a la fecha de finalización tardía del proyecto que afecta cuándo debe finalizar el proyecto y, por lo general, tiene la forma de
una fecha impuesta fija.
Fecha de finalización tardía del proyecto Requerido Calculado
Comportamiento: identifica el final tardío de la última actividad, según el pase de avance de CPM.
Definición: El punto en el tiempo asociado con la fecha de finalización tardía de la actividad de la última actividad del cronograma del proyecto.
Fecha de inicio tardío del proyecto Requerido Calculado
Comportamiento: identifica el inicio tardío de la primera actividad del proyecto, en función del pase hacia atrás.
Definición: El punto en el tiempo asociado con la fecha de inicio tardío de la actividad de la primera actividad del cronograma del proyecto.
123
Nombre del proyecto Requerido Manual
Comportamiento: Describe, en forma abreviada, el proyecto.
Buenas practicas:
Definición: Una frase corta o etiqueta para cada proyecto, usada junto con el identificador del proyecto para diferenciar un proyecto en particular de
otros proyectos en un programa. También conocido como título del proyecto.
Requerido (ver Duración del Proyecto
Porcentaje físico del proyecto completado Porcentaje completo) Calculado
Comportamiento: Representa el avance del proyecto como porcentaje del trabajo físico total a realizar. A nivel de proyecto, este valor generalmente se calcula utilizando
técnicas de gestión del valor ganado. A medida que se registra el progreso, se calcula el valor ganado en el nivel de actividad.
Buenas Prácticas: Realizadas de acuerdo con The Standard for Earned Value Management [5]. El porcentaje físico completado del proyecto se determina dividiendo
las unidades de valor ganado resumidas por el presupuesto del proyecto en las mismas unidades.
Nota condicional/componente asociado: requiere el uso de la técnica del valor ganado. Debe utilizar el porcentaje completo de duración del proyecto o el porcentaje
completo físico del proyecto.
Definición: Un cálculo, expresado como un porcentaje, de la cantidad de trabajo que se ha completado en el proyecto, medido en términos de avance del trabajo físico.
Duración restante del proyecto Requerido Calculado
Comportamiento: identifica el tiempo necesario para completar el proyecto a partir de la fecha de los datos.
Buenas prácticas: una vez que un proyecto comienza pero no se completa durante un ciclo de informes, se determina la duración que
Queda por terminar la obra.
Definición: El número total de períodos de trabajo en unidades de calendario, ya sea igual a la duración original de un proyecto que no ha comenzado o entre la fecha
de datos del modelo de cronograma y la fecha de finalización anticipada del proyecto que tiene al menos una actividad real fecha de inicio.
Esto representa el tiempo necesario para completar un proyecto donde el trabajo está en progreso.
124 Sección 4
Cantidad real del recurso del proyecto Obligatorio (RRC) Manual/Calculado
Comportamiento: Medida de la utilización de recursos para el proyecto a partir de la fecha de los datos.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos, se debe utilizar la cantidad real del proyecto.
Definición: La unidad para expresar la utilización de recursos para el proyecto a partir de la fecha de los datos.
Fecha de finalización nivelada por recursos del proyecto Opcional Calculado
Comportamiento: identifica la finalización más temprana de un proyecto en función de las limitaciones de recursos.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos y existen sobreasignaciones de recursos, se debe usar la nivelación de recursos.
Definición: El punto en el tiempo asociado con la fecha de finalización programada de la última actividad de una actividad de programación de recursos limitados en un recurso
horario limitado.
Fecha de inicio nivelada de recursos del proyecto Opcional Calculado
Comportamiento: identifica el comienzo más temprano de un proyecto en función de las limitaciones de recursos.
Definición: El punto en el tiempo asociado con la fecha de inicio programada de la primera actividad de una actividad de programación de recursos limitados en un recurso
horario limitado.
Cantidad restante de recursos del proyecto Obligatorio (RRC) Calculado
Comportamiento: Medida de los recursos necesarios para completar un proyecto a partir de la fecha de los datos.
Buenas prácticas: una vez que un proyecto comienza pero no se completa durante un ciclo de informes, se debe determinar los recursos que aún se necesitan para completar el
trabajo.
Definición: La unidad para expresar los recursos necesarios para completar el proyecto de actividad a partir de la fecha de los datos.
125
Cantidad total de recursos del proyecto Obligatorio (RRC) Manual/Calculado
Comportamiento: Medida de las asignaciones de recursos del proyecto, generalmente expresada como tipo de recurso o medida.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos, se debe utilizar la cantidad total del proyecto.
Definición: La unidad para expresar las asignaciones de recursos en todas las actividades del proyecto.
Restricción de inicio del proyecto Opcional Manual
Comportamiento: proporciona el punto de partida para el pase hacia adelante del proyecto. Se utiliza como punto de partida para el cálculo del paso adelante para cualquier actividad
en el modelo de programación sin predecesores ni restricciones de paso adelante.
Buenas prácticas: la fecha de inicio normalmente la define el cliente y se incluye en el modelo de programación. Se debe hacer un esfuerzo para desarrollar un modelo de cronograma
alcanzable que cumpla con la restricción de inicio del proyecto. Este esfuerzo debe tener en cuenta los recursos disponibles y dar como resultado un modelo de cronograma con un nivel
de riesgo aceptable para todas las partes interesadas. Si esto no se logra, se debe informar a la parte interesada que define la restricción de inicio del proyecto y se debe acordar un
plan de mitigación.
Definición: una limitación o restricción impuesta a la fecha de inicio anticipada del proyecto que afecta cuándo puede comenzar el proyecto y generalmente tiene la forma de una fecha
impuesta fija.
Duración total del proyecto Requerido Calculado
Comportamiento: Identifica la duración del proyecto de principio a fin.
Buenas practicas:
Definición: El número total de períodos de trabajo en unidades de calendario para completar un proyecto. Para un proyecto en progreso, incluye el proyecto real
duración más la duración restante del proyecto.
Asignación de recursos Obligatorio (RRC) Manual
Comportamiento: Acción de asignar un recurso a una actividad.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos, se utilizará la asignación de recursos.
Definición: La actividad de asignar un recurso a un elemento de modelo de programación específico.
126 Sección 4
Disponibilidad de recursos Obligatorio (RRC) Manual
Comportamiento: Establece la disponibilidad de un recurso para apoyar el proyecto.
Buenas prácticas: este valor no refleja las asignaciones de recursos actuales y del proyecto para el recurso indicado.
Definición: Las fechas y el número de períodos de trabajo en unidades de calendario en los que se puede utilizar un recurso dado de acuerdo con la
calendario de recursos.
Calendario de recursos Obligatorio (RRC) Manual
Comportamiento: Define los períodos de trabajo para el recurso.
Buenas practicas:
Definición: Un calendario de periodos laborables y no laborables asignados al recurso, que define los periodos laborables y los periodos no laborables en formato
de calendario. Por lo general, define días festivos específicos de recursos y períodos de disponibilidad de recursos. Véase también calendario de proyectos y calendario de
actividades.
Descripción del recurso Obligatorio (RRC) Manual
Comportamiento: Describe con una frase corta el recurso y su dominio asociado.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Si se identifica un recurso, se necesita la descripción del recurso. todos los recursos
las descripciones deben ser únicas.
Definición: Una frase que identifica un recurso por tipo, rol o individuo. También conocido como nombre de recurso.
ID de recurso Obligatorio (RRC) Calculado
Comportamiento: Identifica el recurso asignado.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Si se identifica un recurso, se debe usar el ID del recurso. Todos los ID de recursos deben ser únicos.
Definición: Una breve descripción numérica o de texto única asignada a cada recurso específico para diferenciar ese recurso de otros recursos.
El ID de recurso suele ser único dentro de cualquier proyecto.
127
Retraso de recursos Opcional Manual
Comportamiento: Define el tiempo desde el inicio de la actividad que un recurso específico puede comenzar a trabajar.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Los retrasos de recursos solo se deben usar durante un período de tiempo invariable que debe ocurrir
entre el inicio de la actividad y el uso del recurso.
Definición: El número de unidades de calendario que un recurso debe esperar después de la fecha de inicio de la actividad antes de comenzar a trabajar en la actividad del cronograma.
Biblioteca de recursos/Diccionario Obligatorio (RRC) Manual
Comportamiento: proporciona una lista de los recursos aplicados a las actividades en el modelo de programación.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Una biblioteca de recursos o un diccionario debe organizarse en un
estructura.
Definición: una tabulación documentada que contiene la lista completa, incluidos los atributos de los recursos, de todos los recursos que se pueden asignar a las actividades
del proyecto. También conocido como diccionario de recursos.
Tarifas/precios de recursos Opcional Manual
Comportamiento: Define el costo por unidad de tiempo para un recurso específico.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Cuando se asignan recursos, se deben usar tarifas/precios de recursos.
Definición: la tasa de costo unitario asignada a un recurso específico, incluidos los aumentos de tasa conocidos.
Tipo de recurso Obligatorio (RRC) Manual
Comportamiento: Indica la clasificación del recurso.
Buenas Prácticas: Los recursos deben ser identificados y asignados. Si se identifica un recurso, se debe utilizar el tipo de recurso.
Definición: Una designación única que diferencia un recurso por habilidades, capacidades u otros atributos. Un recurso individual tiene un tipo de recurso y muchos recursos
pueden tener el mismo tipo de recurso.
128 Sección 4
Identificación de riesgo
Requerido (KRC) Manual/Calculado
Comportamiento: Distingue riesgos en el registro de riesgos del proyecto.
Buenas Prácticas: Se pueden encontrar en El Estándar para la Gestión de Riesgos en Portafolios, Programas y Proyectos [6]. Los ID de riesgo se asignan a
actividades en el modelo de cronograma cuando corresponda.
Definición: Una identificación breve, numérica o de texto única asignada a cada riesgo en el registro de riesgos del proyecto.
Programar ID de modelo Requerido Manual
Comportamiento: Identifica el proyecto programado.
Buenas Prácticas: Debe ser un identificador único que pueda generarse automáticamente o seguir un esquema de numeración apropiado para la organización. Es útil asignar
una estructura o codificación razonada al ID del modelo de horario.
Definición: Una identificación breve, numérica o de texto única asignada a cada modelo de horario para diferenciar ese modelo de horario de los demás.
También conocido como identificador de proyecto.
Programar instancia de modelo Requerido Calculado
Comportamiento: Indica qué versión del modelo representa el cronograma.
Buenas prácticas: El número de versión debe incrementarse de manera consistente a medida que se realizan cambios sucesivos, lo que da como resultado diferentes versiones del
cronograma.
Definición: Una designación de la instancia de un modelo de cronograma. Los ejemplos incluyen: fecha actual, número de revisión y códigos de versión acordados,
entre otros. También conocida como versión del modelo de planificación.
129
Programar nivel de modelo Opcional Manual
Comportamiento: Define la granularidad o niveles de detalle del cronograma o su presentación.
Buenas prácticas: independientemente de la profundidad del nivel físico del cronograma general, se recomienda utilizar las siguientes definiciones de nivel de cronograma:
• Nivel 0—Resumen del proyecto. Esta es una sola línea que representa todo el proyecto y se usa a menudo para comparar proyectos en una cartera.
o programa.
• Nivel 1—Resumen ejecutivo. Este es un cronograma a nivel de resumen, generalmente de una sola página que incluye los principales hitos contractuales
y actividades de nivel de resumen.
• Nivel 2: Resumen de gestión. Este es un programa de nivel de resumen más extenso, generalmente de cuatro a cinco páginas que incluye el
Resumen de nivel 1 e informes de actividades similares por área o bienes de capital.
• Nivel 3—Programa de publicación. Este es el nivel de detalle utilizado para respaldar el informe mensual. Incluye todos los hitos principales y los elementos principales de ingeniería,
adquisición, construcción y puesta en marcha.
• Nivel 4—Planificación de Ejecución. Esto apoya a los equipos de construcción y puesta en marcha en su planificación general del proyecto.
Normalmente se deben mostrar todas las actividades con una duración de más de 1 semana. El cronograma de anticipación de 3 semanas se produce a partir del nivel 4 y
superior.
• Nivel 5—Planificación detallada. Este nivel de detalle apoya la planificación a corto plazo para el campo, normalmente para aquellas actividades de menor
de 1 semana de duración. Las soluciones provisionales y las áreas críticas se pueden desglosar aquí.
Definición: regla especificada de un equipo de proyecto para la granularidad relativa de las actividades del cronograma en el modelo de cronograma general.
Programación Modelo Presentación Requerido Manual
Formato de datos: Gráfico
Comportamiento: muestra los datos del programa.
Buenas practicas:
1. Se debe emplear una representación visual de las actividades del modelo de cronograma como un gráfico de barras.
2. Los productos deben representar la fecha en la que se genera el producto.
3. Deben incluirse descripciones del producto y los elementos principales dentro del producto.
4. Los resultados deben mostrar tanto el progreso como la fecha actual de los datos.
5. Cualquier diagrama de red del proyecto debe tener la menor cantidad posible de puntos de cruce lógicos, al tiempo que garantiza espacio suficiente para representar
líneas de relación (ver Figura 2-3 por ejemplo).
Definición: Una salida de las instancias del modelo de cronograma que se utiliza para comunicar datos específicos del proyecto para informes, análisis y toma de decisiones.
130 Sección 4
Índice de rendimiento del cronograma (SPI) Opcional Calculado
Comportamiento: define el rendimiento del cronograma comparando el trabajo realizado con el trabajo programado.
Buenas prácticas: Incluya SPI cuando utilice la metodología de valor ganado en el cronograma.
Definición: EV/PV, calculado como valores de fase temporal y utilizado para medir un progreso en relación con el cronograma. Estos valores se pueden calcular en
cualquier nivel de esquema del modelo de cronograma y entre varias fechas de datos. Cuando el cálculo se realiza utilizando el inicio del proyecto
date y la fecha de datos más actual, los valores se denominan acumulativos.
Índice de rendimiento de la programación Tiempo (SPI(t) Opcional Calculado
Comportamiento: define el rendimiento del cronograma comparando el trabajo realizado con el tiempo real ejecutado.
Buenas prácticas: Incluya SPI(t) cuando utilice la metodología de cronograma ganado en el cronograma.
Definición: Es la relación entre el cronograma ganado y el tiempo real y se utiliza para medir un progreso en relación con el cronograma. Estos valores se pueden calcular en
cualquier nivel de esquema del modelo de cronograma y entre varias fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más
actual, los valores se denominan acumulativos.
Variación de horario (SV) Opcional Calculado
Comportamiento: Desviación del rendimiento programado del rendimiento real logrado.
Buenas prácticas: Incluya la variación del cronograma cuando utilice la metodología del valor ganado en el cronograma.
Definición: (EVÿPV)/PV, calculado como valores de fase temporal y utilizado para medir un progreso relativo al cronograma. Estos valores se pueden calcular en cualquier nivel
de esquema del modelo de cronograma y entre varias fechas de datos. Cuando el cálculo se realiza utilizando el inicio del proyecto
date y la fecha de datos más actual, los valores se denominan acumulativos.
131
Porcentaje de variación del cronograma (SV%) Opcional Calculado
Comportamiento: mide la desviación del rendimiento programado del rendimiento real logrado.
Buenas prácticas: Incluya el porcentaje de variación del cronograma cuando utilice la metodología del valor ganado en el cronograma.
Definición: 100 × (EVÿPV)/(PV), calculado como valores desfasados en el tiempo. Estos valores se pueden calcular en cualquier nivel de esquema del modelo de cronograma y
entre varias fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los valores
se denominan acumulativos.
Horario Variación Tiempo (SV(t) Opcional Calculado
Comportamiento: mide la desviación del rendimiento programado del tiempo real ejecutado.
Buenas prácticas: Incluya la variación del cronograma SV(t) cuando utilice la metodología del cronograma ganado en el cronograma.
Definición: Es la diferencia entre el cronograma ganado (ES) y el tiempo real (AT), y se utiliza para medir un progreso relativo al cronograma.
Estos valores se pueden calcular en cualquier nivel de esquema del modelo de cronograma y entre varias fechas de datos. Cuando el cálculo se realiza utilizando la fecha de inicio
del proyecto y la fecha de datos más actual, los valores se denominan acumulativos.
Empezar no antes de Opcional: sin puntuación Manual
Comportamiento: Impone una fecha de inicio de actividad anterior a la cual la actividad no puede iniciar. No antes de que las restricciones impacten solo en el cálculo de avance
y, por lo tanto, en las primeras fechas de una actividad.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. El inicio no anterior a la restricción debe usarse con moderación.
Definición: Una restricción de fecha colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad del cronograma y generalmente tiene la forma de una
fecha impuesta fija. Una restricción de inicio no anterior a impide que la actividad del cronograma se programe para comenzar antes de la fecha impuesta.
Empezar no más tarde de Opcional: sin puntuación Manual
Comportamiento: Impone una fecha al inicio de una actividad especificando la última fecha en que puede comenzar una actividad.
Buenas prácticas: las restricciones no deben reemplazar la lógica de la red de programación. El comienzo no posterior a la restricción debe usarse con moderación.
Definición: Una restricción de fecha colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad del cronograma y generalmente tiene la forma de una
fecha impuesta fija. Una restricción de inicio no posterior a evita que la actividad del cronograma se programe para comenzar más tarde de la fecha impuesta.
132 Sección 4
Comienza en Opcional: sin puntuación Manual
Comportamiento: Impone una fecha al inicio de una actividad en la que se debe iniciar. Afecta tanto a los cálculos de paso hacia adelante como hacia atrás y, por lo tanto, a las
fechas tempranas y tardías. Esto hace que la actividad tenga una flotación total de cero, mientras que sus predecesores y sucesores pueden tener diferentes valores de flotación.
La fecha de inicio se moverá con la fecha de los datos si la fecha de los datos es posterior a la fecha de inicio. el comportamiento de
las restricciones de inicio dependen de la herramienta de programación.
componente.
Nota Condicional/Componente Asociado: Igual que el inicio obligatorio.
Definición: Una restricción de fecha colocada en la actividad del cronograma que requiere que la actividad del cronograma comience en una fecha específica. Los cálculos
de programación no anulan esta restricción. Por lo tanto, una restricción de inicio impuesta establece las fechas tempranas para todas las rutas que conducen desde y las fechas
tardías en las rutas que conducen a la actividad.
Empezar a acabar Opcional: sin puntuación Manual
Comportamiento: especifica para dos actividades que la actividad sucesora no puede finalizar hasta que se inicie la actividad predecesora.
puede ser S o F, independientemente de cualquier otra relación que pueda estar presente (donde S = inicio y F = fin).
Definición: La relación lógica en la que la finalización de la actividad del cronograma sucesor depende del inicio de la actividad del cronograma predecesor. Véase también relación
lógica.
Comienzo a Comienzo Opcional Manual
Comportamiento: especifica para dos actividades que la actividad sucesora no se puede iniciar hasta que se inicie la actividad predecesora.
puede ser S o F, independientemente de cualquier otra relación que pueda estar presente (donde S = inicio y F = fin).
Definición: La relación lógica en la que el inicio del trabajo de la actividad del cronograma sucesor depende del inicio del trabajo de la actividad del cronograma predecesor. Véase
también relación lógica.
133
Resumen de actividad Opcional Calculado
Comportamiento: Hereda información de las actividades de los subordinados. Puede expresarse como una actividad acumulada.
Buenas Prácticas: Utilizado para trazabilidad vertical y roll-up.
Definición: Un grupo de actividades relacionadas del cronograma agregadas en algún nivel de resumen y mostradas/informadas como una sola actividad en ese nivel de resumen.
Véase también subred, subproyecto.
Modelo de cronograma objetivo Opcional Calculado
Formato de datos: Varios
Comportamiento: captura los componentes de programación para un modelo de programación objetivo.
Buenas practicas:
Definición: un modelo de programación objetivo es una instancia de los componentes de programación utilizados para la comparación con otros modelos de programación. Se puede
seleccionar un modelo de cronograma objetivo de cualquier instancia de modelo de cronograma disponible, por ejemplo, el último período de actualización.
Para completar el índice de rendimiento (TCPI) Opcional Calculado
Comportamiento: Medida del desempeño de costos requerida para terminar el proyecto en el EAC o BAC indicado.
Buenas prácticas: Incluya TCPI cuando utilice la metodología de valor ganado en el cronograma.
Definición: TCPI es el esfuerzo restante dividido por el presupuesto restante (o fondos restantes autorizados).
TCPIBAC = (BAC ÿ EVCUM)/(BAC ÿ ACUM)
TCPIEAC = (EAC ÿ EVCUM)/(EAC ÿ ACUM)
134 Sección 4
Para completar el horario
Índice de rendimiento (TSPI) Opcional Calculado
Comportamiento: Medida del desempeño del cronograma requerido para terminar el proyecto en la duración estimada establecida o la duración planificada.
Buenas prácticas: Incluya TSPI cuando utilice la metodología de cronograma ganado en el cronograma.
Definición: TSPI es la duración restante dividida por la duración estimada restante (o la duración restante autorizada).
TSPI = (PD ÿ ES)/(PD ÿ AT)
TSPI = (PD ÿ ES)/(ED ÿ AT)
Flotación total Requerido Calculado
Comportamiento: representa la cantidad de tiempo que una actividad puede retrasar su inicio anticipado de CPM o su finalización anticipada de CPM sin afectar la
finalización tardía de CPM del proyecto o violar una restricción de programación. Se calcula como la diferencia entre las fechas tempranas y tardías de CPM de la actividad,
calculadas a partir de los pases anteriores y posteriores de CPM, respectivamente. A medida que se registra el progreso, este valor puede cambiar. Este valor también puede
cambiar si se revisan la lógica de trabajo restante o las duraciones.
Buenas prácticas: la flotación total se puede utilizar para proporcionar una indicación temprana de un posible retraso en la finalización del proyecto. Esto se hace restringiendo el
hito de finalización del proyecto con una restricción de finalización.
Definición: La cantidad total de tiempo que una actividad del cronograma puede retrasarse desde su fecha de inicio temprano de CPM de actividad o fecha de finalización
anticipada de CPM de actividad sin retrasar la fecha de finalización tardía de CPM del proyecto o violar una restricción de cronograma. Calculado utilizando el enfoque del
método de la ruta crítica y restando (a) la fecha de finalización anticipada del CPM de la actividad de la fecha de finalización tardía del CPM de la actividad o (b) restando la fecha
de inicio anticipado del CPM de la actividad de la fecha de inicio tardío del CPM de la actividad, con esa diferencia expresada en unidades de calendario. Un valor flotante total
inferior a cero indica: (a) la fecha de retraso de CPM de la actividad está programada antes de la fecha temprana de CPM de la actividad y (b) la ruta que incluye la actividad no se
puede completar a tiempo para cumplir con el final de retraso de CPM de la pr objeto Un valor flotante total de cero o mayor indica (a) que la ruta que incluye la actividad se puede
completar a tiempo para cumplir con la finalización tardía de CPM del proyecto y (b) algunas actividades programadas en esa ruta pueden retrasarse. Véase también flotación libre.
Unidad de medida Requerido Manual
Comportamiento: Proporciona unidades cuantificables para varios componentes a lo largo del cronograma.
Buenas prácticas: Las unidades de medida deben definirse de manera consistente en todo el cronograma.
Definición: una designación del tipo de cantidad que se mide, como horas de trabajo, yardas cúbicas o líneas de código.
135
Diferencia Opcional Calculado
Comportamiento: cuantifica la salida de un punto de referencia de fecha (como la fecha de inicio, la fecha de finalización, el costo, las fechas de referencia y el costo, y la duración).
Buenas prácticas: la varianza debe revisarse en busca de tendencias a intervalos regulares para dar indicaciones tempranas de desviación y determinar
si se requiere una acción correctiva.
Definición: La diferencia entre dos atributos seleccionados expresada en unidades apropiadas como días laborables o moneda.
ID de la EDT Requerido Manual/Calculado
Comportamiento: asigna la actividad o tarea a la estructura de descomposición del trabajo del proyecto. Alinea la actividad con su elemento principal dentro de la EDT.
Buenas Prácticas: Se pueden encontrar en el Estándar de Práctica para Estructuras de Desglose de Trabajo [4].
Definición: Una identificación breve, numérica o de texto única asignada a cada elemento de la estructura de desglose del trabajo (WBS) para diferenciar una WBS particular
de cualquier otro elemento de la WBS en un programa.
136 Sección 4
ÍNDICE DE CONFORMIDAD
Esta sección proporciona una descripción general del proceso del índice de conformidad. Esta sección se divide en las siguientes
secciones:
5.1 Resumen de conformidad
5.2 Proceso de evaluación de la conformidad
Cada sección proporciona información adicional sobre el contenido y la terminología de este estándar de práctica.
5.1 VISIÓN GENERAL DE LA CONFORMIDAD
El índice de conformidad proporciona un medio para evaluar qué tan bien un modelo de cronograma de CPM incorpora las pautas,
definiciones, comportamientos y buenas prácticas para los componentes definidos en la Sección 4 de este estándar de práctica. Algunos
gerentes de proyecto pueden optar por no incluir algunos de estos componentes básicos requeridos (CRC). Al hacerlo, el modelo de
cronograma resultante no estará en conformidad con este estándar de práctica y puede no ser viable. La premisa básica es que a medida
que aumenta el índice de conformidad, también lo hace (a) la aplicación adecuada de los componentes del modelo de cronograma y (b)
la probabilidad de que el modelo de cronograma desarrollado represente un plan sólido. El índice de conformidad también fue diseñado
para reflejar dónde existen las debilidades del modelo de cronograma desarrollado y qué áreas necesitan más mejoras. Los conceptos,
comportamientos, atributos y buenas prácticas de programación se definen para todos los componentes del modelo de programación.
La conformidad con el modelo de cronograma se evalúa evaluando la existencia y el uso adecuado de los diversos componentes
definidos en este estándar de práctica de acuerdo con las buenas prácticas.
137
5.1.1 CATEGORÍAS DE COMPONENTES
La lista de componentes en la Sección 4 identifica aquellos componentes que son:
u Componentes requeridos en un modelo de cronograma,
u Componentes opcionales que pueden estar presentes pero no son necesarios, y
u Componentes sin puntuación (NS), que son componentes opcionales que pueden estar presentes en un modelo de cronograma pero
no puntuado en el índice de conformidad.
Los componentes básicos necesarios se definen en cuatro grupos diferentes:
u Los componentes básicos necesarios (CRC) son necesarios independientemente de la complejidad del proyecto,
u Los componentes de recursos requeridos (RRC) son necesarios cuando los documentos del proyecto requieren carga de recursos,
u Los componentes requeridos por EVM (ERC) son necesarios cuando los documentos del proyecto requieren EVM (incluidos los
cronograma) que se utilizará en el proyecto, y
u Los componentes requeridos por el riesgo (KRC) son requeridos cuando los documentos del proyecto requieren que los conceptos de riesgo sean
considerados durante el desarrollo y mantenimiento del cronograma.
5.1.2 USO DE COMPONENTES DEL PROGRAMA
En general, el tamaño del proyecto, la complejidad del proyecto o la experiencia del programador o del equipo de gestión impulsan el uso de componentes
de programación en un modelo de programación determinado. Para cumplir con este estándar de práctica, se requieren componentes básicos (CRC) en cualquier
cronograma, independientemente de los requisitos definidos por el proyecto. Otros tipos de componentes requeridos se aplican para un proyecto específico en
función de los requisitos de ese proyecto. Los requisitos están definidos por varios documentos del proyecto y generalmente están contenidos dentro de los
activos del proceso organizacional, el lenguaje del contrato del proyecto o el plan de gestión del cronograma para el proyecto, pero también pueden incluirse en
otros documentos escritos.
El RRC, ERC y KRC se basan condicionalmente en los requisitos del proyecto. Por ejemplo, cuando el proyecto requiere que se carguen recursos en el
proyecto y no hay otros requisitos para la gestión del valor ganado o la gestión de riesgos, los componentes totales requeridos son CRC + RRC. De manera
similar, cada área requerida se agrega al CRC cuando lo requiere el proyecto. Cuando se requieren recursos, riesgos y gestión del valor ganado, los componentes
necesarios son CRC + RRC + ERC + KRC. A medida que aumenta la complejidad de los requisitos del proyecto, también lo hace el número total de componentes
necesarios.
138 Sección 5
Los componentes necesarios deben utilizarse en su totalidad para lograr un nivel mínimo aceptable de conformidad.
Cuando los documentos del proyecto no proporcionan requisitos para el cronograma, solo se requieren los componentes de CRC.
El RRC, el ERC y el KRC siguen siendo componentes opcionales para ese proyecto. La puntuación del índice de conformidad se realiza de
acuerdo con el Apéndice X3, que divide los componentes en tres categorías básicas: componentes básicos requeridos (CRC), componentes
condicionalmente requeridos (RRC, ERC, KRC) y componentes opcionales.
El proceso del índice de conformidad proporciona un medio para ajustar el valor del índice cuando se utilizan componentes opcionales.
La existencia de un componente, en sí mismo, no es suficiente para sumar a la puntuación. El uso de componentes opcionales puede
contribuir al índice solo si estos componentes cumplen con las recomendaciones de buenas prácticas definidas en la lista de componentes
de la Tabla 4-1. Los componentes de NS pueden estar presentes en un modelo de cronograma, pero no se cuentan en el índice de
conformidad basado en la lista de componentes de la Sección 4.
5.1.3 EVALUACIÓN DE LA CONFORMIDAD
El proceso de evaluación consta de dos partes: (a) una para la aplicación de los componentes obligatorios y (b) otra para la aplicación
de los componentes opcionales. Estas dos partes se suman para obtener un valor de índice total. Las puntuaciones resultantes de estas
dos evaluaciones se suman para obtener un valor de índice total. El proceso de evaluación se explica con mayor detalle en la Sección 5.2.
El concepto crítico es que los componentes requeridos deben estar presentes antes de que se pueda registrar un valor de índice de
conformidad. Los componentes específicos requeridos pueden cambiar según los requisitos del proyecto. El CRC siempre debe estar
presente independientemente de la complejidad del alcance del proyecto.
Una vez que se ha evaluado el modelo de cronograma para la incorporación de los componentes requeridos apropiados, se pueden
lograr mayores grados de conformidad mediante el uso adecuado de los componentes de cronograma opcionales relevantes.
Los componentes opcionales solo se cuentan cuando se adhieren adecuada y completamente a las definiciones, comportamientos y buenas
prácticas definidas en la Sección 4. Los componentes opcionales solo deben usarse para respaldar las necesidades de un proyecto
específico, nunca solo para aumentar el valor del índice. Como regla general, se espera encontrar el uso de componentes opcionales en
organizaciones más sofisticadas o modelos de cronograma más complejos. Los modelos de cronograma que no utilizan completamente
todos los componentes requeridos y sus conceptos se consideran de naturaleza de desarrollo. Los modelos de cronograma de desarrollo
aún pueden evaluarse con un valor de índice de conformidad, pero deben reflejarse como "no cumple con los estándares mínimos de
conformidad".
El diseño del proceso de evaluación de la conformidad del modelo de cronograma admite una evaluación manual. Cuando un componente
está presente en el modelo de cronograma y se usa correctamente, se gana un punto. La relación entre el número total de puntos
(obligatorios más opcionales) obtenidos en relación con el número total de puntos posibles que podrían otorgarse representa el valor de
conformidad y se expresa como un porcentaje en el continuo de 0 a 100. Los componentes requeridos son un excepción a esta regla. Como
se indicó anteriormente, cuando los componentes requeridos (según lo definido por el
139
requisitos del proyecto) no se utilizan por completo (100% empleados), entonces el modelo de cronograma no cumple con este estándar de
práctica. Si se logra este umbral mínimo, entonces el valor de la relación se representa en el continuo o escala móvil, siendo (32 = 36/111) el
más bajo y (100 = 111/111) el más alto (consulte la Tabla 5-1). El valor más bajo (32 = 36/111) representa la proporción que provendría solo de
los componentes requeridos (CCR), todos los cuales son necesarios en cada modelo de cronograma.
Si el evaluador determina que no se han cumplido los requisitos mínimos, el evaluador puede (a) finalizar el proceso de evaluación o (b)
continuar la evaluación con el fin de ayudar a la organización a identificar áreas específicas que requieren mejoras. En este caso,
independientemente del número final de puntos anotados, el evaluador no registra el valor de evaluación del modelo de cronograma en el
continuo porque no cumple con el mínimo
requisitos
5.2 PROCESO DE EVALUACIÓN DE LA CONFORMIDAD
El Apéndice X3 contiene una lista de los componentes del cronograma organizados en componentes básicos requeridos (CRC), componentes
condicionalmente requeridos (RRC, ERC, KRC) y componentes opcionales. La Tabla 5-1 refleja el número máximo de componentes por
categoría, así como el número máximo total de componentes puntuables. La Tabla 5-1 no incluye los componentes NS, por lo que la cantidad
total de componentes disponibles no es igual a la cantidad total de componentes definidos en la Sección 4. Utilizando la lista del Apéndice X3,
el evaluador determina si cada componente requerido está presente en el modelo de cronograma. siendo analizado. El programador debe
comprender completamente las buenas prácticas asociadas con los diversos componentes obligatorios y opcionales.
Tabla 5-1. Número de componentes por categoría
Requerido Condicional Opcional Total

Disponible
CDN CRR ERC KRC Opcional
36 13 9 7 46 111
Para comenzar el proceso de evaluación, el evaluador primero determina la respuesta a las siguientes preguntas:
u ¿Existe algún requisito para la carga de recursos?
u ¿Existe algún requisito para utilizar EVM?
u ¿Existe algún requisito para utilizar la gestión de riesgos basada en cronogramas?
140 Sección 5
Cuando la respuesta a cualquiera de las preguntas es afirmativa, se necesitan los componentes del cronograma requeridos para ese
grupo además del CRC. El CRC, entonces, estará presente en cualquier modelo de horario. Ejemplos de cómo los componentes requeridos
condicionales pueden afectar el umbral incluyen:
u Cuando se requiere carga de recursos, se requiere el RRC y el nivel mínimo de componentes requeridos es
CRC + RRC.
u Cuando se requiere EVM, se requiere ERC, y el nivel mínimo de componentes requeridos es CRC + ERC.
u Cuando se requiere gestión de riesgos, se requiere el KRC y el nivel mínimo de componentes requeridos es
CRC + KRC.
u Cuando se requiere carga de recursos y EVM, el nivel mínimo de componentes requeridos es CRC +
RRC + ERC.
u Cuando se requiere carga de recursos, gestión de riesgos y EVM, el nivel mínimo de componentes requeridos
es CRC + KRC + RRC + ERC.
Dependiendo de los requisitos del proyecto, el valor que se puede alcanzar para el pleno cumplimiento de los componentes requeridos
puede variar entre CRC y CRC más la suma de los componentes adicionales requeridos por RRC/ERC/KRC. Este valor comprende la
primera parte del proceso de evaluación denominada valor de los componentes requeridos.
La parte restante de la puntuación de la evaluación se compone de todos los componentes opcionales disponibles. Por ejemplo, cuando
no se requieren componentes KRC, todos los componentes de riesgo se consideran opcionales. Una vez que se contabilizan los
componentes necesarios, todos los componentes restantes se representan mediante el valor de los componentes opcionales. El evaluador
revisa los componentes opcionales restantes y, cuando están presentes y se utilizan correctamente, el evaluador otorga los puntos que se indican.
Cada componente opcional también tiene un valor de uno. El evaluador determina una puntuación bruta sumando todos los puntos
obtenidos de los componentes requeridos junto con los componentes opcionales. Si no se obtienen todos los puntos asociados con el valor
de los componentes requeridos, entonces no se puede registrar una puntuación bruta final. Sin embargo, la puntuación bruta se puede
compartir con el proyecto para que la organización pueda comprender las áreas de mejora. Finalmente, la puntuación bruta se divide por la
puntuación total máxima posible para obtener el índice de conformidad. El valor resultante se expresa como un porcentaje y representa la
puntuación del índice de conformidad para el modelo de programación.
Cuando la evaluación de la conformidad de un modelo de cronograma con este estándar de práctica y su madurez implícita ha
se ha logrado:
u El evaluador determina dónde cae un modelo de cronograma dado en el continuo de evaluación.
u El programador luego determina acciones específicas para avanzar más a lo largo del continuo.
Un valor de índice de conformidad más alto no implica automáticamente un mejor modelo de programación. Sin embargo, puede indicar
una mayor probabilidad de lograr los objetivos del proyecto. El Apéndice X4 contiene una hoja de puntuación en blanco y algunos ejemplos.
141
APÉNDICE X1
CAMBIOS EN LA TERCERA EDICIÓN
Este apéndice proporciona información sobre los cambios clave realizados en el Estándar de práctica para la programación - Segunda
Edición para crear el Estándar de práctica para la programación - Tercera edición.
El comité del proyecto fue autorizado para actualizar y mejorar el Estándar de práctica para la programación - Segunda edición. Las
siguientes áreas se incluyeron en el alcance aprobado para la actualización:
u Agile como un área de mayor contenido,
u Todos los insumos que se han presentado para considerar su inclusión o expansión (por ejemplo, planificación de recursos, análisis,
BIM y programación basada en la ubicación, y planificación y análisis forense),
u Todos los comentarios diferidos y tardíos de la segunda edición, y
u Posible alineación/consideración de la especificación del examen PMI Scheduling Professional (PMI-SP)® .
Adicionalmente, se consideraron las siguientes fuentes y criterios:
u Armonización de temas y conceptos clave con los estándares fundamentales de PMI,
u Alineación con el Léxico de Términos de Gestión de Proyectos de PMI,
u Recomendaciones del Grupo Asesor de Miembros de Normas,
u Recomendaciones de la revisión de expertos en la materia, y
u Recomendaciones de la revisión del borrador para exposición pública.
Esta edición del Estándar de práctica para la programación se centró en agregar más claridad a los temas descritos en la edición
anterior.
El cambio más importante de esta edición es la cobertura ampliada de la programación mediante enfoques ágiles y otros enfoques
adaptables. Esto respalda la mayor cobertura de ágil en la Guía PMBOK® - Sexta edición y el lanzamiento de la Guía de práctica ágil.
143
Hay un aumento significativo en el número de cifras incluidas a lo largo del Estándar de Práctica para Programación - Tercera Edición,
basado en varios comentarios diferidos que solicitan cifras adicionales.
Esta edición también amplía e introduce otros enfoques y tendencias emergentes que incluyen: programación basada en la ubicación,
programación bajo demanda, programación ajustada, sistemas inteligentes, línea de equilibrio, modelado de información de construcción
y programación ganada como un enfoque de monitoreo y control.
La estructura del apéndice se modificó para incluir dos apéndices adicionales de la siguiente manera:
u Cambios en la tercera edición de X1 : describe los cambios clave de la segunda edición a la tercera edición.
u X5 Análisis forense de horarios—Proporciona una introducción al tema del análisis forense de horarios.
144 Apéndice X1
APÉNDICE X2
COLABORADORES Y REVISORES DEL
ESTÁNDAR DE PRÁCTICA PARA LA PROGRAMACIÓN – TERCERA EDICIÓN
Este apéndice enumera, dentro de los grupos, a las personas que han contribuido al desarrollo y la producción del Estándar de
práctica para la programación - Tercera edición. El Project Management Institute agradece a todas estas personas por su apoyo y
reconoce sus contribuciones a la profesión de dirección de proyectos.
X2.1 ESTÁNDAR DE PRÁCTICA PARA LA PROGRAMACIÓN: COMITÉ PRINCIPAL DE LA TERCERA EDICIÓN
Las siguientes personas sirvieron como miembros, contribuyeron con textos o conceptos y sirvieron como líderes dentro
el Comité Central del Proyecto:
Bridget Fleming, presidenta, MCP, PMI-SP,

PMP Harold “Mike” Mosley, Jr., vicepresidente, PE,
PMP Jeanine Cooper, OCP, PMI-SP, PMP Charles
T. Follin, PMP Charles Gallagher, MBA, PMP M
Elaine Lazar, MA, MA, Astd, PMI Especialista en
proyectos de estándares Sanjay Mandhan, MBA, PMP Fernando
Nunes de Oliveira, PMI-SP, PMI-RMP, PMP Gilberto Regal Rodríguez,
PMI-SP, PMP
145
REVISORES X2.2
X2.2.1 REVISIÓN DE PYMES
Además de los miembros del Comité, las siguientes personas brindaron su revisión y recomendaciones
sobre los borradores de la norma:
James Aksel, PMP

Erik J. Brenner, MBA, PMP
Panos Chatzipanos, PhD, Dr. Eur Ing
Jennifer C. Fortner, MSA, PMP Ivo
Gerber, PMI-ACP, PgMP Walter Lipke,
PE, MS, PMI Premio Eric Jenett Norman Patnode
Gary J. Sikma, PMI-ACP, PMP Dave Violette, MPM,
PMP Laura A. Williams, PMI-SP, PMP
X2.2.2 REVISIÓN DEL PROYECTO DE EXPOSICIÓN FINAL
Además de los miembros del Comité, las siguientes personas brindaron recomendaciones para mejorar
el Proyecto de Norma del Estándar de Práctica para la Programación - Tercera Edición.
Abdalilah Hamed Abbas, PMI-RMP, PMP Panos Chatzipanos, PhD, Dr. Eur Ing
Majed Abdeen, MSc, PMP Ahmad Khairiri Sergio Luis Conte, PhD, PMP Pamela
Abdul Ghani, Eur Ing, MBA, FIMechE Habeeb Abdulla, MS, Crayon, CSM, PMP William H.
PMP Emre Alic, PMP Abdulrahman Alulaiyan, MBA, PMP Dannenmaier, MBA, PMP Saju Devassy,
Nabeel Eltyeb Babiker, P3O, PMP Pablo Balsamo Haytham SAFe, POPM, PMP Tasheka Dorsey,
Baraka Athanasios Bikos Kiron D. Bondale, PMI-ACP, PMP MBA, PMP Phillip Doyle, PMP Jon Edgar
Naga Pradeep Buddhavarapu Paulo Guilherme Coda A. Christopher Edwards, MBA, PMP
Dias Mohamed MH El-fouly, PMI-SP, PMP
Walla S. Elhadey, PMI-RMP, PMP
Mossab Abbas ElKhidir, CCP, PMP Wael
K. Elmetwaly, PMI-ACP, PMP Majdi N.
Elyyan, PMI- RMP, PMP
Larry Cebuano, PMP
146 Apéndice X2
Gregory Fabian, MS, PMP Aleksei Nikitin, PMI-ACP, PMP

Fereydoun Fardad, PMI-PBA, PMP Mohammad Ali Niroomand Rad, MArch, PMP
A. Fernández Fernández, BSc, CAPM Habeeb Omar, PgMP, PfMP Truc Pham, PMI-
Bruce Gay, PMP Ioanna Giampatzidou, RMP, PMP David R. Pratten, MIM, PMP Claudia
MStat, OpRes, PMP Theofanis Giotis, PhDc, Prince, PMP Carl Pro
PMP Akram Hassan, PhD, PMP Hossam
Hassan Anwar, PMI-RMP, PMP Paul A
Ivinson, BSc(Hons), MIET, PMP Yves Naga Santhi Rayavarapu, ITIL, PMP
Jordan Rami MW Kaibni, BEng, PMP Dan S. Roman, PMI-ACP, PMP Jaime
Dorothy L. Kangas, PMP Diwakar Killamsetty, Andres Salazar Cabrera, PMI-RMP, PfMP G.
PMP Taeyoung Kim, PMP Stefanos Kotsonis, Lakshmi Sekhar, PMI-PBA, PMI-SP Olby Shaju,
PMP P. Ravikumar, PMP, PgMP Lydia Gala SAFe Agilist, PMP Artie Shaw, Jr ., PMP Edward
Liberio, PMI-RMP, PMP Vladimir Liberzon, Shehab, PMP, PgMP Abel Sillas, DM, PMP Mauro
GPSF, PMP Tong Liu Carlos López Javier, Sotille, PMI-RMP, PMP Frank Spiegel, PMI-ACP,
MBA, PMP Komal Mathur, CSM, PMP Felipe PMP Mohammed Khedir Sultan, MBA, PMP
Fernandes Moreira, PMP Syed Ahsan Tetsuya Tani, PMP Laurent Thomas, PMI-ACP,
Mustaqeem, PE, PMP Vinay Nagaraj, SSBB PMP Gaitan Marius Titi, PMI-PBA, PMP Kevin
(ASQ) , MS Asaya Nakasone, PMP Torres Barsallo, PMI-SP, PMP Eric Uyttewaal,
PMP Dave Violette, MPM, PMP Hany I. Zahran
147
X2.3 GRUPO ASESOR DE MIEMBROS DEL PROGRAMA DE ESTÁNDARES DEL PMI (MAG)
Las siguientes personas sirvieron como miembros del Grupo Asesor de Miembros del Programa de Estándares de PMI durante
desarrollo de la Guía del PMBOK® – Sexta Edición:
Maria Cristina Barbero, CSM, PMI-ACP, PMP

Michael J. Frenette, ISP, SMC, MCITP, PMP Brian
Grafsgaard, CSM, PMP, PgMP, PfMP Dave Gunner,
MSc, PMP, PfMP Hagit Landman, MBA, PMI-SP,
PMP Vanina Mangano, PMP Yvan Petit, PhD, MBA,
MEng, PMP, PfMP Carolina Gabriela Spindola, MBA,
SSBB, PMP Chris Stevens, PhD Dave Violette, MPM,
PMP John Zlockie, MBA, PMP, PMI Gerente de
estándares
X2.4 REVISIÓN DEL ÓRGANO DE CONSENSO
Las siguientes personas sirvieron como miembros del Órgano de Consenso del Programa de Estándares de PMI:
Nigel Blampied, PE, PMP Vanina Mangano, PMP

Chris Cartwright, MPM, PMP John Mike Mosley, PE, PMP
Dettbarn, DSc, PE Charles Follin, Nanette Patton, MSBA, PMP
PMP Michael J. Frenette, ISP, Crispin (“Kik”) Piney, PgMP, PfMP Mike
SMC, MCITP, PMP Brian Grafsgaard, CSM, PMP, Reed, PMP, PfMP David Ross, PMP,
PgMP, PfMP Dave Gunner, MSc, PMP , PfMP PgMP Paul Shaltry, PMP Carolina
Dorothy Kangas, MS, PMP Thomas Kurihara Hagit Gabriela Spindola, MBA, SSBB , PMP
Landman, MBA, PMI-SP, PMP Tim MacFadyen, Chris Stevens, PhD Judi Vincent David J. Violette,
MBA, PMP MPM, PMP
148 Apéndice X2
X2.5 PERSONAL DE PRODUCCIÓN
Se debe una mención especial a los siguientes empleados de PMI:
Donn Greenberg, Gerente, Publicaciones

Kim Shinners, asociada de publicaciones
Roberta Storer, editora de productos
Barbara Walsh, supervisora de producción de publicaciones
149
APÉNDICE X3
TABLA DE PUNTUACIÓN DE LA EVALUACIÓN DE LA CONFORMIDAD
La Tabla X3-1 brinda claridad adicional con respecto a las cuatro categorías de componentes: componentes básicos requeridos (CRC),
componentes requeridos condicionalmente (RRC, ERC, KRC) y componentes opcionales (O). Esta tabla también proporciona la base para
el recuento oficial de cada categoría de componente que se utiliza en la hoja de trabajo de evaluación, que se muestra en el Apéndice X4.
El componente se enumera en la primera columna a la izquierda de la tabla. Las siguientes seis columnas muestran en qué categoría
se encuentra el componente: componentes básicos obligatorios (CRC), componentes de recursos condicionales (RRC), componentes EVM
condicionales (ERC), componentes de riesgo condicionales (KRC), componentes opcionales (OPT) o sin puntuación ( NS). La última línea
de la tabla refleja un resumen de cada tipo de categoría con un valor total para los componentes. Esta última línea de resumen también se
refleja en la parte superior de la hoja de trabajo de evaluación como un recordatorio del total de puntos disponibles en cada categoría.
151
Tabla X3-1. Ejemplo de tabla de puntuación de la evaluación de la conformidad
Componente CDN CRR ERC KRC OPTAR NS
Costo real de la actividad R
Actividad Duración real R
Actividad Fecha de finalización real R
Actividad Fecha de inicio real R
Calendario de actividades O
Código de actividad O
Categoría de costo de actividad O
Estimación del costo de la actividad O
Distribución de riesgo de probabilidad acumulada de actividad R
Fecha de finalización anticipada de la actividad R
Actividad Fecha de inicio temprano R
Actividad Esfuerzo O
ID de actividad R
Etiqueta de actividad R
Actividad Fecha de finalización tardía R
Actividad Fecha de inicio tardío R
Actividad Duración más probable R
Actividad Nota/Comentario/Registro O
Actividad Optimista Duración R
Actividad Duración original R
Actividad Pesimista Duración R
Actividad Física % Completado O Duración de la Actividad % CompletadoA R
Duración restante de la actividad R
(continuado)
152 Apéndice X3
Tabla X3-1. (Continuado)
Actividad Recurso Cantidad real R
Fecha de finalización nivelada por recursos de actividad O
Actividad Nivel de recursos Fecha de inicio O
Actividad Recurso Cantidad restante R
Actividad Recurso Cantidad total R
Índice de Criticidad del Riesgo de Actividad R
Definición del alcance de la actividad O
Actividad Duración total R
Actividad Trabajo Porcentaje completado O
Tiempo actual O
Lo más tarde posible NS
Lo antes posible NS
Modelo de cronograma de línea base R
Presupuesto al finalizar (BAC) R
Identificador de solicitud de cambio O
ID de cuenta de control R
Gerente de Cuentas de Control (CAM) O
Índice de rendimiento de costos (IPC) O
Variación de costo (CV) O
% de variación del costo (CV%) O
Camino critico R
Fecha de Datos R
Recurso de conducción O
(continuado)
153
Calendario Ganado (ES) O
Valor ganado (EV) R
Tipo de medición de valor ganado O
Peso del valor ganado O
Estimación al finalizar (EAC) R
Estimación para completar (ETC) R
Estimación del tiempo completo (ETC(t)) O
Duración estimada (ED) O
Identificador de paquete de trabajo de EVMS R
Final esperado NS
Terminar no antes de NS
Terminar no más tarde de NS
Terminar en NS
Final a Final O
Terminar para comenzar R
flotación libre R
Hamaca O
Retraso O
Guiar NS
Nivel de esfuerzo O
Fecha de finalización obligatoria NS
Fecha de inicio obligatoria NS
Hitos R
(continuado)
154 Apéndice X3
Valor planificado R
Distribución de riesgo de probabilidad R
Duración real del proyecto R
Fecha de finalización real del proyecto R
Fecha de inicio real del proyecto R
Calendario del proyecto R
Categoría de costo del proyecto O
Descripción del Proyecto O
Fecha de finalización anticipada del proyecto R
Fecha de inicio anticipado del proyecto R
Restricción de finalización del proyecto O
Fecha de finalización tardía del proyecto R
Fecha de inicio tardío del proyecto R
Nombre del proyecto R
Proyecto Físico % Completo O Duración del Proyecto % CompletoB R
Duración restante del proyecto R
Cantidad real del recurso del proyecto R
Fecha de finalización nivelada por recursos del proyecto O
Fecha de inicio nivelada de recursos del proyecto O
Cantidad restante de recursos del proyecto R
Cantidad total de recursos del proyecto R
Restricción de inicio del proyecto O
Duración total del proyecto R
(continuado)
155
Asignación de recursos R
Disponibilidad de recursos R
Calendario de recursos R
Descripción del recurso R
ID de recurso R
Retraso de recursos O
Biblioteca de recursos/Diccionario R
Tarifas/precios de recursos O
Tipo de recurso R
Identificación de riesgo R
Programar ID de modelo R
Programar instancia de modelo R
Programar nivel de modelo O
Programación Modelo Presentación R
Índice de rendimiento del cronograma (SPI) O
Tiempo de índice de rendimiento de programación (SPI(t)) O
Variación de horario (SV) O
% de variación de horario (SV%) O
Horario de variación de tiempo (SV(t)) O
Empezar no antes de NS
Empezar no más tarde de NS
Comienza en NS
Empezar a acabar NS
(continuado)
156 Apéndice X3
Comienzo a Comienzo O
Resumen de actividad O
Modelo de cronograma objetivo O
Para completar el índice de rendimiento (TCPI) O
Para completar el índice de rendimiento del cronograma (TSPI) O
Flotación total R
Unidad de medida R
Diferencia O
ID de la EDT R
Número de componentes en la categoría 36 13 9 7 46 13
Número total de componentes: 111
A
El porcentaje de actividad completado debe ser físico O duración: se requiere UNO.
B
El porcentaje de finalización del proyecto debe ser físico O duración; se requiere UNO.
157
APÉNDICE X4
HOJAS DE TRABAJO DE EVALUACIÓN DE LA CONFORMIDAD
El Apéndice X4 proporciona una serie de hojas de trabajo de evaluación. Los valores utilizados para los conteos totales en cada componente
categoría se toman directamente del Apéndice X3. Cada hoja de trabajo se explica con mayor detalle de la siguiente manera:
u Figura X4-1 Hoja de trabajo base. La figura X4-1 refleja los valores potencialmente disponibles para cada categoría completada.
Tenga en cuenta que las categorías de componentes condicionales se enumeran en ambas secciones en este punto, ya que aún no se
ha determinado si son necesarios para el proyecto determinado. La hoja base también refleja el valor requerido para los componentes
principales, los valores opcionales disponibles y, en la parte inferior de la página, se muestran los puntos totales disponibles. Esta hoja
base se puede reproducir y marcar manualmente para cualquier evaluación.
u Figura X4-2 Hoja de trabajo de ejemplo de recursos requeridos. La Figura X4-2 refleja una hoja de trabajo completa para un proyecto
que solo requirió la carga de recursos además de los componentes básicos básicos; también refleja la presencia de algunos componentes
opcionales. El ejemplo refleja una puntuación de evaluación de 53.
u Figura X4-3 Hoja de trabajo de ejemplo de recurso, EVM y riesgo requerido. La figura X4-3 refleja una hoja de trabajo completa para
un proyecto que requiere carga de recursos, EVM y gestión de riesgos además de los componentes básicos básicos; también refleja la
presencia de algunos componentes opcionales. El ejemplo refleja una puntuación de evaluación de 67.
u Figura X4-4 Hoja de trabajo de ejemplo de recurso y riesgo requerido. La figura X4-4 refleja una hoja de trabajo completa para un
proyecto que requería carga de recursos y gestión de riesgos además de los componentes básicos básicos; también refleja la presencia
de algunos componentes opcionales. El ejemplo refleja una puntuación de evaluación de 86.
Tenga en cuenta que algunos de los componentes opcionales puntuados son componentes EVM, pero dado que no fueron necesarios
en este proyecto, se encuentran en la categoría opcional.
u Figura X4-5 Hoja de trabajo de ejemplo sin puntuación. La figura X4-5 refleja una hoja de trabajo completa para un proyecto que
requería carga de recursos y gestión de riesgos además de los componentes básicos básicos; también refleja la presencia de algunos
componentes opcionales, incluidos todos los componentes de EVM. Sin embargo, tenga en cuenta que esta evaluación no tiene puntaje
porque no están presentes todos los componentes requeridos. Faltan tres de los requisitos básicos, así como tres de los componentes
de recursos. Las reglas establecen que si los componentes requeridos no están presentes, entonces no se debe registrar ningún puntaje.
Tenga en cuenta que aún puede ver los puntos obtenidos en comparación con los puntos disponibles tanto en las áreas obligatorias
como en las opcionales, pero no se registra ningún valor del índice de conformidad.
El Apéndice X4 fue desarrollado para proporcionar al usuario ejemplos para una mayor comprensión de cómo funciona el proceso de
evaluación.
159
Programar hoja de trabajo de evaluación

CDN CRR ERC KRC Disponible
Opcional
36 13 9 7 46 111
Preguntas de evaluación: sí No
1 ¿Existe algún requisito para la carga de recursos?
2 ¿Existe algún requisito para utilizar EVM?
3 ¿Existe un requisito para utilizar la gestión de riesgos?
Las respuestas a las preguntas de evaluación determinarán los valores de los puntos disponibles para los componentes obligatorios y opcionales que se
colocarán en los campos a continuación. El CRC siempre es obligatorio, por lo que los valores adicionales requeridos del cuadro anterior se agregarán al
CRC para obtener el total de puntos requeridos disponibles. Todas las categorías restantes se vuelven opcionales por definición y ese valor se registra
como el valor opcional. El total disponible siempre será igual al valor de 111.
Puntaje de los componentes requeridos
Potencial disponible Requerido GANADO 36 36
Componentes básicos necesarios (CRC) 36 Puntos Requeridos 56
Componentes de recursos necesarios (RRC) 13 13 13
Componentes requeridos de EVM (ERC) 9 0 Puntos Ganados 56
Componentes requeridos de riesgo (KRC) 7 7 7
Componentes Totales Requeridos 56 56
Puntuación de componentes opcionales
Potencial Disponible Disponible Opcional GANADO

Componentes básicos necesarios (CRC) 46 46 30 Puntos Disponibles 54
Componentes de recursos necesarios (RRC) 13 0
Componentes requeridos de EVM (ERC) 9 9 9 Puntos Ganados 39
Componentes requeridos de riesgo (KRC) 7 0
Componentes opcionales totales 54 54
Puntaje total
Este cuadro solo se completa si se obtienen TODOS los puntos requeridos
Puntaje de los componentes requeridos 56 Total de puntos disponibles 111
Puntuación de componentes opcionales 39
Total 95
Total de Ganancias 95
Puntos totales 111 Valor del índice de conformidad sin procesar 0.86
multiplicar por 100 100
Índice de conformidad 86
Figura X4-1. Hoja de trabajo básica
160 Apéndice X4

Opcional
36 13 9 7 46 111
1 ¿Existe algún requisito para la carga de recursos? X
2 ¿Existe algún requisito para utilizar EVM? X
3 ¿Existe un requisito para utilizar la gestión de riesgos? X
Potencial disponible Requerido GANADO 36

Componentes básicos necesarios (CRC) 36 36 Puntos Requeridos 49

Puntaje total
Total 59
Figura X4-2. Hoja de trabajo de ejemplo de recursos requeridos
161

Opcional
36 13 9 7 46 111
Las respuestas a las preguntas de evaluación determinarán los valores de los puntos disponibles para los componentes requeridos y opcionales que se
colocarán en los campos a continuación. El CRC siempre es obligatorio, por lo que los valores adicionales requeridos del cuadro anterior se agregarán al CRC.
para obtener el total de puntos requeridos disponibles. Todas las categorías restantes se vuelven opcionales por definición y ese valor se registra como el
valor opcional. El total disponible siempre será igual al valor de 111.
Potencial disponible Obligatorio GANADO
Componentes básicos necesarios (CRC) 36 36 36 Puntos Requeridos 65
Componentes requeridos de EVM (ERC) 9 9 9 Puntos Ganados sesenta y cinco
Componentes Totales Requeridos sesenta y cinco sesenta y cinco
Puntaje total
Puntaje de los componentes requeridos sesenta y cinco Total de puntos disponibles 111
Total 74
Puntos totales 111 Valor del índice de conformidad sin procesar 0,66
Figura X4-3. Hoja de trabajo de ejemplo de recurso, EVM y riesgo requerido
162 Apéndice X4

Opcional
36 13 9 7 46 111


Puntaje total
Total 95
Figura X4-4. Hoja de trabajo de ejemplo de recursos y riesgos requeridos
163

Opcional
36 13 9 7 46 111


Componentes requeridos de EVM (ERC) 9 9 9 Puntos ganados 34
Puntaje total
Total 95
Total de Ganancias
Figura X4-5. Hoja de trabajo de ejemplo sin puntuación
164 Apéndice X4
APÉNDICE X5
ANÁLISIS DE HORARIO FORENSE
El análisis de cronograma forense se desarrolló a partir de la necesidad de herramientas y métodos para ayudar en la comprensión
y el análisis de las variaciones significativas que surgen durante el ciclo de vida de un proyecto. El componente clave dentro de la
ciencia del análisis forense de horarios es siempre el mismo. El análisis se basa en la capacidad de comparar lo que estaba previsto
que ocurriera con lo que ocurrió. Si bien es un concepto simple, a menudo es difícil explicar lo que sucedió en comparación con lo que
se planeó y determinar qué causó la diferencia. El Estándar de Práctica para Programación y las buenas prácticas que destaca permiten
al usuario generar herramientas de programación más efectivas y también facilitan la realización de análisis forenses cuando sea
necesario. Mucho se ha producido sobre las diversas metodologías y procesos que se pueden utilizar para realizar un análisis de
programación forense. Algunas de las metodologías o procesos más conocidos se resumen a continuación:
u Metodología según lo planeado versus según lo construido. La metodología según lo planeado versus según lo construido
compara lo que realmente se logró con lo que se planeó originalmente. Se puede realizar a nivel de resumen o con mayor detalle.
Se enfoca en áreas de retraso específicas e intenta mostrar por qué ocurrió el retraso.
u Método de análisis periódico. El método de análisis periódico (ventanas) se basa en la capacidad de comparar el cronograma
que se capturó a lo largo del tiempo. Se enfoca en comparar los diversos horarios en intervalos de tiempo específicos y busca
explicar el movimiento programado (retrasos) dentro de ese marco de tiempo, analizando el horario de actualización a
actualización.
u Análisis de impacto temporal. La metodología de análisis de impacto en el tiempo (TIA) utiliza la incorporación de fragmentos
o porciones de lógica que representan el nuevo trabajo a realizar debido al cambio. También puede reflejar la eliminación del
trabajo que ya no se requiere. En cualquier caso, los horarios antes y después de la TIA se comparan con el documento para
cuantificar el retraso o la ganancia en el tiempo del horario.
165
u Metodología colapsada según construcción. El método colapsado de construcción comienza con el cronograma de construcción
y luego resta las actividades que representan demoras o cambios para demostrar el efecto en la fecha de finalización de un
proyecto (menos la demora o el cambio). En general, este método se aplica en los casos en que existe información confiable sobre
el cronograma conforme a obra.
u Método impactado según lo planeado. El método impactado según lo planeado implica la inserción o adición de actividades que
representan retrasos o cambios en el cronograma de referencia para determinar el impacto de esas actividades retrasadas en la
fecha de finalización del proyecto.
Cabe señalar que estas diversas metodologías y procesos a menudo comparten características comunes y requieren actualizaciones y
mantenimiento de cronograma activos, consistentes y precisos. Sin embargo, se pueden identificar algunos elementos clave de la
programación del proyecto que ayudarán al especialista forense a realizar el análisis.
La tarea principal, como se indicó anteriormente, es comparar lo que se planeó con lo que ocurrió. Todo proyecto debe
contienen documentos que permiten a un analista determinar lo que se planeó.
Primero, revise el contrato del proyecto y/o el acta de constitución del proyecto y determine lo que requiere en cuanto a herramientas y
documentos del cronograma. Se pueden producir varios documentos como prueba de lo que se logró. Por lo general, esto incluye, pero no
se limita a:
u Requisitos para tener un modelo de cronograma desarrollado a un nivel específico de detalle. También puede especificar los requisitos
tiempo para desarrollar el modelo de cronograma.
u Requisitos para crear y capturar un cronograma de referencia contra el cual se compara el progreso. Esto incluye
el proceso de aprobación del cronograma de referencia.
u Requisitos para las actualizaciones periódicas del modelo de cronograma, incluida la definición del período del ciclo.
u Contenido específico del modelo de cronograma requerido (por ejemplo, estructuras de código de actividad, ID de actividad, convenciones de
nomenclatura de actividad y otros).
u Requisitos para la identificación, seguimiento y aprobación de cambios en el modelo de cronograma del proyecto.
u Requisitos para realizar esfuerzos de rebaseline cuando sea necesario y las aprobaciones que se requieran.
u Definiciones de quién controla y posee el flotador del proyecto o cómo se utilizará.
En segundo lugar, verifique los procedimientos y procesos propios de la organización. Incluso si el contrato no contiene algunos de
estos datos, los documentos internos de la organización pueden proporcionar los requisitos que deberían haberse establecido.
A partir de estas dos fuentes descritas anteriormente, el analista debe ser capaz de determinar los documentos necesarios para
establecer lo que originalmente se planeó y aprobó para lograrse.
166 Apéndice X5
Otra consideración al revisar la línea de base del modelo de cronograma inicial es asegurarse de que sea realista. Algunas preguntas
a considerar y responder son:
u ¿Se va a utilizar el cronograma como un plan real o se está desarrollando para cumplir con un requisito del contrato?
Si los actores clave y las partes interesadas no están realmente comprometidos con el desarrollo y el trabajo del plan, está condenado desde
el principio.
u ¿Son realistas y razonables las duraciones de las actividades?
u ¿Están completas y bien pensadas las relaciones de actividad? ¿Tiene sentido la lógica del horario? ¿Se puede lograr como se muestra?
u ¿El cronograma contiene restricciones que podrían estar afectando el pase hacia atrás y el pase hacia adelante?
u ¿Tiene sentido la ruta crítica y la ruta casi crítica?
u ¿La ruta crítica cambia entre actualizaciones?
u ¿Se realizó una evaluación de conformidad con el cronograma y, de ser así, cuál fue el resultado?
En este punto, debe haber un entendimiento sobre el desarrollo de los esfuerzos del modelo de cronograma inicial y
conocimiento de lo que se planeó originalmente y cómo se creó.
El analista forense luego se enfoca en determinar lo que ocurrió versus lo que se planeó. Muchas actualizaciones del modelo de cronograma pueden
mostrar lo que ha ocurrido, de un período de actualización a otro, pero rara vez explican el motivo de la ocurrencia. El analista necesita identificar o
determinar forensemente la razón usando una variedad de métodos.
Los siguientes son ejemplos de documentos que un analista forense probablemente buscaría:
u Copia de cada actualización de progreso del modelo de cronograma para reflejar con el tiempo lo que sucedió con el plan;
u Cualquier entrada de registro o cuaderno asociada con cualquier actividad programada;
u Copias de cualquier aviso de cambio formal para el proyecto y cómo ese cambio afectó los esfuerzos de trabajo del proyecto;
u Copias de los miembros del equipo del proyecto, diarios de trabajo, diarios, notas o libros de registro;
u Copias de informes de progreso mensuales, semanales o diarios;
u Copias de actas de reuniones de progreso;
u Copias de cualquier solicitud de cambio y/o solicitud de información y cómo se dispusieron;
u Copias de los cronogramas rebasados y cualquier explicación de lo que se hizo y por qué;
u Copias de cualquier esfuerzo y análisis de análisis de impacto en el tiempo;
167
u Otros documentos o notas que le permitan al analista revisar el desempeño del proyecto y determinar por qué
ocurrió algo.
u Entrevistas con las partes involucradas en la ejecución de las actividades para determinar lo ocurrido.
Una vez que se hayan recopilado todos estos registros, documentos y versiones del modelo de cronograma, la ciencia y el arte
del análisis forense pueden comenzar. A menudo, las etapas iniciales de este análisis conducen a un estudio más profundo en áreas
específicas con el objetivo de determinar qué sucedió y por qué.
A medida que los proyectos se vuelven más y más complejos, aumenta la probabilidad de que los proyectos incurran en retrasos
que den lugar a reclamaciones. Sin embargo, muchas de las buenas prácticas descritas en este estándar de práctica se han
determinado durante muchos años de práctica para ayudar en los esfuerzos para mitigar este proceso de reclamaciones. Esto es
especialmente cierto cuando se considera la importancia de crear, mantener y actualizar todos los aspectos del cronograma del
proyecto de acuerdo con el Estándar de práctica para las buenas prácticas de programación. En el caso de un análisis de programa
forense, la aplicación adecuada y consistente de estas prácticas ayuda a un analista forense a realizar un análisis de manera eficaz y eficiente.
168 Apéndice X5
REFERENCIAS
[1] Instituto de manejo proyectos. 2017. Guía de práctica ágil. Newtown Square, Pensilvania: Autor.
[2] Instituto de manejo proyectos. 2017. Léxico de términos de gestión de proyectos del PMI. Newtown Square, Pensilvania: Autor.
[3] Instituto de manejo proyectos. 2017. Una guía para los fundamentos de la dirección de proyectos (Guía del PMBOK® ), sexta edición.
Newtown Square, Pensilvania: Autor.
[4] Instituto de manejo proyectos. 2019. Estándar de práctica para estructuras de descomposición del trabajo (WBS) - Tercera edición.
[5] Instituto de manejo proyectos. 2019. El Estándar para la Gestión del Valor Ganado - Segunda Edición. Newtown Square, Pensilvania: Autor.
[6] Instituto de manejo proyectos. 2019. La Norma para la Gestión de Riesgos en Portafolios, Programas y Proyectos.
[7] Instituto de manejo proyectos. 2019. Estándar de práctica para la estimación de proyectos, segunda edición. Newtown Square, Pensilvania:
Autor.
[8] Instituto de manejo proyectos. 2007. Estándar de práctica para la gestión de configuración de proyectos. Newtown Square, Pensilvania:
Autor.
169
GLOSARIO
1. SIGLAS COMUNES
C.A. costo real de la actividad o costo real
ACWP costo real del trabajo realizado
ANUNCIO
duración de la actividad
FA fecha de finalización real
COMO fecha de inicio real
Presupuesto BAC al finalizar
Gerente de cuentas de control CAM
IPC índice de rendimiento de costos
Método de la ruta crítica de CPM
CV variación de costo
DD fecha de Datos
DoD definición de hecho
DU duración
Duración DUR
171
Estimación de EAC al finalizar
ETC estimar para completar
VE valor agregado
TVE técnica de valor ganado
FF flotación libre
ordenador personal
Porcentaje completo
PCT por ciento completado
Método de diagramación de precedencia PDM
fotovoltaica
valor planificado
RD duración restante
SPI índice de rendimiento del cronograma
SV variación de horario
TF flotación total
Estructura de desglose del trabajo de la EDT
2. DEFINICIONES
Actividad. Una parte distinta y programada del trabajo realizado durante el curso de un proyecto. Véase también programar actividad.
Actividad Costo Real (AC). El costo realizado incurrido por el trabajo realizado en una actividad durante un período de tiempo específico. Véase también presupuesto al
finalizar (BAC), valor ganado (EV), estimación al finalizar (EAC), estimación hasta completar (ETC) y valor planificado (PV).
Duración real de la actividad. El número total de períodos de trabajo, en unidades de calendario, entre la fecha de inicio real de la actividad del cronograma y la fecha de
datos del modelo del cronograma, si la actividad del cronograma está en curso, o la fecha de finalización real de la actividad, si la actividad del cronograma Esta completo.
Véase también duración real.
Fecha de finalización real de la actividad. El punto en el tiempo en el que se completa una actividad del cronograma.
Fecha de inicio real de la actividad. El punto en el tiempo en el que comenzó una actividad del cronograma.
172 Glosario
Calendario de actividades. El calendario del proyecto u otro calendario específicamente definido de la biblioteca de calendarios asignada a la actividad del
cronograma que define los períodos de trabajo y los períodos de no trabajo en formato de calendario; se utiliza para reemplazar el calendario del proyecto durante
el análisis de la red del cronograma. Véase también biblioteca de calendario.
Código de actividad. Un valor alfanumérico asignado a cada actividad que permite clasificar, ordenar y filtrar.
Categoría de costo de actividad. Un desglose del costo, como el costo de la mano de obra, el costo del equipo y el costo del material.
Estimación del costo de la actividad. El costo proyectado de la actividad del cronograma que incluye el costo de todos los recursos necesarios para realizar y
completar la actividad, incluidos todos los tipos de costos y componentes de costos.
Distribución de riesgo de probabilidad acumulada de actividad. Una tabla de fechas y sus probabilidades acumuladas de ocurrencia asociadas para la
finalización de la actividad del cronograma.
Actividad Fecha de finalización actual. Ver fecha de finalización programada de la actividad.
Actividad Fecha de inicio actual. Ver fecha de inicio programada de la actividad.
Descripción de la actividad (AD). Una frase o etiqueta corta para cada actividad del cronograma, que se usa junto con un identificador de actividad para diferenciar
una actividad del cronograma del proyecto de otras actividades del cronograma. También conocido como nombre de actividad o título de actividad.
Duración de la actividad. El número total de períodos de trabajo, en unidades de calendario, entre la fecha de inicio anticipado de la actividad y la fecha de
finalización anticipada de la actividad de una actividad del cronograma. Véase también duración (DU o DUR).
Actividad Duración Porcentaje completado. El porcentaje calculado de que la duración real de la actividad es de la duración total de la actividad para una actividad
programada que tiene trabajo en curso.
Fecha de finalización anticipada de la actividad. El momento más temprano posible en el que la parte incompleta de la actividad del cronograma se puede
completar dados los recursos asignados. Véase también fecha de finalización anticipada.
Fecha de inicio anticipado de la actividad. El momento más temprano posible en el que la actividad del cronograma puede comenzar según el método de ruta
crítica (CPM) paso adelante de la lógica del modelo de cronograma. Véase también fecha de inicio temprano.
Esfuerzo de actividad. El número de unidades necesarias para completar una actividad del cronograma o un componente de la estructura de desglose del trabajo.
Identificador de actividad. Un valor alfanumérico asignado a una actividad y utilizado para diferenciar esa actividad de otras actividades. Véase también código de
actividad y etiqueta de actividad.
Etiqueta de actividad. Una frase que nombra y describe una actividad. Véase también código de actividad e identificador de actividad.
Fecha de finalización tardía de la actividad. El último momento posible en el que la actividad del cronograma se puede completar sin violar una restricción del
cronograma o retrasar la fecha de finalización del proyecto. Véase también fecha de finalización tardía.
173
Fecha de inicio tardío de la actividad. El último momento posible en el que la actividad del cronograma puede comenzar sin violar una restricción del cronograma
o retrasar la fecha de finalización del proyecto. Véase también fecha de inicio tardía.
Lista de actividades. Una tabulación documentada de las actividades del cronograma que muestra la descripción de la actividad, el identificador de la actividad y
una definición del alcance de la actividad suficientemente detallada para el trabajo, de modo que los miembros del equipo del proyecto entiendan qué trabajo se
debe realizar. La lista puede tener atributos de actividad adicionales.
Actividad Duración más probable. El número total de períodos de trabajo en unidades de calendario asignados para realizar la actividad del cronograma,
considerando todas las variables que puedan afectar el desempeño; se determina que es la duración más probable de la actividad.
Nombre de la actividad. Ver descripción de la actividad.
Nota de actividad. Documentación de información de apoyo adicional para una actividad.
Actividad Optimista Duración. El número total de períodos de trabajo en unidades de calendario asignados para realizar la actividad del cronograma, considerando
todas las variables que puedan afectar el desempeño; se determina que es la duración de actividad más corta posible.
Actividad Duración original. La duración de la actividad asignada originalmente a una actividad del cronograma; esta duración normalmente no se actualiza a
medida que se informa sobre el progreso de la actividad. Se utiliza para la comparación con la duración real de la actividad y la duración restante de la actividad al
informar el progreso del cronograma. La duración original de la actividad normalmente se desarrolla basándose en datos históricos, especialistas, disponibilidad de
recursos, consideraciones financieras y volumen de trabajo a realizar.
También conocida como duración planificada.
Actividad Pesimista Duración. El número total de períodos de trabajo en unidades de calendario asignados para realizar la actividad del cronograma, considerando
todas las variables que podrían afectar el desempeño, se determina que es la mayor duración posible de la actividad.
Actividad Física Porcentaje Completado. Una estimación, expresada como porcentaje, de la cantidad de trabajo que se ha completado en una actividad del
cronograma, medido en términos de progreso de trabajo físico o por medio de las reglas de obtención de la gestión del valor ganado.
Fecha de finalización planificada de la actividad. Ver fecha de finalización programada de la actividad.
Fecha de inicio planificada de la actividad. Ver fecha de inicio programada de la actividad.
Duración restante de la actividad. El número total de períodos de trabajo, en unidades de calendario, (a) igual a la duración original de una actividad que no ha
comenzado o (b) entre la fecha de los datos del cronograma del proyecto y la fecha de finalización anticipada del método de ruta crítica (CPM) de una actividad de
programación que tiene una fecha de inicio real de actividad. Esto representa el tiempo necesario para completar una actividad del cronograma donde el trabajo está
en progreso. Véase también duración restante.
174 Glosario
Fecha de finalización nivelada por recursos de la actividad. El punto en el tiempo asociado con la fecha de finalización programada de la actividad de una actividad del
cronograma de recursos limitados en un cronograma de recursos limitados.
Actividad Fecha de inicio nivelada por recursos. El punto en el tiempo asociado con la fecha de inicio programada de la actividad de una actividad del cronograma con
recursos limitados en un cronograma con recursos limitados.
Índice de Criticidad del Riesgo de la Actividad. La probabilidad de que la actividad del cronograma se encuentre en una ruta crítica.
Fecha de finalización programada de la actividad. El punto en el tiempo en el que se programó la finalización del trabajo en una actividad del cronograma.
La fecha de finalización programada de la actividad normalmente está dentro del rango de fechas delimitadas por la fecha de finalización anticipada de la actividad y la fecha
de finalización tardía de la actividad. Puede reflejar la nivelación de recursos de recursos escasos. También conocida como fecha de finalización planificada de la actividad.
Consulte también la fecha de finalización programada.
Fecha de inicio programada de la actividad. El punto en el tiempo en el que se programó el inicio del trabajo en una actividad del cronograma. La fecha de inicio
programada de la actividad normalmente está dentro del rango de fechas delimitado por la fecha de inicio temprano de la actividad y la fecha de inicio tardío de la actividad.
Puede reflejar la nivelación de recursos de recursos escasos. También conocida como fecha de inicio planificada de la actividad.
Consulte también la fecha de inicio programada.
Definición del alcance de la actividad. Narrativa documentada que describe el trabajo representado por la actividad.
Fecha de inicio de la actividad. Un punto en el tiempo asociado con el comienzo de la actividad del cronograma en un proyecto. Por lo general, calificado por uno de los
siguientes: real, de referencia, actual, temprano, tardío, programado o objetivo. Véase también fecha de inicio.
Título de la actividad. Ver descripción de la actividad.
Duración total de la actividad. El número total de períodos de trabajo, en unidades de calendario, para completar una actividad del cronograma. Para las actividades
programadas en curso, incluye la duración real de la actividad más la duración restante de la actividad.
Tipo de actividad. Una designación de categorización que diferencia las actividades discretas del cronograma que tienen diferentes funciones dentro del modelo de
cronograma, como hito, tarea, resumen, nivel de esfuerzo y dummy.
Costo real (CA). El costo realizado incurrido por el trabajo realizado en una actividad durante un período de tiempo específico.
Véase también presupuesto al finalizar (BAC), valor ganado (EV), estimación al finalizar (EAC), estimación hasta completar (ETC) y valor planificado (PV).
Costo real del trabajo realizado (ACWP). Ver costo real (AC).
Duración real. El tiempo, en unidades de calendario, entre la fecha de inicio real de la actividad del cronograma y la fecha de los datos del cronograma del proyecto, si la
actividad del cronograma está en progreso, o la fecha de finalización real si la actividad del cronograma está completa. Véase también duración real de la actividad y duración
real del proyecto.
175
Actividad Duración Porcentaje completado. El porcentaje calculado de que la duración real de la actividad es de la duración total de la actividad para una
actividad programada que tiene trabajo en curso.
Fecha de finalización real (AF). El punto en el tiempo en que el trabajo realmente terminó en una actividad del cronograma. (Nota: en algunas áreas de aplicación,
la actividad del cronograma se considera "terminada" cuando el trabajo está "sustancialmente completo"). Consulte también la fecha de finalización real del proyecto.
Fecha de inicio real (AS). El momento en el que el trabajo realmente comenzó en una actividad del cronograma. Ver la fecha de inicio real de la actividad
y la fecha de inicio real del proyecto.
Ágil. Un término utilizado para describir una mentalidad de valores y principios tal como se establece en el Manifiesto Ágil.
Aprobar. El acto de confirmar, sancionar, ratificar o acordar formalmente algo.
Flecha. La presentación gráfica de una actividad del cronograma en el método de diagramación de flechas o una relación lógica entre las actividades del
cronograma en el método de diagramación de precedencia.
A partir de la fecha. Ver fecha de datos (DD).
Suposición. Un factor en el proceso de planificación que se considera verdadero, real o cierto, sin prueba o demostración.
Reserva. Consulte la acumulación de iteraciones y la acumulación de productos.
Pase hacia atrás. Una técnica del método de ruta crítica para calcular las fechas de inicio tardío y finalización tardía trabajando hacia atrás a través del modelo de
cronograma desde la fecha de finalización del proyecto. Véase también pase adelantado.
Bar. Un objeto de visualización gráfica de forma rectangular que se utiliza para representar la aparición de un componente de datos en un documento, como una
actividad de programación en un gráfico de barras cuya duración está determinada por las fechas de inicio y finalización de la actividad correspondientes a la
escala de tiempo utilizada para el gráfico de barras. . Las barras pueden superponerse o mostrarse una al lado de la otra para indicar el progreso o las líneas de
base.
Gráfico de barras. Una pantalla gráfica de información relacionada con la programación. En el gráfico de barras típico, las actividades del cronograma o los
componentes de la estructura de desglose del trabajo se enumeran en el lado izquierdo del gráfico, las fechas se muestran en la parte superior y las duraciones de
las actividades se muestran como barras horizontales colocadas por fecha. También conocido como diagrama de Gantt.
Base. La versión aprobada de un producto de trabajo que se puede cambiar mediante procedimientos formales de control de cambios y se utiliza como base para
la comparación con los resultados reales. También conocida como línea de base de medición del rendimiento. Véase también línea base de costo y línea base de
cronograma.
Fecha de referencia. La fecha en la que se estableció la línea de base actual. A veces se usa con un modificador, como el cronograma del proyecto, el alcance
del proyecto o el costo del proyecto.
176 Glosario
Presupuesto. La estimación aprobada para el proyecto o cualquier componente de la estructura de desglose del trabajo o actividad del cronograma.
Véase también estimación.
Presupuesto al finalizar (BAC). La suma de todos los presupuestos establecidos para la obra a realizar. Consulte también el costo real (AC), el valor ganado
(EV), la estimación al finalizar (EAC), la estimación hasta completar (ETC) y el valor planificado (PV).
Costo presupuestado del trabajo realizado (BCWP). Ver valor ganado (EV).
Cuadro de incendio. Una representación gráfica del trabajo restante frente al tiempo que queda en una caja de tiempo.
Calendario. Define períodos en los que el trabajo puede o no ocurrir durante un proyecto y la duración del período de trabajo, las vacaciones y las excepciones.
Biblioteca de calendarios. Ver calendario de actividades y calendario de recursos.
Unidad de Calendario. La unidad de tiempo más pequeña utilizada en la programación del proyecto. Las unidades de calendario son generalmente horas, días
o semanas, pero también pueden ser trimestres, meses, turnos o incluso minutos.
Cambio de control. Un proceso mediante el cual se identifican, documentan, aprueban o rechazan las modificaciones a los documentos, entregables o líneas
base asociadas con el proyecto.
Identificador de solicitud de cambio. El valor de clave principal para elementos en el registro de cambios de programa en relación con el modelo de programación.
Componente. Una parte constituyente, elemento o pieza de un todo complejo.
Restricción. Un factor que limita las opciones para gestionar un proyecto, programa, cartera o proceso.
Control. Comparar el desempeño real con el desempeño planificado, analizar variaciones, evaluar tendencias para efectuar mejoras en el proceso, evaluar
posibles alternativas y recomendar acciones correctivas apropiadas según sea necesario.
Control de cuenta. Un punto de control de gestión donde el alcance, el presupuesto, el costo real y el cronograma se integran y se comparan con el valor
ganado para la medición del desempeño.
Identificación de la cuenta de control. Un identificador alfanumérico de contabilidad de costos normalmente asignado en la intersección de la estructura de
desglose del trabajo y la estructura de desglose de la organización en el nivel en el que se recopilarán los costos. Las cuentas de control contienen paquetes de
trabajo.
Administrador de cuentas de control (CAM). Una designación alfanumérica de la persona única responsable de los costos y el logro del alcance del trabajo
identificado por la cuenta de control; este puede ser el nombre de un individuo o una referencia única que identifique al individuo.
Acción correctiva. Una actividad intencional que realinea el desempeño del trabajo del proyecto con el plan para la dirección del proyecto.
177
Costo. El valor monetario o precio de una actividad o componente del proyecto que incluye el valor monetario de los recursos necesarios para realizar y
completar la actividad o componente, o para producir el componente. Un costo específico puede estar compuesto por una combinación de componentes de
costos que incluyen horas de mano de obra directa, otros costos directos, horas de mano de obra indirecta, otros costos indirectos y el precio de compra.
(Sin embargo, en la metodología de gestión del valor ganado, en algunos casos, el término costo puede representar solo horas de trabajo sin conversión a
valor monetario). Consulte también costo real (AC) y estimación.
Línea base de costos. La versión aprobada de las estimaciones de costos del paquete de trabajo y la reserva para contingencias que se pueden modificar
mediante procedimientos formales de control de cambios y se utiliza como base para la comparación con los resultados reales. Véase también línea de base
y programar la línea de base.
Índice de rendimiento de costes (IPC). Una medida de la rentabilidad de los recursos presupuestados expresada como la relación entre el valor ganado y
el costo real. Consulte también el índice de rendimiento del cronograma (SPI).
Tipo de costo. Una subdivisión del costo, como costo directo, costo indirecto y tarifa.
Variación de Costo (CV). La cantidad de déficit o superávit presupuestario en un momento dado, expresada como la diferencia entre el valor ganado y el
costo real. Véase también variación de programación (SV).
chocando Una técnica de compresión del cronograma que se utiliza para acortar la duración del cronograma con el menor costo incremental mediante la
adición de recursos. Véase también seguimiento rápido y compresión de programación.
Criterios. Normas, reglas o pruebas en las que se puede basar un juicio o decisión, o mediante las cuales se puede evaluar un producto, servicio, resultado
o proceso.
Actividad crítica. Cualquier actividad del cronograma en una ruta crítica en el cronograma de un proyecto o mediante el uso de calendarios, recursos o
restricciones que es fundamental para algún artefacto que no sea la ruta crítica.
Enfoque de Cadena Crítica. Un método de programación que permite al equipo del proyecto colocar amortiguadores en cualquier ruta de programación del
proyecto para tener en cuenta los recursos limitados y las incertidumbres del proyecto.
Camino critico. La secuencia de actividades que representa el camino más largo a través de un proyecto, que determina la duración más corta posible.
Véase también actividad de ruta crítica y método de ruta crítica.
Actividad de ruta crítica. Cualquier actividad en la ruta crítica en el cronograma de un proyecto. Véase también ruta crítica y método de ruta crítica.
Método del camino crítico. Un método utilizado para estimar la duración mínima del proyecto y determinar la cantidad de flexibilidad de programación en
las rutas de la red dentro del modelo de programación. Véase también ruta crítica.
Fecha de finalización actual. La estimación actual del momento en el que se completará una actividad del cronograma, donde la estimación refleja cualquier
progreso del trabajo informado. Consulte también la fecha de finalización programada.
178 Glosario
Fecha de inicio actual. La estimación actual del momento en que comenzará una actividad del cronograma, donde la estimación refleja cualquier progreso del
trabajo informado. Consulte también la fecha de inicio programada.
Cliente. La persona u organización que utilizará el producto, servicio o resultado del proyecto. Véase también usuario.
Fecha de datos (DD). Un momento en el que se registra el estado del proyecto.
Fecha. Término que representa el día, mes y año de un calendario y, en algunos casos, la hora del día.
Descomponer. Ver descomposición.
Descomposición. Una técnica utilizada para dividir y subdividir el alcance del proyecto y los entregables del proyecto en partes más pequeñas y manejables.
Definir actividades. El proceso de identificar las actividades específicas del cronograma que deben realizarse para producir los diversos entregables del
proyecto.
Definición de Hecho (DoD). La lista de verificación de un equipo de todos los criterios que deben cumplirse para que un entregable pueda considerarse listo
para el uso del cliente.
Entregable. Cualquier producto, resultado o capacidad único y verificable para realizar un servicio que se produce para completar un proceso, fase o proyecto.
Dependencia. Véase relación lógica.
Desarrollar horario. El proceso de analizar las secuencias de actividades del cronograma, las duraciones de las actividades del cronograma, los requisitos de
recursos y las restricciones del cronograma para crear el cronograma del proyecto.
Disciplina. Un campo de trabajo que requiere un conocimiento específico que tiene un conjunto de reglas que rigen la conducta laboral (por ejemplo, ingeniería
mecánica, programación de computadoras, estimación de costos, etc.).
Documento. Un medio y la información grabada en él que generalmente tiene permanencia y puede ser leído por una persona o una máquina. Los ejemplos
incluyen planes de gestión de proyectos, especificaciones, procedimientos, estudios y manuales.
Recursos de conducción. Recursos que se considera que tienen un impacto directo en la duración de la actividad durante la nivelación de recursos.
Duración. El número total de períodos de trabajo requeridos para completar una actividad o proyecto, expresado en horas, días o semanas. Por lo general,
calificado por uno de los siguientes: real, línea de base, actual, original, restante, programado o objetivo.
Véase también esfuerzo.
Duración Porcentaje completado. Vea el porcentaje completado de la duración de la actividad y el porcentaje completado de la duración del proyecto.
179
Fecha de finalización anticipada. En el método de la ruta crítica, el momento más temprano posible en el que las partes incompletas de una actividad del
cronograma pueden terminar según la lógica de la red del cronograma, la fecha de los datos y cualquier restricción del cronograma.
Véase también fecha de inicio anticipada, fecha de finalización tardía, fecha de inicio tardía y análisis de red de programación.
Fecha de inicio temprano. En el método de la ruta crítica, el momento más temprano posible en el que las partes incompletas de una actividad del cronograma
pueden comenzar según la lógica de la red del cronograma, la fecha de los datos y cualquier restricción del cronograma. Véase también fecha de finalización
anticipada, fecha de finalización tardía, fecha de inicio tardía y análisis de red de programación.
Horario ganado. Una técnica de valor ganado que mide el momento en que el valor planificado es igual al valor ganado.
Valor Ganado (EV). La medida del trabajo realizado expresada en términos del presupuesto autorizado para ese trabajo.
Consulte también el costo real (AC), el presupuesto al finalizar (BAC), el estimado al finalizar (EAC), el estimado hasta completar (ETC) y el valor planificado
(PV).
Técnica de Valor Ganado (EVT). Una técnica específica para medir el rendimiento del trabajo para un componente de la estructura de desglose del trabajo,
una cuenta de control o un proyecto. También se conoce como reglas de obtención y método de acreditación. Consulte también costo real (AC), estimación al
finalizar (EAC) y estimación para completar (ETC).
Esfuerzo. El número de unidades de mano de obra requeridas para completar una actividad del cronograma o un componente de la estructura de desglose
del trabajo, a menudo expresado en horas, días o semanas. Véase también duración.
Estimar. Una evaluación cuantitativa de la cantidad o resultado probable, que generalmente se aplica a los costos, recursos, esfuerzos y duraciones del
proyecto, generalmente está precedida por un modificador (es decir, preliminar, conceptual, factibilidad, orden de magnitud, definitivo) y debe incluya siempre
alguna indicación de precisión (p. ej., ± x %).
Estimar la duración de las actividades. El proceso de estimar el número de períodos de trabajo que se necesitan para completar las actividades individuales
del cronograma.
Estimar los recursos de la actividad. El proceso de estimar los tipos y cantidades de recursos requeridos para realizar cada actividad del cronograma.
Estimación al Finalizar (EAC). El costo total esperado de completar todo el trabajo expresado como la suma del costo real hasta la fecha y el estimado para
completar. Véase también costo real (AC), presupuesto al finalizar (BAC), valor ganado (EV),
estimación para completar (ETC) y valor planificado (PV).
Estimación para completar (ETC). El costo esperado para terminar todo el trabajo restante del proyecto. Consulte también el costo real (AC), el presupuesto
al finalizar (BAC), el valor ganado (EV), el estimado al finalizar (EAC) y el valor planificado (PV).
Fecha de finalización prevista. Una restricción de fecha colocada en las fechas de finalización temprana y tardía de una actividad del cronograma en curso
que afecta cuándo se puede programar la finalización de la actividad del cronograma y, por lo general, tiene la forma de una fecha impuesta fija. Véase también
fecha de finalización y fecha de finalización del proyecto.
180 Glosario
Seguimiento rápido. Una técnica de compresión del cronograma en la que las actividades o fases que normalmente se realizan en secuencia se realizan en
paralelo durante al menos una parte de su duración. Véase también fallar y programar la compresión.
Fecha de finalización. Un punto en el tiempo asociado con la finalización de una actividad del cronograma. Por lo general, calificado por uno de los siguientes:
real, de referencia, actual, anticipado, esperado, tardío, obligatorio, original, programado o objetivo. Véase también fecha de finalización del proyecto.
Véase también fecha de finalización del proyecto.
Terminar no antes de. Una restricción del cronograma colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad del
cronograma y generalmente tiene la forma de una fecha impuesta fija
Terminar no más tarde de. Una restricción del cronograma colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad del
cronograma y generalmente tiene la forma de una fecha impuesta fija.
Finalizar en. Una restricción de fecha colocada en la actividad del cronograma que requiere que la actividad del cronograma finalice en una fecha específica.
Final a Final. Una relación lógica en la que una actividad sucesora no puede terminar hasta que haya terminado una actividad predecesora. Consulte también
relación de fin a comienzo, de comienzo a fin, de comienzo a comienzo y lógica.
Fin a Inicio. Una relación lógica en la que una actividad sucesora no puede terminar hasta que haya terminado una actividad predecesora. Consulte también
relación de fin a comienzo, de comienzo a fin, de comienzo a comienzo y lógica.
Flotar. También conocido como holgura. Véase también flotación libre (FF) y flotación total (TF).
Pronósticos. Estimaciones o predicciones de condiciones y eventos en el futuro del proyecto con base en la información y el conocimiento disponible en el
momento del pronóstico. Los pronósticos se actualizan y vuelven a emitir en función de la información de rendimiento del trabajo proporcionada a medida que
se ejecuta el proyecto.
Pase adelantado. Una técnica del método de la ruta crítica para calcular las fechas de inicio anticipado y finalización anticipada trabajando hacia adelante a
través del modelo de cronograma desde la fecha de inicio del proyecto o un punto dado en el tiempo. Véase también pase hacia atrás.
Flotación libre. La cantidad de tiempo que se puede retrasar una actividad del cronograma sin retrasar la fecha de inicio temprano de cualquier sucesor o
violar una restricción del cronograma. Véase también flotación total, ruta crítica y ruta casi crítica.
Grafico. Una pantalla gráfica visual que usa líneas y formas para representar valores de datos, como el estado del proyecto o información de pronóstico.
Actividad de hamacas. Una actividad cuya duración se agrega mediante relaciones lógicas de un grupo de actividades relacionadas dentro del modelo de
programación. Véase también actividad de resumen.
Fecha Impuesta. Una fecha fija impuesta a una actividad del cronograma o un hito del cronograma, generalmente en forma de una fecha de "inicio no antes
de" y "finalización no después de".
Aporte. Cualquier elemento, ya sea interno o externo al proyecto, que es requerido por un proceso antes de que dicho proceso continúe.
181
Integrado. Componentes interrelacionados, interconectados, entrelazados o entrelazados combinados y unificados en un todo funcional o unificado.
Iteración. Un ciclo de desarrollo de un producto o entregable con un límite de tiempo en el que se realiza todo el trabajo necesario para entregar valor.
Cartera de iteraciones. Una lista ordenada de requisitos centrados en el usuario que un equipo mantiene para una iteración.
Tablero Kanban. Una herramienta de visualización que permite mejorar el flujo de trabajo al hacer visibles los cuellos de botella y las cantidades de trabajo.
Método Kanban. Un método ágil inspirado en el sistema de control de inventario Kanban original y utilizado específicamente para el trabajo de conocimiento.
Retraso. La cantidad de tiempo por el cual una actividad sucesora se retrasará con respecto a una actividad predecesora.
Véase también plomo.
Fecha de finalización tardía. En el método de la ruta crítica, el último momento posible en el que las partes incompletas de una actividad del cronograma pueden
terminar según la lógica de la red del cronograma, la fecha de finalización del proyecto y cualquier restricción del cronograma. Véase también fecha de finalización
anticipada, fecha de inicio anticipada, fecha de inicio tardía y análisis de red de programación.
Fecha de inicio tardía. En el método de la ruta crítica, el último momento posible en el que las partes incompletas de una actividad del cronograma pueden
comenzar según la lógica de la red del cronograma, la fecha de finalización del proyecto y cualquier restricción del cronograma. Véase también fecha de finalización
anticipada, fecha de inicio anticipada, fecha de finalización tardía y análisis de red de programación.
Guiar. La cantidad de tiempo por el cual una actividad sucesora puede adelantarse con respecto a una actividad predecesora.
Véase también retraso.
Lecciones aprendidas. El conocimiento obtenido durante un proyecto que muestra cómo se abordaron o deberían abordarse los eventos del proyecto en el futuro
con el fin de mejorar el desempeño futuro.
Nivel de esfuerzo. Una actividad que no produce productos finales definitivos y se mide por el paso del tiempo.
Arrasamiento. Ver nivelación de recursos.
Lógica. Ver lógica de red.
Diagrama de lógica. Consulte el diagrama de red del cronograma del proyecto.
Relación lógica. Una dependencia entre dos actividades o entre una actividad y un hito. Consulte también de fin a fin, de fin a comienzo, de comienzo a fin y de
comienzo a comienzo.
182 Glosario
Programa maestro. Un cronograma del proyecto a nivel de resumen que identifica los principales entregables, los componentes de la estructura de desglose del
trabajo y los hitos clave del cronograma. Véase también calendario de hitos.
Metodología. Un sistema de prácticas, técnicas, procedimientos y reglas utilizadas por quienes trabajan en una disciplina.
Hito. Un punto o evento significativo en un proyecto, programa o carpeta.
Calendario de hitos. Un tipo de cronograma que presenta hitos con fechas planificadas.
Duración más probable. Una estimación de la duración más probable de la actividad que tiene en cuenta todas las variables conocidas que podrían afectar el
rendimiento. Véase también duración optimista y duración pesimista.
Camino casi crítico. Una secuencia de actividades con flotación baja que, si se agota, se convierte en una secuencia de ruta crítica para el proyecto. Véase
también ruta crítica, flotación libre y flotación total.
La red. Consulte el diagrama de red del cronograma del proyecto.
Análisis de red. Ver análisis de red de cronograma.
Lógica de red. Todas las dependencias de actividad en un diagrama de red de cronograma de proyecto. Véase también fecha de finalización anticipada, fecha de
inicio anticipada, fecha de finalización tardía, fecha de inicio tardía y ruta de red.
Nodo. Un punto en el que las líneas de dependencia se conectan en un diagrama de red de programación. Véase también método de diagramación de precedencia
(PDM).
Período no laboral. Una fecha, o parte de una fecha, identificada como un tiempo para no realizar el trabajo, incluidos los días festivos designados.
Final abierto. Una actividad sin predecesor, sucesor o ambos.
Duración optimista. Una estimación de la duración más corta de la actividad que tiene en cuenta todas las variables conocidas que podrían afectar el rendimiento.
Véase también duración más probable y duración pesimista.
Organización. Un grupo de personas organizadas para algún propósito o para realizar algún tipo de trabajo dentro de una empresa.
Duración original. La duración de la actividad originalmente asignada a una actividad del cronograma y no actualizada a medida que se informa sobre el progreso
de la actividad. Normalmente se usa para comparar con la duración real y la duración restante cuando se informa sobre el progreso del cronograma.
Producción. Un producto, resultado o servicio generado por un proceso. Puede ser una entrada para un proceso sucesor.
Porcentaje completo (PC o PCT). Una estimación expresada como un porcentaje de la cantidad de trabajo que se ha completado en una actividad o en un
componente de la estructura de desglose del trabajo.
183
Duración pesimista. Una estimación de la duración más larga de la actividad que tiene en cuenta todas las variables conocidas que podrían afectar el
rendimiento. Véase también duración más probable y duración optimista.
Fase. Véase también fase del proyecto.
Progreso del Trabajo Físico. La cantidad de trabajo físicamente completado en el proyecto o tarea.
Duración prevista. Ver duración original de la actividad y duración original del proyecto.
Fecha de finalización planificada (PF). Ver fecha de finalización prevista.
Fecha de inicio planificada (PS). Ver fecha de inicio programada.
Valor planificado (PV). El presupuesto autorizado asignado a los trabajos programados. Consulte también el costo real (AC), el presupuesto al finalizar
(BAC), el valor ganado (EV), el estimado al finalizar (EAC) y el estimado para completar (ETC).
Práctica. Tipo específico de actividad profesional o de gestión que contribuye a la ejecución de un proceso y que puede emplear una o más técnicas y
herramientas.
Método de diagramación de precedencia (PDM). Una técnica utilizada para construir un modelo de cronograma en el que las actividades están
representadas por nodos y están vinculadas gráficamente por una o más relaciones lógicas para mostrar la secuencia en la que se realizarán las actividades.
Véase también diagrama de red de programación de nodos y proyectos.
Relación de precedencia. El término utilizado en el método de diagramación de precedencia para una relación lógica. Véase también relación lógica.
Actividad predecesora. Una actividad que lógicamente viene antes de una actividad dependiente en un cronograma. Véase también actividad sucesora y
actividad resumida.
Presentación. Una salida de una instancia de modelo de programación que presenta la información basada en el tiempo requerida por el plan de
comunicación, incluidas las actividades con fechas planificadas, duraciones, fechas de hitos y asignación de recursos.
Procedimiento. Una serie de pasos seguidos en un orden regular y definitivo para lograr algo.
Proceso. Un conjunto de acciones y actividades interrelacionadas realizadas para lograr un conjunto específico de productos, resultados o servicios.
Producto. Un artefacto que se produce, es cuantificable y puede ser un artículo final en sí mismo o un artículo componente. También conocido como
materiales y bienes. Contrasta con resultado y servicio. Véase también entregable.
Pila de Producto. Una lista ordenada de requisitos centrados en el usuario que un equipo mantiene para un producto.
Anulación de progreso. Programar el cálculo que ignora las relaciones lógicas y permite que las actividades con progreso continúen incluso si las
relaciones lógicas de los predecesores no se han satisfecho.
184 Glosario
Elaboración progresiva. El proceso iterativo de aumentar el nivel de detalle en un plan de gestión de proyectos a medida que se dispone de mayores cantidades de información
y estimaciones más precisas.
Proyecto. Un esfuerzo temporal emprendido para crear un producto, servicio o resultado único.
Duración real del proyecto. El número total de períodos de trabajo en unidades de calendario entre la fecha de inicio real del proyecto y la fecha de datos de la instancia del
modelo de cronograma, si el proyecto está en progreso, o la fecha de finalización real del proyecto, si el proyecto está completo. Véase también duración real.
Fecha de finalización real del proyecto. El punto en el tiempo asociado con la fecha de finalización real de la actividad de la última actividad del cronograma en el proyecto.
Véase también fecha de finalización real.
Fecha de inicio real del proyecto. El punto en el tiempo asociado con la fecha de inicio real de la actividad de la primera actividad del cronograma en el proyecto. Véase
también fecha de inicio real.
Fecha de inicio del proyecto. Ver fecha de inicio del proyecto.
Calendario de proyectos. Un calendario que identifica los días laborables y los turnos que están disponibles para las actividades programadas.
Fecha de finalización del proyecto. Ver fecha de finalización del proyecto.
Ruta crítica del proyecto. La ruta de red de programación más larga desde la fecha de inicio del proyecto o la fecha de datos del proyecto actual hasta la fecha de finalización
del proyecto. Véase también ruta crítica.
Fecha de finalización actual del proyecto. Consulte la fecha de finalización actual, la fecha de finalización de la línea base del proyecto y la fecha de finalización programada del proyecto.
Fecha de inicio actual del proyecto. Consulte la fecha de inicio actual, la fecha de inicio de la línea base del proyecto y la fecha de inicio programada del proyecto.
Descripción del Proyecto. Resumen narrativo documentado del enunciado del alcance del proyecto.
Duración del proyecto. El número total de períodos de trabajo, en unidades de calendario, entre la fecha de inicio anticipada del proyecto y la fecha de finalización anticipada
del proyecto. Véase también duración (DU o DUR).
Proyecto Duración Porcentaje completado. Una estimación expresada como el porcentaje que la duración real del proyecto es de la duración total del proyecto para un
proyecto que tiene trabajo en progreso.
Fecha de finalización anticipada del proyecto. El punto más temprano posible en el tiempo asociado con la finalización de la última actividad del cronograma del proyecto.
Véase también fecha de finalización anticipada.
Fecha de inicio anticipado del proyecto. El punto más temprano posible en el tiempo asociado con el comienzo de la primera actividad del cronograma del proyecto. Véase
también fecha de inicio temprano.
Fecha de finalización del proyecto. El punto en el tiempo establecido por la fecha de finalización tardía del proyecto según lo determinado por un análisis de red de
programación o según lo establecido por una restricción de finalización del proyecto. También conocida como fecha de finalización del proyecto.
185
Restricción de finalización del proyecto. Una limitación o restricción impuesta a la fecha de finalización tardía del proyecto que afecta cuándo
debe finalizar el proyecto y, por lo general, tiene la forma de una fecha impuesta fija.
Fecha de finalización del proyecto. Un punto en el tiempo asociado con la finalización de la última actividad del cronograma en un proyecto. Por
lo general, calificado por uno de los siguientes: real, de referencia, actual, anticipado, esperado, tardío, obligatorio, original, programado o objetivo.
Véase también fecha de finalización.
Identificador del proyecto. Una identificación breve, numérica o de texto única asignada a cada proyecto para diferenciar un proyecto en particular
de otros proyectos en un programa.
Fecha de finalización tardía del proyecto. El último punto posible en el tiempo asociado con la finalización de la última actividad del cronograma
del proyecto.
Fecha de inicio tardío del proyecto. El último punto posible en el tiempo asociado con el comienzo de la primera actividad del cronograma del
proyecto.
Plan de gestión de proyectos. El documento que describe cómo se ejecutará, monitoreará, controlará y cerrará el proyecto.
Equipo de gestión de proyectos. Los miembros del equipo del proyecto que están directamente involucrados en las actividades de gestión del
proyecto. En algunos proyectos más pequeños, el equipo de gestión del proyecto puede incluir prácticamente a todos los miembros del equipo del
proyecto.
Gerente de proyecto. La persona asignada por la organización ejecutora para liderar el equipo responsable de lograr los objetivos del proyecto.
Nombre del proyecto. Una frase corta o etiqueta para cada proyecto, utilizada junto con el identificador del proyecto, para diferenciar un proyecto
en particular de otros proyectos en un programa. También conocido como título del proyecto.
Fase del proyecto. Una colección de actividades del proyecto relacionadas lógicamente que culmina en la finalización de uno o más entregables.
Porcentaje físico del proyecto completado. Un cálculo, expresado como porcentaje, de la cantidad de trabajo que se ha completado en el
proyecto, medido en términos de avance del trabajo físico.
Fecha de finalización prevista del proyecto. Consulte también la fecha de finalización programada del proyecto.
Fecha de inicio planificada del proyecto. Consulte también la fecha de inicio programada del proyecto.
Duración restante del proyecto. El número total de períodos de trabajo, en unidades de calendario, entre la fecha de datos del modelo de
programación y la fecha de finalización anticipada del proyecto de un proyecto que tiene al menos una fecha de inicio real de actividad. Esto
representa el tiempo necesario para completar un proyecto donde el trabajo está en progreso. Véase también duración restante (RD).
186 Glosario
Fecha de finalización del nivel de recursos del proyecto. El punto en el tiempo asociado con la fecha de finalización programada de la última actividad de una actividad del
cronograma con recursos limitados en un cronograma con recursos limitados.
Fecha de inicio nivelada de recursos del proyecto. El punto en el tiempo asociado con la fecha de inicio programada de la primera actividad de una actividad del cronograma
con recursos limitados en un cronograma con recursos limitados.
Cronograma del proyecto. Salida de un modelo de programación que presenta actividades vinculadas con fechas planificadas, duraciones, hitos y recursos.
Gestión del cronograma del proyecto. La gestión del cronograma del proyecto incluye los procesos necesarios para gestionar la finalización oportuna del proyecto.
Fecha de finalización programada del proyecto. Consulte la fecha de finalización actual y la fecha de finalización programada.
Fecha de inicio programada del proyecto. Ver la fecha de inicio actual y la fecha de inicio programada.
Alcance del proyecto. El trabajo realizado para entregar un producto, servicio o resultado con las características y funciones especificadas.
Enunciado del alcance del proyecto. La descripción del alcance del proyecto, los principales entregables, los supuestos y las limitaciones.
Patrocinador de proyecto. Ver patrocinador.
Interesado del proyecto. Ver parte interesada.
Restricción de inicio del proyecto. Una limitación o restricción impuesta a la fecha de inicio anticipada del proyecto que afecta cuándo debe comenzar el proyecto y
generalmente tiene la forma de una fecha impuesta fija.
Fecha de inicio del proyecto. Un punto en el tiempo asociado con el inicio de la primera actividad del cronograma en un proyecto. Por lo general, calificado por uno de los
siguientes: real, de referencia, actual, anticipado, esperado, tardío, obligatorio, original, programado o objetivo.
Véase también fecha de inicio.
Grupo de proyecto. Todos los miembros del equipo del proyecto, incluido el equipo de gestión del proyecto, el director del proyecto y, en algunos proyectos, el patrocinador
del proyecto.
Miembros del equipo del proyecto. Las personas que reportan directa o indirectamente al gerente del proyecto y que son responsables de realizar el trabajo del proyecto
como parte regular de sus deberes asignados.
Gestión del tiempo del proyecto. Consulte Gestión del cronograma del proyecto.
Título del Proyecto. Ver nombre del proyecto.
Duración total del proyecto. El número total de períodos de trabajo, en unidades de calendario, para completar un proyecto. Para un proyecto en curso, incluye la duración
real del proyecto más la duración restante del proyecto.
187
Proyecto de Trabajo. Ver trabajo.
Línea de relación. Una línea de relación lógica dibujada dentro de un diagrama de red del cronograma del proyecto desde una actividad del cronograma a una
o más actividades del cronograma que indica el tipo de relación lógica por la posición relativa de los puntos inicial y final de la línea.
Duración restante (RD). El tiempo, en unidades de calendario, que es (a) igual a la duración original de una actividad que no ha comenzado o (b) entre la fecha
de los datos del cronograma del proyecto y la fecha de finalización de una actividad del cronograma que tiene una fecha de inicio real . Esto representa el tiempo
necesario para completar una actividad del cronograma donde el trabajo está en progreso.
Véase también duración restante de la actividad y duración restante del proyecto.
Requisito. Una condición o capacidad que debe cumplir o poseer un sistema, producto, servicio, resultado o componente para satisfacer un contrato, estándar,
especificación u otros documentos formalmente impuestos.
Recurso. Recursos humanos calificados (disciplinas específicas, ya sea individualmente o en cuadrillas o equipos), equipos, servicios, suministros, productos
básicos, presupuestos o fondos.
Asignación de recursos. La vinculación de uno o más recursos a una actividad del cronograma y la identificación de la cantidad de cada recurso que se necesita
para realizar el trabajo en esa actividad del cronograma.
Atributos de recursos. Múltiples atributos asociados con cada recurso que se pueden incluir dentro de la biblioteca de recursos, como identificador de recurso,
nombre de recurso, tipo de recurso, disponibilidad de recurso, tasa de recurso, código de recurso, restricciones y suposiciones.
Disponibilidad de recursos. Las fechas y el número de períodos de trabajo, en unidades de calendario, en los que un recurso determinado está disponible de
acuerdo con el calendario de recursos adecuado.
Calendario de recursos. Un calendario que identifica los días hábiles y los turnos en los que está disponible cada recurso específico.
Calendario de recursos limitados. Consulte el cronograma de recursos limitados.
Diccionario de recursos. Ver biblioteca de recursos.
Identificador de recursos. Una identificación breve, numérica o de texto única asignada a cada recurso específico para diferenciar ese recurso de otros recursos.
Retraso de recursos. El número de unidades de calendario que un recurso debe esperar después de la fecha de inicio de la actividad antes de comenzar a
trabajar en la actividad del cronograma.
Nivelación de recursos. Técnica de optimización de recursos en la que se realizan ajustes en el cronograma del proyecto para optimizar la asignación de
recursos y que pueden afectar la ruta crítica.
188 Glosario
Biblioteca de recursos. Una tabulación documentada que contiene la lista completa, incluidos los atributos de los recursos, de todos los recursos que se
pueden asignar a las actividades del proyecto. También conocido como diccionario de recursos.
Calendario de recursos limitados. Un cronograma de proyecto cuya actividad de cronograma, fechas de inicio programadas y fechas de finalización
programadas reflejan la disponibilidad de recursos esperada. También conocido como calendario con recursos limitados. Véase también nivelación de
recursos.
Nombre del recurso. Una frase o etiqueta corta para cada recurso que se usa junto con un identificador de recurso para diferenciar ese recurso de otros
recursos, por ejemplo, por tipo, función o persona.
Tasa de recursos. La tasa de costo unitario asignada a un recurso específico, incluidos los aumentos de tasa conocidos.
Tipo de recurso. Una designación única que diferencia un recurso por habilidades, capacidades u otros atributos.
Resultado. Un resultado de la realización de procesos y actividades de gestión de proyectos. Contrasta con producto y servicio.
Véase también entregable.
Lógica retenida. Un cálculo de programación que requiere que una actividad fuera de secuencia no pueda reanudarse hasta que se hayan satisfecho
todas las relaciones lógicas de los predecesores.
Role. Una función definida que debe realizar un miembro del equipo del proyecto, como probar, archivar, inspeccionar o codificar.
Planificación ola de rodadura. Una técnica de planificación iterativa en la que el trabajo que se realizará a corto plazo se planifica en detalle, mientras
que el trabajo futuro se planifica a un nivel superior.
Calendario. Ver cronograma del proyecto y modelo de cronograma.
Programar Actividad. Un componente discreto y programado del trabajo realizado durante el transcurso de un proyecto. Véase también actividad.
Análisis de horarios. Véase también programar análisis de red.
Programar línea de base. La versión aprobada de un modelo de cronograma que se puede cambiar utilizando procedimientos formales de control de
cambios y se usa como base para la comparación con los resultados reales. Véase también línea base y línea base de medición del desempeño.
Fecha de finalización programada. El punto en el tiempo cuando el trabajo estaba programado para terminar en una actividad del cronograma. También conocida como fecha
de finalización planificada. Consulte también la fecha de finalización programada de la actividad, la fecha de finalización actual y la fecha de finalización programada del proyecto.
Fecha de inicio programada. El momento en el que se programó el inicio del trabajo en una actividad programada. También conocida como fecha de
inicio planificada. Consulte también la fecha de inicio programada de la actividad, la fecha de inicio actual y la fecha de inicio programada del proyecto.
189
Nivel de horario. Una regla especificada por el equipo del proyecto para la granularidad relativa de las actividades del cronograma en el modelo de cronograma
general.
Programar hito. Un evento importante en el cronograma del proyecto, como un evento que restringe el trabajo futuro o marca la finalización de un entregable
principal. También conocida como actividad de hitos. Véase también hito.
Modelo de horario. Una representación del plan para ejecutar las actividades del proyecto, incluidas las duraciones, las dependencias y otra información de
planificación, que se utiliza para producir una programación del proyecto junto con otros artefactos de programación. Consulte también el análisis del modelo
de cronograma.
Análisis del modelo de cronograma. Un proceso que se utiliza para investigar o analizar la salida del modelo de cronograma con el fin de optimizar el
cronograma. Véase también modelo de horario.
Programar instancia de modelo. Una versión del modelo de programación que ha sido procesada por una herramienta de programación y ha reaccionado a
las entradas y ajustes realizados a los datos específicos del proyecto dentro de la herramienta de programación (ciclo de actualización completado), que se
guarda para registro y referencia, como la fecha de los datos versión, modelos de cronograma de destino y el modelo de cronograma de referencia.
Programar análisis de red. Una técnica para identificar fechas de inicio tempranas y tardías, así como fechas de finalización tempranas y tardías, para las
partes incompletas de las actividades del proyecto. Véase también fecha de finalización anticipada, fecha de inicio anticipada, fecha de finalización tardía y
fecha de inicio tardía.
Índice de rendimiento del cronograma (SPI). Una medida de la eficiencia del cronograma expresada como la relación entre el valor ganado y el valor
planificado. Véase también índice de rendimiento de costes (IPC).
Variación de horario (SV). Una medida del rendimiento del cronograma expresada como la diferencia entre el valor ganado y el valor planeado. Ver también
variación de costos (CV).
Enfoque de programación. Un sistema de prácticas, técnicas, procedimientos y reglas que utilizan los programadores de programación de proyectos. Esta
metodología se puede realizar de forma manual o con un software de gestión de proyectos utilizado específicamente para la programación.
Herramienta de programación. Una herramienta que proporciona nombres de componentes de programación, definiciones, relaciones estructurales y
formatos para respaldar la aplicación de un método de programación.
Alcance. La suma de los productos, servicios y resultados a ser proporcionados como proyecto. Véase también alcance del proyecto y alcance del producto.
Melé. Un marco ágil para desarrollar y mantener productos complejos con roles, eventos y artefactos específicos.
Secuencia de actividades. El proceso de identificar y documentar las relaciones entre las actividades del proyecto.
190 Glosario
Servicio. Trabajo útil realizado que no produce un producto o resultado tangible, como realizar cualquiera de las funciones comerciales que respaldan la
producción o la distribución. Contraste con producto y resultado. Véase también entregable.
Flojo. Ver flotación total (TF) y flotación libre (FF).
Ruta crítica especificada. La secuencia más larga de actividades del cronograma en una ruta de red de cronograma especificada por un miembro del
equipo del proyecto. Véase también ruta crítica.
Patrocinador. Un individuo o un grupo que proporciona recursos y apoyo para el proyecto, programa o cartera, y es responsable de permitir el éxito.
Véase también parte interesada.
Interesado. Un individuo, grupo u organización que puede afectar, ser afectado o percibirse como afectado por una decisión, actividad o resultado de un
proyecto, programa o cartera. Véase también patrocinador.
Fecha de inicio. Un punto en el tiempo asociado con el inicio de una actividad del cronograma. Por lo general, calificado por uno de los siguientes: real,
de referencia, actual, anticipado, esperado, tardío, obligatorio, original, programado o objetivo. Véase también fecha de inicio del proyecto.
Empezar no antes de. Una restricción del cronograma colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad
del cronograma y generalmente tiene la forma de una fecha impuesta fija.
Empezar no más tarde de. Una restricción del cronograma colocada en la actividad del cronograma que afecta cuándo se puede programar una
actividad del cronograma y generalmente tiene la forma de una fecha impuesta fija.
Comienza en. Una restricción del cronograma colocada en la actividad del cronograma que afecta cuándo se puede programar una actividad del
cronograma y generalmente tiene la forma de una fecha impuesta fija.
Empezar a acabar. Una relación lógica en la que una actividad sucesora no puede terminar hasta que haya comenzado una actividad predecesora.
Véase también relación de fin a fin, de fin a comienzo, de comienzo a comienzo y lógica.
Comienzo a Comienzo. Una relación lógica en la que una actividad sucesora no puede comenzar hasta que haya comenzado una actividad predecesora.
Véase también relación de fin a fin, de fin a comienzo, de comienzo a comienzo y lógica.
Situación a la fecha. Término cuyo significado para los informes de datos de estado varía según la marca del software de gestión de proyectos utilizado
para la programación, donde en algunos sistemas la fecha de estado se incluye en el pasado y en algunos sistemas la fecha de estado es en el futuro.
Véase también fecha de datos u hora-fecha actual.
subred. Una subdivisión (fragmento) de un diagrama de red del cronograma de un proyecto, que generalmente representa un subproyecto o un paquete
de trabajo. Véase también actividad de resumen.
Subfase. Una subdivisión de una fase.
subproyecto. Una porción más pequeña del proyecto general creada cuando un proyecto se subdivide en componentes o piezas más manejables.
Véase también actividad de resumen.
191
Sucesor. Ver actividad sucesora.
Actividad sucesora. Una actividad dependiente que lógicamente viene después de otra actividad en un horario. Véase también actividad predecesora y
actividad de resumen.
Actividad resumida. Un grupo de actividades de cronograma relacionadas agregadas y mostradas como una sola actividad. Véase también actividad
predecesora y actividad sucesora.
Sistema. Un conjunto integrado de componentes interdependientes o que interactúan regularmente creado para lograr un objetivo definido, con relaciones
definidas y mantenidas entre sus componentes, y el conjunto produce u opera mejor que la simple suma de sus componentes.
Horario objetivo. Un cronograma adoptado con fines de comparación durante el análisis de la red de cronogramas, que puede ser diferente del cronograma
de referencia. Véase también línea de base.
Tarea. Un término para el trabajo cuyo significado y ubicación dentro de un plan estructurado para el trabajo del proyecto varía según el área de aplicación,
la industria y la marca del software de gestión de proyectos.
Miembros del equipo. Ver miembros del equipo del proyecto.
Técnica. Un procedimiento sistemático definido empleado por un recurso humano para realizar una actividad para producir un producto o resultado o
entregar un servicio, y que puede emplear una o más herramientas.
Modelo. Un documento parcialmente completo en un formato predefinido que proporciona una estructura definida para recopilar, organizar y presentar
información y datos.
Estimación de tres puntos. Una técnica utilizada para estimar el costo o la duración mediante la aplicación de un promedio o promedio ponderado de
estimaciones optimistas, pesimistas y más probables cuando existe incertidumbre con las estimaciones de actividades individuales.
Hora Fecha actual. Ver fecha de datos.
Escala de tiempo. Una marca graduada de tiempo lineal, que muestra el tiempo en unidades específicas como horas, días, semanas, meses, trimestres o
años. Las escalas de tiempo pueden mostrar más de una unidad de tiempo. Por lo general, se muestra encima o debajo de los componentes de datos
dentro de un documento o pantalla gráfica electrónica.
Herramienta. Algo tangible, como una plantilla o un programa de software, que se utiliza para realizar una actividad para producir un producto o resultado.
Duración total. Ver duración total de la actividad y duración total del proyecto.
Flotación Total. La cantidad de tiempo que una actividad del cronograma puede retrasarse o extenderse desde su fecha de inicio temprana sin retrasar la
fecha de finalización del proyecto o violar una restricción del cronograma. Véase también flotación libre, ruta crítica y actividad casi crítica.
192 Glosario
Unidad de medida. Una designación del tipo de cantidad que se mide, como horas de trabajo, yardas cúbicas o líneas de código.
Usuario. La persona u organización que utilizará el producto o servicio del proyecto. Véase también cliente.
Diferencia. Una desviación cuantificable, salida o divergencia de una línea de base conocida o un valor esperado.
Umbral de varianza. Un rango predeterminado de resultados normales que se determina durante el proceso de planificación y establece los límites
dentro de los cuales el equipo practica la gestión por excepción.
Extremos abiertos virtuales. Una condición que puede ocurrir cuando faltan las relaciones lógicas adecuadas o cuando se informa sobre el progreso
de una actividad que da como resultado que la actividad ya no tenga ninguna relación de conducción. Reacciona como si no tuviera predecesor o
sucesor.
Trabajar. Esfuerzo físico o mental sostenido, esfuerzo o ejercicio de habilidad para superar obstáculos y lograr un objetivo.
Solución alterna. Una respuesta a un riesgo negativo que ha ocurrido.
Estructura de Desglose del Trabajo (EDT). Una descomposición jerárquica del alcance total del trabajo que debe realizar el equipo del proyecto
para lograr los objetivos del proyecto y crear los entregables requeridos.
Componente de Estructura de Desglose de Trabajo. Una entrada en la estructura de desglose del trabajo que puede estar en cualquier nivel.
Identificador de estructura de desglose de trabajo (WBS ID). Una identificación breve, numérica o de texto única asignada a cada elemento o
componente de la WBS para diferenciar un elemento particular de la WBS de otros elementos de la WBS.
Paquete de trabajo. El trabajo definido en el nivel más bajo de la estructura de desglose del trabajo para el cual se estiman y gestionan el costo y la
duración.
Período de trabajo. Una fecha o parte de una fecha identificada como un tiempo para realizar el trabajo, que puede dividirse en unidades de
calendario como turnos, horas o incluso minutos.
193
ÍNDICE
A desviaciones estándar en, 75–76 actividad de
resumen, 56–57, 83, 134, 192 en WBS, 2, 51

C.A. Ver costo real
Lista de siglas, 171–172

Costo real de la actividad, 98, 172
Actividad, 172
Duración real de la actividad, 98, 172
granularidad de actividad, 50–51
Fecha de finalización real de la actividad, 98, 172
estructura de codificación para, 51
Fecha de inicio real de la actividad, 99, 172
CPM para, 71–72
Calendario de actividades, 99, 173
actividades colgantes, 61 duración
Código de actividad, 99, 173
de, 56, 62 actividad de hamaca,
Categoría de costo de actividad, 100, 173
58, 97, 117, 181
Estimación del costo de la actividad, 100, 173
identificación para, 55, 102
Distribución de riesgo de probabilidad acumulada de actividad, 100
LOE actividades, 57–58, 118 relaciones
Descripción de la actividad, 173
lógicas en, 77–81 redes basadas en lógica
Duración de la actividad, 173
para, 17 márgenes para, 19 hitos y, 3
Porcentaje de duración de la actividad completado, 173
actividades abiertas, 61 actividades abiertas,
Fecha de finalización anticipada de la actividad, 101, 173
77–79 propietarios para, 56 requisitos para, 26
Fecha de inicio temprano de la actividad, 101, 173
–27 recursos y, 30, 61, 83–85 actividad de
Esfuerzo de actividad, 101, 173
secuencia, 59–61, 190 software para, 28
ID de actividad, 102, 173
Etiqueta de actividad, 102, 173
Fecha de finalización tardía de la actividad, 102, 173
Fecha de inicio tardío de la actividad, 102, 174
Lista de actividades, 174
195
Actividad duración más probable, 103, 174 Aplicabilidad, 7–8
Nota de actividad/comentario/registro, 103, 174 Enfoques, 2, 13–14, 23, 48. Véase también Método de la ruta crítica; Ciclos
Actividad duración optimista, 104, 174 de vida para modelos de programación, 25–27 herramientas de
Duración original de la actividad, 174 programación para, 9 Aprobación, 64–65 Aprobar, 176 Flecha, 176 Lo
Actividad pesimista duración, 104, 174 más tarde posible, 108 Evaluaciones, 5, 7, 47 para el índice de
Actividad física por ciento completada o duración de la actividad conformidad, 139–140 proceso y, 140– 141 de riesgo, 83–85 para modelos
por ciento completo, 104, 174 de programación, 139
Duración restante de la actividad, 105, 174
Cantidad real del recurso de actividad, 105
Fecha de finalización nivelada de recursos de actividad, 105, 175
Fecha de inicio nivelada de recursos de actividad, 106, 175
Cantidad restante del recurso de actividad, 106
Cantidad total del recurso de actividad, 106
Índice de criticidad del riesgo de actividad, 106, 175
Definición del alcance de la actividad, 107, 175 Asignaciones, 54–55, 63, 67 Tan pronto
Actividad programada fecha de finalización, 175 como sea posible, 108 Asunción, 176
Fecha de inicio programada de la actividad, 175 AT. Ver Automatización en tiempo real,
Fecha de inicio de actividad, 175 56
Duración total de la actividad, 107, 175
Tipo de actividad, 175
Actividad trabajo por ciento completado, 107 B

Costo real (AC), 175
BAC. Consulte Presupuesto al finalizar
Duración real, 62, 74, 120, 175
Atrasos, 35–37, 52–53, 184 Paso hacia
Porcentaje completo de duración real, 175
atrás, 176 Gráfico de barras, 176 Línea de
Fecha de finalización real, 121, 176
base, 55, 67–69, 176 Fecha de línea de
Fecha de inicio real, 121, 176
base, 176 Modelo de programación de línea
Hora real (AT), 86, 88, 107
de base, 108 Comportamiento, para
Datos reales, 67–68
componentes, 95 BIM. Consulte Modelado
Ciclos de vida adaptativos, 11, 12, 21–23, 33
de información de construcción Presupuesto,
Ágil, 12, 31–37, 176
177 Presupuesto al finalizar (BAC), 109, 177 Presupuesto.
como enfoques, 2, 23 para
Consulte Consumo de búfer de costos, 19–20 Ciclos de
presentaciones, 38–43 para diseño
construcción, 32
de productos, 21
Asignación, de recursos, 64
Análisis, 62–64, 83
196 Índice
Modelado de información de construcción (BIM), 27 Índice de rendimiento de costos (CPI), 110, 178 Tipo de
Gráfico de evolución, 38–41, 177 costo, 178 Variación de costos (CV), 110, 178 Porcentaje
Gráfico de quemado, 42 de variación de costos (CV%), 111 CPI. Consulte Índice
de rendimiento de costes CPM. Consulte el método de
C ruta crítica Crashing, 64, 178 CRC. Ver Componentes
básicos requeridos Criterios, 178 Actividad crítica, 178

Cálculos, 94 Calendario,
Enfoque de cadena crítica, 178 Ruta crítica, 111, 178
49–50, 59, 177 Unidad de calendario,
Actividad de ruta crítica, 178 Método de ruta crítica
177 CAM. Véase Gestor de cuentas
(CPM), 1, 71 para actividades, 71–72 Cadenas críticas,
de control Control de cambios, 53, 70, 177
18–21 , 49–50 definiciones para, 178, 191 diagramas de
Identificador de solicitud de cambio, 109, 177
red para, 17–18 relaciones en, 59–61 para modelos de
Estructura de codificación, 51 Comunicación, 43,
programación, 14–18 WBS y, 54 Fecha de finalización
69–70, 88–91 Lista de verificación completa, 81–
actual, 178 Fecha de inicio actual, 179 Cliente, 43, 90,
82 Componente, 1, 93–106, 177 Ver también
179 CV. Ver Variación de costo
Programación de componentes por categoría, 97,
138 evaluación de conformidad de, 139 lista de componentes de
programación, 98–136 nombre, 94 uso de, 138 Notas condicionales,
de componentes, 95 Condiciones, para componentes, 94 Evaluación
de conformidad, 139–141 Índice de conformidad, 1, 5, 137–141
Restricción, 4, 6, 71, 76–77, 177 Control, 177 ID de cuenta de
control, 109, 177 Administrador de cuenta de control (CAM), 110,
177 Componentes básicos necesarios (CRC) , 93–94, 96, 138–141
Acción correctiva, 177 Costo, 172, 175, 178 Entrada EVM, 85–86 Valor
planificado, 86–88 Costo de referencia, 178
CV%. Ver porcentaje de variación de costo
D
Datos
para el tiempo real, 86
para gráfico de quemado, 42
cálculos para, 94 fechas
para, 78–79, 179 elementos,
94–95
EVM como, 85–86
197
formatos, 94, 95 Esfuerzo, 180
requisitos de jerarquía en, 48 desviación Elementos, en formatos de datos, 95
estándar para, 75–76 para WBS, 5 Fecha Tendencias emergentes, 25–27 Usuarios
de datos, 111, 179 Fecha, 179 finales, 36 Ingeniería, 53 Fabricación de
Descomposición, 3, 179 Definir actividades, equipos, 82 ERC. Consulte Componentes
179 Definición de hecho (DoD), 179 necesarios para EVM ES. Consulte
Dependencias, 36 –37 Planificación detallada, Programación ganada ESM. Consulte Gestión de
23–24, 66 Modelos de programación programación ganada Estimación, 180 Estimar
deterministas, 62 Desarrollar programación, duraciones de actividad, 180 Estimar recursos de actividad,
179 Desviaciones, 68 Disciplina, 179 180 Estimar al finalizar (EAC), 113, 180 Duración estimada
Documento, 179 Recurso impulsor, 112, 179 (ED), 114 Estimar para completar (ETC), 114, 180 Estimar
Duración, 179. Véase también Componentes de para completar el tiempo (ETC) (t)), 114, 180 Estimaciones,
programación de actividades, 56, 62 Reales y , 61–62, 74–76, 180, 192 ETC. Ver Estimación para
67–68 duración más probable, 74–75 duración completar ETC(t). Ver Estimación para completar el tiempo
optimista, 74–75 duración pesimista, 74–75, 184 EV. Consulte Componentes necesarios de EVM de valor
ganado (ERC), 93–94, 96, 138–141.
Consulte también Componentes de programación
Identificador de paquete de trabajo de EVMS, 115
Planificación de ejecución, 66 Resumen ejecutivo,

mi 66 Fecha de finalización prevista, 115, 180
EAC. Consulte Estimación al finalizar Fechas
de finalización anticipada, 101, 122, 180

F
Fechas de inicio anticipado, 101, 122, 180
Calendario ganado (ES), 112, 180 Gestión del Seguimiento rápido, 64, 181
calendario ganado (ESM), 85–88 Valor ganado (EV), 112, 180 Tampones de alimentación,
Gestión del valor ganado (EVM), 46, 52–53, 85–86, 93 Técnica 20 FF. Ver flotadores libres
del valor ganado (EVT), 180 Ponderación del valor ganado, 113 ED. Ver Duración Relaciones FF. Consulte Relaciones de fin a fin Nombre de archivo, 49
estimada Fecha de finalización, 181 No finalice antes de, 115, 181
198 Índice
Terminar no más tarde de, 116, 181 Ciclo de vida iterativo, 11

Terminar el, 116,181 Terminar a Planificación iterativa, 23
terminar, 116, 181 Relaciones de
terminar a terminar (FF), 57–58, 79–80 Terminar a comenzar, j

117, 181 Terminar a comenzar (FS ) relaciones, 59–61, 79–
Inventario justo a tiempo (JIT), 81–82
80 Valores flotantes, 63, 181, 192 Diagramas de flujo, 11, 14–
16 Pronósticos, 181 Proceso forense, 71 Pase hacia adelante,
k
181 Flotación libre (FF), 63, 72–74, 73 , 117, 181 ss. Consulte
Kanban, 32–33, 35–37, 182 Tablero
Relaciones de fin a comienzo
Kanban, 182 Método Kanban, 182
Rendimiento clave, 52–53 KRC.
Ver Componentes requeridos por el
riesgo
L
GRAMO
Lag, 59, 81–82, 118, 182 Fechas

Glosario, 171–193
de finalización tardías, 102, 123, 182
Granularidad, 50–51
Fechas de inicio tardías, 102, 123, 182
Gráfico, 25, 65–66, 181
LBS. Consulte Líder de programación basada
en la ubicación, 81–82, 118, 182 Programación
H
ajustada, 26 Lecciones aprendidas, 182
Hamaca actividad, 58, 117, 181
Actividades de nivel de esfuerzo (LOE), 57–
requisitos de jerarquía, 48
58, 118, 182 Niveles. Ver niveles de horarios
Recursos humanos, 2, 52
Ciclos de vida híbridos, 13

Ciclos de
vida ciclos de vida adaptativos, 11, 21–23,

yo
33 restricciones de fecha para, 76–77 ciclos
Fecha impuesta, 181 de vida híbridos, 13 ID para, 49 ciclo de
Ciclo de vida incremental, 11 vida incremental, 11 ciclo de vida iterativo,

Índice. Ver índice de conformidad 11 ciclo de vida continuo, 10 ciclo de vida
Entrada, predictivo, 10– 11, 13 para modelos de
181 Integrado, 182 programación, 10–13 Línea de equilibrio
Inventario, 81–82 (LOB), 27 LOB. Ver Línea de saldo
Iteración atrasada, 182
Iteración, 182. Véase también Sprints
Iteración atrasada, 182
199
Programación basada en ubicación (LBS), 25, 51 Final abierto, 183

Actividades LOE. Consulte Actividades de nivel de Actividad abierta, 77–79 Duración
esfuerzo Relaciones lógicas, 2–3, 29, 77–82, 182 Redes optimista, 74–75, 183 Componentes
basadas en lógica, 17 Planificación anticipada, 26 opcionales (O), 96, 138–141. Ver también
Componentes de programación
Organización, 25–27, 46–47, 49–50, 183

METRO
Duración original, 183
Lógica fuera de secuencia (OOS), 79–81

Mantenimiento, 50, 67–70
Salida, 62–64, 183
Resumen de gestión, 66
Propietarios, por actividades, 56
Fecha de finalización obligatoria, 119
Fecha de inicio obligatoria, 119
Horario maestro, 26, 53, 183 PAGS
Fusionar puntos, 72–73

PDM. Consulte Método de diagramación de precedencia
Metodología, 46–47, 60, 183
Porcentaje completo (PC o PCT), 183 Evaluación del
Hito, 2–3, 51, 55, 59–60, 63–64, 119, 183
desempeño de, 47 CPI, 110 ESM en, 85–86 desempeño
Programación de hitos, 183
clave, 52–53 monitoreo de, 41 SPI, 131, 190 SPI(t),
conformidad mínima, 139
131 TCPI, 134 de equipos, 49–50 TSPI, 135 PERT.
Seguimiento, 41, 73–74
Consulte Técnicas de revisión y evaluación de
Simulación de Montecarlo, 83–85
programas Duración pesimista, 74–75, 184
Duración más probable, 74, 183
Programación de fases, 26 Porcentaje físico
completado, 104, 124 Avance del trabajo físico, 184

norte
Valor planificado, 86–88, 184 Avance del trabajo

Diagramas de red, 17–18 Lógica planificado, 184 Planificación, 23–24 planificación de
de red, 183 Nodo, 183 Período la ejecución , 66 planificación anticipada, 26
sin trabajo, 183 Componentes sin
puntuación (NS), 96. Consulte
también Componentes de programación
O. Consulte Omisiones de
componentes opcionales, 77–78
Programación bajo demanda, 26
Lógica OOS. Ver Actividades abiertas de lógica
fuera de secuencia, 61
200 Índice
para administración, 47–48 niveles Duración real del proyecto, 120, 185
de programación modelo para, 130 valor Fecha de finalización real del proyecto, 121, 185
planificado, 120 paquetes de planificación, 29, Fecha de inicio real del proyecto, 121, 185
47–48 planificación de versiones, 43 para Calendario de proyectos, 121, 185
recursos, 52 herramientas de programación Categoría de costo del proyecto, 121
para, 29 resúmenes para, 65–66 programaciones Ruta crítica del proyecto, 185
objetivo, 31, 134 en adelante -planificación Descripción del proyecto, 122, 185
frontal para, 31–32 Política, 46 Práctica, 184 duración del proyecto, 185
Método de diagramación de precedencia Porcentaje de duración del proyecto completado, 122, 185
(PDM), 14, 184 Relación de precedencia, 184 Fecha de finalización anticipada del proyecto, 122, 185
Actividad predecesora, 184 Ciclo de vida predictivo, Fecha de inicio temprano del proyecto, 122, 185
10–11, 13 Presentación, 17, 184 ágil para, 38 –43 Fecha de finalización del proyecto, 185
modelos de programación y, 3, 6, 30–31, 90–91 Precios, para recursos, 128 Restricción de finalización del proyecto, 123, 186
Modelos de programación probabilística, 62, 85 Distribución de riesgo de Fecha de finalización del proyecto, 186
probabilidad, 120 Procedimiento, 53, 184 Proceso, 8, 15–16, 46, 71, 140– Identificador del proyecto, 186
141, 184. Véase también Diagramas de flujo Producto, 184 Pila de productos, Fecha de finalización tardía del proyecto, 123, 186
33, 184 Diseño de productos, 21 Visión del producto, 43 Evaluación de Fecha de inicio tardío del proyecto, 123, 186
programas y técnicas de revisión (PERT), 13 Progreso, 28–29, 43, 50, plan de gestión del proyecto, 186
67 supervisión de, 73–74 anulación del progreso, 80–81, 184 equipo de gestión de proyectos, 186
Gerente de proyecto, 186
Nombre del proyecto, 124, 186
Fase de proyecto, 186
Porcentaje físico completado del proyecto o Duración del proyecto
por ciento completo, 124, 186
Duración restante del proyecto, 124, 186
Cantidad real del recurso del proyecto, 125
Fecha de finalización nivelada de recursos del proyecto, 125, 187
Fecha de inicio nivelada de recursos del proyecto, 125, 187
Cantidad restante del recurso del proyecto, 125
Cantidad total de recursos del proyecto, 126
cronograma del proyecto, 187
Gestión del cronograma del proyecto, 187
alcance del proyecto, 187
Elaboración progresiva, 185; Declaración del alcance del proyecto, 187
proyecto, 185 Restricción de inicio de proyecto, 126, 187
201
Fecha de inicio del proyecto, Riesgo
187 Resumen del proyecto, evaluación de, 83–85 datos
66 Equipo del proyecto, 187 para, 47 en relaciones lógicas,
Miembros del equipo del proyecto, 187 81–82 riesgo cuantitativo, 20 ID de riesgo,
Duración total del proyecto, 126, 187 129 Componentes requeridos por el
Calendario de publicación, 66 PV. Ver riesgo (KRC), 93–94, 96, 138–141.

valor planificado
Véase también Componentes de programación
R Rol, 189 Planificación de ondas continuas, 23–
24, 189 RRC. Ver Componente de recursos

Registros, 70
requeridos
Relaciones, 82, 188 para
fechas, 57–61, 79–80 relaciones
lógicas, 2–3, 29, 77–81 Planificación de la versión,

S
43 Duración restante (RD), 188 Informes, 67, 87–90 Programar actividad, 189
Requisito, 26–27, 32–33, 37, 54, 139–140, 188 Línea base del cronograma, 189
Recurso, 18–19, 188 Asignación de recursos, 126, fecha de finalización prevista, 189
188 Disponibilidad de recursos, 127, 188 Calendario de recursos, 127, fecha de inicio prevista, 189
188 Descripción de recursos, 127 ID de recurso, 127 , 188 Retraso de Nivel de programación, 65–66, 190
recursos, 128, 188 Nivelación de recursos, 188 Biblioteca/diccionario Gestión de horarios, 45–53
de recursos, 128, 189 Calendario de recursos limitados, 189 Nombre Programar hito, 190
del recurso, 189 Tasas/precios de recursos, 128, 189 Componente de Horario modelo, 2, 94, 190
recursos requeridos (RRC), 96, 138– 141. Análisis del modelo de cronograma, 71–88, 190
Programar la creación de modelos 63–66
Programar instancia de modelo, 190
Programar nivel de modelo, 130
Programar el mantenimiento del modelo, 67–70
Presentación modelo horario, 130
Principios y conceptos del modelo de programación, 9–43 ágil,
31–43 ciclos de vida del proyecto y enfoques de programación,
10–27 modelo de programación, 29 instancias y presentaciones del
Véase también Planificación de componentes modelo de programación, 30–31 herramienta de programación, 28
Tipo de recurso, 128, 189
resultado, 189
Lógica retenida, 80–81, 189 Programar análisis de red, 190
202 Índice
Índice de rendimiento del cronograma (SPI), 131, 190 actividad recurso cantidad restante, 106 actividad
Horario índice de rendimiento de tiempo (SPI (t)), 131 recurso cantidad total, 106 actividad riesgo criticidad
Variación de horario (SV), 131, 190 índice, 106, 175 actividad ámbito definición, 107, 175
Porcentaje de variación del cronograma (SV%), 132 actividad total duración, 107, 175 actividad trabajo por
Horario de variación de tiempo (SV(t)), 132 ciento completado, 107 tiempo real (AT), 107 tan tarde
Enfoque de programación, 190 como posible, 108 tan pronto como sea posible, 108
Componentes de programación, 93–136 modelo de programación de referencia, 108 presupuesto
costo real de actividad (AC), 98, 172 al finalizar (BAC), 109, 177 identificador de solicitud de
duración real de actividad, 98, 172 fecha cambio, 109, 177 ID de cuenta de control, 109, 177
de finalización real de actividad, 98, 172 administrador de cuenta de control (CAM), 110, 177
fecha de inicio real de actividad, 99, 172 rendimiento de costos índice (CPI), 110, 178 variación
calendario de actividad, 99, 172 código de de costos, 110, 178 porcentaje de variación de costos
actividad, 99, 173 categoría de costo de (CV %), 111 ruta crítica, 111, 178 fecha de datos, 111,
actividad, 100 , 173 estimación de costos de 179 recurso impulsor, 112, 179 cronograma ganado
actividad, 100, 173 distribución de riesgo de (ES), 112, 180 valor ganado (EV), 112, 180 tipo de
probabilidad acumulada de actividad, 100, 173 fecha de medición del valor ganado, 113 ponderación del valor
finalización anticipada de actividad, 101, 173 fecha de ganado, 113 estimación al finalizar (EAC), 113, 180
inicio anticipada de actividad, 101, 173 esfuerzo de actividad, duración estimada (ED), 114 estimación para completar
101, 173 ID de actividad, 102, 173 etiqueta de actividad, 102 , (ETC), 114, 180 estimación para completar tiempo
173 fecha de finalización tardía de la actividad, 102, 173 fecha (ETC(t)), 114
de inicio tardía de la actividad, 102, 174 duración más probable
de la actividad, 103, 174 nota/comentario/registro de actividad,
103, 174 duración optimista de la actividad, 103, 174 duración
original de la actividad, 104, 174 actividad pesimista duración,
104, 174 actividad física porcentaje completado o duración de
la actividad
identificador del paquete de trabajo de EVMS,
115 fecha de finalización esperada, 115, 180
porcentaje completado, 104, 174 finalización no antes de, 115, 181 finalización
duración restante de actividad, 105, 174 cantidad no más tarde de, 116, 181 finalización el, 116,
real de recurso de actividad, 105 fecha de 181 finalización a finalización, 116, 181
finalización nivelada de recurso de actividad, 105, 175 fecha finalización a inicio, 117, 181
de inicio nivelada de recurso de actividad, 106, 175
203
flotación libre, 117, 181 disponibilidad de recursos, 127, 188
actividad hamaca, 117, 181 retraso, calendario de recursos, 127, 188
118, 182 ventaja, 118, 182 nivel de descripción de recursos, 127 ID de
esfuerzo (LOE), 118, 182 fecha de recurso, 127, 188 retraso de recursos,
finalización obligatoria, 119 fecha de 128, 188 biblioteca/diccionario de
inicio obligatoria, 119 hito, 119, 183 recursos, 128, 189 tasas/precios de recursos,
valor planificado, 120, 184 distribución 128, 189 tipo de recurso, 128, 189 ID de riesgo,
de riesgo de probabilidad, 120 129 ID de modelo de programación, 129
duración real del proyecto, 120, 185 instancia de modelo de programación, 129, 190
fecha de finalización real del proyecto, nivel de modelo de programación, 130
121, 185 fecha de inicio real del proyecto, presentación de modelo de programación, 130
121, 185 calendario del proyecto, 121, 185 índice de rendimiento de programación (SPI),
categoría de costo del proyecto, 121 131, 190 tiempo de índice de rendimiento de
descripción del proyecto, 122, 185 duración programación (SPI(t)), 131 variación de programación
del proyecto porcentaje completado, 122, 185 (SV), 190 % de variación del programa (SV%), 131 tiempo
fecha de finalización anticipada del proyecto, de variación del programa (SV(t)), 131 inicio no antes de,
122, 185 fecha de inicio anticipada del proyecto, 122, 185 131, 191 inicio no más tarde de, 131, 191 inicio el, 133,
restricción de finalización del proyecto, 123, 186 fecha de 191 inicio a fin , 133, 191 inicio a inicio 133, 191 actividad
finalización tardía del proyecto, 123, 186 fecha de inicio de resumen, 134, 192 modelo de cronograma objetivo 134,
tardía del proyecto, 123, 186 nombre del proyecto, 124, para completar el índice de desempeño (TCPI), 134 para
186 porcentaje físico del proyecto completado o duración completar el índice de desempeño del cronograma (TSPI),
del proyecto 135 flotación total, 135, 192 unidad de medida, 135, 193
varianza, 136, 193
porcentaje completado, 124, 186
duración restante del proyecto, 124, 186
cantidad real de recursos del proyecto, 125
fecha de finalización nivelada de recursos del proyecto,
125, 187 fecha de inicio nivelada de recursos del proyecto,
125, 187 cantidad restante de recursos del proyecto, 125
cantidad total de recursos del proyecto, 126 restricción de ID de EDT, 136, 193
inicio de proyecto, 126, 187 duración total del proyecto, Herramienta de programación, 3, 190
126, 187 asignación de recursos, 126, 188 Alcance, 21, 190
Scrum, 32–37, 190
204 Índice
Actividad de secuencia, 59–61, 190 Servicio, T

191 SF. Consulte Simulaciones de relaciones
Programación objetivo, 31, 192
de principio a fin, 83–85 Deslizamiento, 68 Software,
Modelo de programación objetivo, 134
28, 49, 51, 56
Tarea, 192 Ejecución de tareas, 19, 39–
42 TCPI. Consulte Para completar la
técnica del índice de rendimiento, 192 Dependencias

para planificación de versiones,
impulsadas por la tecnología, 36 Plantilla, 192 TF. Ver
43 para nivelación de recursos, 63, 83
flotadores totales
Ruta crítica especificada, 191 SPI.
Consulte el índice de rendimiento de la programación
SPI(t). Consulte Programar tiempo de índice de rendimiento

Teoría de
Patrocinador, 191 Sprints, 32–34, 38–41 SS. Véase Relaciones
ágil, 31–37 de
de comienzo a comienzo Parte interesada, 48, 88, 191 Fechas
componentes, 1, 93 de CPM,
de inicio, 191 Comienzo no antes de, 131, 191 Comienzo no
5 de EVM, 46 de gestión, 45–
más tarde de, 131, 191 Comienzo el, 133, 191 Comienzo a fin,
46 conformidad mínima, 139
133, 191 Comienzo a -finish (SF) relaciones, 82 Comienzo a
de modelos de programación, 3–
comienzo 133, 191 Comienzo a comienzo (SS) relaciones, 57–
4, 9 grado técnico de incertidumbre, 22
61, 79–80, 133 Fecha de estado, 191 Puntos de historia, 39–42
Subred, 191 Subfase, 191 Subproyecto , 191 Actividad sucesora,
192 Actividad resumida, 56–57, 83, 134 SV. Ver Variación de

Estimación de tres puntos, 192
horario
umbrales, 83
Fases temporales, 4
AT, 86, 88, 107 por
costo, 30
ETC(t), 114
para presentaciones, 17
modelos de programa probabilístico, 62
SPI(t), 131
SV(t), 132
para equipos, 50–51
Escala de tiempo, 192

VS%. Consulte el porcentaje de variación del
Para completar el índice de rendimiento (TCPI), 134
cronograma SV(t). Ver Sistema de tiempo de variación
Para completar el índice de rendimiento del cronograma (TSPI), 135
de horario, 191
205
Herramienta, Velocidad, 42–43
192 Duración total, 107, 126 Extremos abiertos virtuales, 78–79, 193
Flotación total (TF), 63, 72–74, 135, 192 Visualización, 27, 54
Formación, 46 TSPI. Ver Para completar el índice
de rendimiento del cronograma

W
tu EDT. Ver estructura de descomposición del trabajo
Peso, de valor ganado, 113

Unidad de medida, 135, 193
Trabajo, 193
Ciclos de actualización, 50–51, 69
Solución alternativa, 193
Planificación inicial, 31–32
Estructura de desglose del trabajo (EDT), 193
Usuario, 193
Continuidad
del flujo de trabajo

V
para, 56 recursos humanos y, 52
Valor, 180, 184 Kanban para, 35, 37
EV, 112–113 planificación para, 26
EVM, 46, 52–53, 85–86, 93 valor de sprints y, 38–41 períodos
desempeño 86–88 valor planificado, de trabajo, 49–50
120 paquete de trabajo, 193
Varianza, 136, 193 Periodo de trabajo, 193
Umbral de varianza, 193
206 Índice
Estándar de práctica para la programación - Tercera edición
El Estándar de práctica para la programación - Tercera edición proporciona el pensamiento más reciente sobre las prácticas
buenas y aceptadas en el área de la programación de un proyecto. Alineado con la Sexta edición de A Guide to Project
Management Body of Knowledge (Guía del PMBOK® ) , este estándar de práctica actualizado expone la información contenida
en la Sección 6 sobre Gestión del cronograma de proyectos de la Guía del PMBOK® .
En esta nueva edición del estándar de práctica, aprenderá a identificar los elementos de un buen modelo de programación, su
propósito, uso y beneficios. También descubrirá lo que se requiere para producir y mantener un buen modelo de cronograma.
También se incluye en la tercera edición:
Descripción de la programación
Definición de modelo de cronograma
Usos y beneficios del modelo de cronograma
Definiciones de términos clave y pasos para la programación
Descripciones detalladas de los componentes de programación
Orientación sobre los principios y conceptos de creación y uso de modelos de horario
Descripciones de los principios y conceptos del modelo de cronograma
Diferencias entre modelos de programación, instancias de modelos de programación y presentaciones
Descripciones detalladas del método de la ruta crítica, la cadena crítica, la técnica de evaluación y revisión de
programas (PERT), la planificación de ondas móviles y la simulación de Monte Carlo
Usos y aplicaciones de enfoques de gestión de proyectos adaptables en la programación, como ágil
Orientación e información sobre buenas prácticas generalmente aceptadas asociadas con los procesos de planificación,
desarrollo, mantenimiento, comunicación e informes de un modelo de programación efectivo
Instituto de manejo proyectos

Centro de operaciones globales
14 campus bulevar
Newtown Square, Pensilvania 19073 EE. UU.
ESTANDAR GLOBAL Teléfono: +1 610 356 4600
PMI.org

PS - Scheduling - 3rd (ES)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PS - Scheduling - 3rd (ES)

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

Datos de catalogación en publicación de la Biblioteca del Congreso

Nombres: Instituto de Gestión de Proyectos.

Registro LC disponible en https://lccn.loc.gov/2019009443

©2019 Project Management Institute, Inc. Todos los derechos reservados.

800-888-4741 Fax: +1 312-337-5985

Box 932683, Atlanta, GA 31193-2683 EE. UU. Teléfono:

1-866-276-4764 (dentro de EE. UU. o Canadá) o +1-770-280-4129 (a nivel mundial)

Correo electrónico: info@bookorders.pmi.org

1. INTRODUCCIÓN............................................... .................................................... .......................1

1.1 Programación del proyecto ............................................... .................................................... .......2

1.4 Propósito.................................................. .................................................... ........................7 1.5

2. PRINCIPIOS Y CONCEPTOS DEL MODELO DE LISTA ........................................... .........................9

2.2 Ciclos de vida del proyecto y enfoques de programación ........................................... .............10

2.6 Ágil .................................................. .................................................... ..........................31 2.6.1

3. RESUMEN DE BUENAS PRÁCTICAS DEL MODELO DE CRONOGRAMA .................................. ......................45

3.1 Gestión de horarios.................................................... ..........................................................45 3.1.1 Plan

proyecto y granularidad de la actividad ........ ........................50 3.1.2.8 Estructura de

cambios... .................................................... ..........................53 3.2 Creación del modelo de

3.2.1 Desarrollar la línea base del modelo de cronograma .................................. .......................55

las Actividades del Proyecto ........................................... ....................55 3.2.1.3 Secuencia

3.3 Programar el mantenimiento del modelo ........................................... ..........................................67

3.3.3 Comparar y abordar cualquier desviación ........................................... ...........68 3.3.4

3.3.8 Control de cambios ............................................. .................................................... .70 3.4

Estimación de la duración de las actividades ..... .................................................... ..............74

3.4.5 Actividades abiertas.................................................... ..........................................77 3.4.6

3.5 Comunicación e informes ............................................... .....................................88

4. COMPONENTES DEL PROGRAMA .................................................. .................................................... ..93

4.1 Cómo usar la lista de componentes........................................... .....................................94 4.1.1

4.1.7 Pagaré Condicional/Componente Asociado........................................... .............95

4.2 Lista de componentes por categoría ........................................... .....................................96

4.3 Lista detallada de componentes ............................................. .............................................98

5. ÍNDICE DE CONFORMIDAD ............................................... .................................................... ........137

5.1 Resumen de conformidad ............................................... .............................................137

5.1.1 Categorías de componentes ............................................. ..........................138

5.2 Proceso de evaluación de la conformidad ............................................... .............................140

X2.2.2 Revisión final del proyecto de norma ............................................... ..........................146

X2.4 Revisión del cuerpo de consenso ........................................... .............................................148

REFERENCIAS .................................................. .................................................... ........................169

GLOSARIO................................................. .................................................... .............................171

ÍNDICE .................................................. .................................................... ....................................195

LISTA DE TABLAS Y FIGURAS

Figura 1-1. Programar el desarrollo y el uso del modelo ........................................... ......................6

Figura 2-1. Continuidad del ciclo de vida .............................................. .............................................10

Figura 2-2. Ejemplo de Diagrama de Flujo Predictivo ............................................... .......................11

Figura 2-3. Diagrama de flujo iterativo .............................................. ..........................................11

Figura 2-4. Un ciclo de vida de incrementos de tamaño variable .................................. ....................11

Figura 2-5. Diagrama de flujo adaptativo .............................................. ..........................................12

Figura 2-6. Enfoques predictivos y adaptativos combinados utilizados ..........................................13

Figura 2-7. Flujo del modelo de cronograma................................................... ..............................................15

Figura 2-8. Diagrama de flujo para el modelo de cronograma asignado

Figura 2-9. Ejemplo de diagrama CPM ............................................... ..........................................18

Figura 2-10. Tampones de alimentación ................................................ .................................................... ..20

Figura 2-11. Amortiguadores del proyecto ................................................ .................................................... ...21

Figura 2-12. Diagrama de Incertidumbre ............................................... ..........................................22

Figura 2-13. Ejemplos de enfoques ágiles ............................................... ..........................23

Figura 2-14. Ejemplo de planificación de ondas móviles—Planificación

Figura 2-15. Ejemplo de planificación de ondas móviles—Planificación

2-16. Ejemplo de horario basado en la ubicación ........................................... ..........................25

Figura 2-17. Programar instancias de modelos y presentaciones ............................................... ......30

Figura 2-18. Ejemplo de Múltiples Iteraciones o Sprints ............................................... ...............32

Figura 2-19. Ciclo de Vida Adaptativo Típico ............................................... ....................................33