CRONOGRAMA

Xxxxxxx
Instituto de manejo proyectos
NORMA DE PRÁCTICA PARA LA
PROGRAMACIÓN
Segunda edicion
Con licencia para: ITALO MARTIN ARBIETO MORENO PMI MemberID: 2895710
Esta copia es un beneficio para miembros de PMI, no para distribución, venta o reproducción.
Página 2
Datos de catalogación en publicación de la Biblioteca del Congreso
Norma de práctica para la programación / Project Management Institute. 2da ed.
pag. cm.
Incluye referencias bibliográficas e indice.
ISBN 9781935589242 (pbk.: Papel alcalino) 1. Gestión del proyecto Normas. I. Instituto de Gestión de
Proyectos.
HD69.P75P653 2011
658.4'04 — dc23
2011020603
Publicado por:
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pennsylvania 190733299 Estados Unidos.
Teléfono: + 6103564600
Fax: + 6103564647
Correo electrónico: customercare@pmi.org
Internet: www.PMI.org
© 2011 Project Management Institute, Inc. Todos los derechos reservados.
“PMI”, el logotipo de PMI, “PMP”, el logotipo de PMP, “PMBOK”, “PgMP”, “Project Management Journal”, “PM
Network” y el PMI
Hoy los logotipos son marcas registradas de Project Management Institute, Inc. El Quarter Globe Design es una
marca registrada del Proyecto
Management Institute, Inc. Para obtener una lista completa de las marcas de PMI, comuníquese con el Departamento
Legal de PMI.
PMI Publications agradece las correcciones y comentarios sobre sus libros. Por favor, siéntase libre de enviar
comentarios tipográficos,
formateo u otros errores. Simplemente haga una copia de la página relevante del libro, marque el error y envíelo a:
Editor de libros,
Publicaciones de PMI, 14 Campus Boulevard, Newtown Square, PA 190733299 EE. UU.
Para consultar sobre descuentos para reventa o fines educativos, comuníquese con el Centro de servicios de libros de
PMI.
Centro de servicio de libros PMI
PO Box 932683, Atlanta, GA 311932683 EE. UU.
Teléfono: 18662764764 (dentro de los EE. UU. O Canadá) o + 17702804129 (globalmente)
Fax: + 17702804113
Correo electrónico: book.orders@pmi.org
Impreso en los Estados Unidos de América. Ninguna parte de este trabajo puede reproducirse o transmitirse de
ninguna forma ni por ningún medio,
electrónica, manual, fotocopiado, grabación o por cualquier sistema de almacenamiento y recuperación de
información, sin previo aviso
permiso del editor.
El papel utilizado en este libro cumple con la Norma de papel permanente emitida por las Normas nacionales de
información
Organización (Z39.48—1984).
10 9 8 7 6 5 4 3 2 1
Página 3
AVISO
Las normas y publicaciones de pautas del Project Management Institute, Inc. (PMI), de las cuales el
documento
contenido aquí es uno, se desarrollan a través de un proceso de desarrollo de estándares de consenso
voluntario. Esta
El proceso reúne a voluntarios y / o busca las opiniones de personas que tienen interés en el tema
cubierto por esta publicación. Mientras que PMI administra el proceso y establece reglas para
promover la justicia en
El desarrollo del consenso, no escribe el documento y no prueba, evalúa,
o verificar la exactitud o integridad de cualquier información o la solidez de cualquier juicio contenido
en su
estándares y publicaciones de guías.
PMI se exime de responsabilidad por cualquier lesión personal, propiedad u otros daños de cualquier
naturaleza, ya sea
especial, indirecta, consecuente o compensatoria, directa o indirectamente resultante de la publicación,
uso de
aplicación o dependencia de este documento. PMI niega y no ofrece ninguna garantía, expresa o
implícito, en cuanto a la exactitud o integridad de cualquier información publicada en este documento,
y renuncia y no hace
garantía de que la información en este documento cumplirá cualquiera de sus propósitos o necesidades
particulares. PMI hace
no se compromete a garantizar el desempeño de ningún fabricante o producto o servicio del vendedor
por
virtud de esta norma o guía.
Al publicar y poner a disposición este documento, PMI no se compromete a prestar servicios
profesionales u otros
servicios para o en nombre de cualquier persona o entidad, ni PMI se compromete a realizar ningún
deber adeudado por ninguna persona
o entidad a otra persona. Cualquiera que use este documento debe confiar en su propio juicio
independiente
o, según corresponda, busque el consejo de un profesional competente para determinar el ejercicio de
un cuidado razonable
en cualquier circunstancia La información y otras normas sobre el tema cubierto por esta publicación
pueden
estar disponible de otras fuentes, que el usuario puede consultar para obtener vistas adicionales o
información que no
cubierto 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 o inspecciona productos, diseños o instalaciones con fines de seguridad o
salud. Ninguna
certificación u otra declaración de cumplimiento de 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 creador de la declaración.
Página 4
Página 5
TABLA DE CONTENIDO
PREFACIO ................................................. .................................................. ......................
..........X
CAPÍTULO 1
INTRODUCCIÓN .............................................. .................................................. ... 1
1.1 Programación del
proyecto ............................................... .................................................. 1
1.2 ¿Por qué programar? .................................................. ..................................................
2
1.3 Descripción
general ................................................ .................................................. ................ 2
1.4 Propósito ................................................ .................................................. .................. 3
1.5 Aplicabilidad ................................................ .................................................. ........... 5
CAPÍTULO 2 EL MODELO DE HORARIO PRINCIPIOS Y
CONCEPTOS ....................................... 7
2.1 Descripción
general ................................................ .................................................. ................ 7
2.2 Métodos de
programación ............................................... ................................................. 9
2.2.1 Método de ruta crítica ............................................ ........................................ 9
2.2.2 Método del diagrama de precedencia ............................................ ........................
12
2.2.3 Método de cadena crítica ............................................ .................................... 12
2.3 Técnicas de programación ............................................... ..........................................
15
2.3.1 Planificación de olas rodantes ............................................ ...................................
15
2.3.2 Técnica ágil ............................................. ............................................. dieciséis
2.3.3 Técnica de evaluación y revisión del programa .......................................... ...
dieciséis
2.3.4 Simulación de Monte Carlo ............................................ .................................
dieciséis
2.4 La herramienta de
programación .............................................. ................................................ 17
2.5 El modelo de
programación .............................................. ................................................ 18
2.6 El modelo de programa Instancias y presentaciones ........................................... ...
18
CAPÍTULO 3 PROGRAMA MODELO BUENAS PRÁCTICAS
RESUMEN .......................................... ..21
3.1 Gestión del modelo de
programación .............................................. ................................. 21
3.1.1 Plan de gestión de datos programados ........................................... .................. 22
3.1.2 Plan de gestión del modelo de programación ........................................... ................
23
.1 Selección de un método de programación ........................................... ............ 23
.2 Selección de una herramienta de
programación ........................................... .................. 23
.3 Plan de Creación del Modelo de Horario ............................................ ................. 23
.4 Programar ID de modelo ............................................. .................................. 23
.5 Programar versión del modelo ............................................. .......................... 23
.6 Calendarios y períodos de trabajo ............................................ .................... 23
.7 Ciclo de actualización del proyecto ............................................. ...............................
24
v
Página 6
vi
Estándar de práctica para la programación Segunda edición
© 2011 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 190733299 EE. UU.
.8 Estructura de codificación de hitos y actividades ........................................... 24
.9 Planificación de recursos .............................................. ................................ 25
.10 Indicadores de rendimiento .............................................. ........................ 25
.11 Modelo de programación maestra ............................................. ......................... 25
3.2 Programación de la creación del
modelo .............................................. ........................................ 26
3.2.1 Desarrollar la línea base del modelo de
cronograma ........................................... ................. 27
.1 Definir hitos .............................................. ................................... 27
.2 Diseñar las actividades del proyecto ............................................ ................. 27
.3 Actividades de secuencia .............................................. ................................ 28
.4 Determinar recursos para cada actividad ........................................... .... 30
.5 Determinar la duración de cada actividad .......................................... .. 30
.6 Analizar la salida de la programación ............................................ ................... 31
.7 Aprobar el cronograma ............................................. ............................. 32
.8 Línea de base del modelo de programación ............................................ ...................
32
3.3 Programa de mantenimiento del
modelo .............................................. ................................. 33
3.3.1 Recopilar datos reales y trabajo restante .......................................... .............. 33
3.3.2 Actualización y progreso del modelo de programación de acuerdo con los datos
reales ...... 33
3.3.3 Comparar y resolver cualquier desviación .......................................... .............. 34
3.3.4 Actualizar el modelo de programación con cambios
aprobados ............................... 34
3.3.5 Actualizar el modelo de programación de línea de base ..........................................
............. 34
3.3.6 Comunicar .............................................. ............................................... 34
3.3.7 Mantener los registros ............................................ .................................... 34
3.4 Análisis del modelo de
programa .............................................. ........................................ 35
3.4.1 Ruta crítica y actividades críticas .......................................... ................. 35
.1 Ruta crítica .............................................. ............................................ 35
.2 Actividades críticas .............................................. .................................... 35
3.4.2 Flotación total y flotación libre .......................................... ................................ 35
3.4.3 Actividades de nivel de esfuerzo (LOE) ........................................ ...........................
36
3.4.4 Distribución probabilística de la duración de las
actividades ....................................... 36
3.4.5 Programa de riesgos ............................................. ............................................... 37
3.4.6 Restricciones de fecha ............................................. ........................................... 37
3.4.7 Actividades abiertas ........................................... .................................... 37
3.4.8 Lógica fuera de secuencia (OOS) ........................................ ............................ 37
3.4.9 Leads and Lags ............................................ .............................................. 38
TABLA DE CONTENIDO
Página 7
vii
3.4.10 Relación de principio a fin ......................................... ............................. 38
3.4.11 Enlaces a / desde actividades resumidas ......................................... ................... 38
3.5 Comunicación e informes .............................................. ............................... 39
CAPÍTULO 4 COMPONENTES DE
PROGRAMACIÓN ............................................. ................................ 41
4.1 Cómo usar la lista de componentes ........................................... ...............................
41
4.1.1 Nombre del componente ............................................. ......................................... 42
4.1.2 Uso obligatorio, condicional u opcional ......................................... ............. 42
4.1.3 Manual o Calculado ............................................ .................................... 42
4.1.4 Formato de datos ............................................. .................................................. 42
4.1.5 Comportamiento .............................................. .................................................. .....
42
4.1.6 Buenas prácticas ............................................. .............................................. 43
4.1.7 Nota condicional / componente asociado .......................................... ....... 43
4.1.8 Definición .............................................. .................................................. .... 43
4.2 Lista de componentes por categoría ............................................ ...............................
43
4.3 Lista detallada de
componentes .............................................. ....................................... 45
CAPÍTULO 5 ÍNDICE DE
CONFORMIDAD ............................................. ........................................ 77
5.1 Descripción general de
conformidad ............................................... .......................................... 77
5.1.1 Categorías de componentes ............................................ ............................ 77
5.1.2 Utilización de componentes de programación ........................................... ..............
78
5.1.3 Evaluación de conformidad ............................................. ............................ 79
5.2 Proceso de evaluación de conformidad .............................................. ........................
79
REFERENCIAS ................................................. .................................................. ..............
......... 83
APÉNDICE A: DIRECTRICES PARA UN INSTITUTO DE GESTIÓN DE
PROYECTOS
NORMA DE
PRÁCTICA ................................................ .................................................. .......... 85
A.1 Introducción .............................................. .................................................. ........... 85
APÉNDICE B EVOLUCIÓN DEL ESTÁNDAR DE PRÁCTICAS DE PMI PARA
LA PROGRAMACIÓN ....................... 87
B.1 PreProyecto ............................................ .................................................. ...............
87
B.2 Trabajo preliminar ............................................. .................................................. ....
88
B.2.1 Calificaciones .............................................. ............................................... 88
B.2.2 Geográfica .............................................. .................................................. .88
B.2.3 Mercado .............................................. .................................................. ........ 88
B.2.4 Aplicaciones .............................................. ................................................. 88
B.3 Exposición y consenso ............................................ .......................................... 90
TABLA DE CONTENIDO
Página 8
viii
APÉNDICE C CONTRIBUYENTES Y REVISORES DE LA
NORMA DE PRÁCTICA PARA PROGRAMACIÓN: SEGUNDA
EDICIÓN ........................................... .... 91
C.1 Comité Central ............................................. .................................................. ...... 91
C.2 Contribuyentes
significativos ............................................. ........................................... 91
C.3 Exposición de revisores y contribuyentes del
borrador .......................................... .............. 92
C.4 Otros contribuyentes ............................................. .................................................. ..
93
C.5 Grupo Asesor de Miembros del Programa de Normas PMI
(MAG) .................................... 93
C.6 Personal de
producción ............................................. .................................................. ...... 93
APÉNDICE D TABLA DE PUNTUACIÓN DE LA EVALUACIÓN DE
CONFORMIDAD ........................................... .95
APÉNDICE E HOJAS DE TRABAJO DE EVALUACIÓN DE
CONFORMIDAD ............................................ ..101
GLOSARIO ................................................. .................................................. ......................
... 107
Acrónimos y términos comunes .............................................. ......................................
107
Términos y definiciones ............................................... ..................................................
110
TABLA DE CONTENIDO
Página 9
ix
LISTA DE TABLAS Y CIFRAS
Figura 1
1. Programación ................................................. .................................................. ........................ 4
Figura 21. Programación de
creación ................................................ .................................................. .............. 8
Figura 22 (a). Diagrama de flujo para el modelo de
programación ............................................ .................................. 10
Figura 22 (b). Tabla de mapeo de componentes del
proceso .............................................. .................................... 11
Figura 23. Ejemplo de diagrama de CPM /
PDM ............................................ ............................................. 13
Figura 24. Ejemplo de cadena
crítica .............................................. .................................................. ..14
Figura 25. Ejemplo de planificación de olas
rodantes ............................................. ......................................15
Figura 26. Distribución de probabilidad de duración de ejemplo para una sola
actividad ...................................... 17
Figura 27. Programar presentaciones de instancias de
modelo .............................................. ............................ 19
Figura 31. Ilustraciones de los tipos de relación en la metodología
CPM ........................................... ...... 29
Tabla 31. Niveles de presentaciones de instancias de modelo de
programa ............................................ ............... 39
Tabla 41. Lista de componentes por
categoría ............................................. .......................................... 44
Tabla 51. Número de componentes por
categoría ............................................. ................................... 80
Tabla D1. Tabla de puntuación de evaluación de conformidad de
muestra ............................................. ............... 95
Figura E1 Hoja de trabajo
base ............................................ .................................................. ................. 102
Figura E2 Recurso requerido Ejemplo de hoja de
trabajo .......................................... ............................... 103
Figura E3 Recurso, EVM y hoja de trabajo de ejemplo de riesgo
requerido ...................................... .......... 104
Figura E4 Ejemplo de hoja de cálculo de recursos y riesgos
necesarios ........................................ ................. 105
Figura E5 Ejemplo de hoja de trabajo sin
puntaje .......................................... ........................................... 106
Página 10
X
PREFACIO
El Estándar de práctica para la programación: la segunda edición se ha desarrollado como
complemento de una guía
al Cuerpo de Conocimientos de Gestión de Proyectos ( Guía PMBOK ® Cuarta Edición) en el Área de
Conocimientos de
Gestión del tiempo del proyecto. Esta segunda edición del estándar de práctica se basa en la base
establecida
en la primera edición que describe los métodos relacionados con la programación que generalmente se
reconocen como una buena práctica
para la mayoría de los proyectos la mayor parte del tiempo . Las buenas prácticas significan que
existe un acuerdo general de que lo correcto
La aplicación de estas habilidades, herramientas y técnicas puede aumentar las posibilidades de éxito
en una amplia gama
de diferentes proyectos. Las buenas prácticas no significan que el conocimiento descrito siempre deba
aplicarse.
uniformemente en todos los proyectos; El equipo de gestión del proyecto es responsable de
determinar qué es apropiado para
un proyecto determinado .
La comunidad de gestión de proyectos ha expresado firmemente la necesidad de un estándar para
promover el
desarrollo de horarios de sonido. Además, la comunidad solicitó la capacidad de evaluar la adecuación
de sus horarios.
Este estándar de práctica está diseñado para proporcionar profesionales de gestión de proyectos, que
estén familiarizados con
la Guía PMBOK ® — Cuarta edición, con un resumen de los beneficios y ventajas de un bien
desarrollado
y modelo de horario mantenido. Este estándar de práctica describe los rasgos distintivos de un sonido
efectivo y efectivo.
metodología de programación de proyectos, así como proporcionar medios cuantificables para evaluar
la aplicación de la
disposiciones de esta norma a un modelo de horario.
Uno de los desarrollos más significativos en la creación de la primera edición del Estándar de
Práctica para
La programación se centró en la aclaración del calendario de términos . Se hizo evidente a través de
la discusión
proceso y la retroalimentación de la comunidad de que hubo un apoyo significativo para la aclaración
de esta terminología.
El Estándar de práctica para la programación: la segunda edición aclaró esta distinción entre el
cronograma del proyecto
y modelo de horario.
El desarrollo del programa fluye a partir de la selección de un método de
programación apropiado seguido de la selección
y uso de una herramienta de programación . A continuación, los datos específicos del proyecto se
ingresan en la herramienta de programación para producir el
modelo de horario . A partir de ahí, las instancias del modelo de programación se guardan para su uso
como plataformas hipotéticas, objetivos,
y para aprobación formal como línea de base. A partir de estos casos, se
producen varias presentaciones para una amplia
gama de usos. Con estos términos discretos, los profesionales de gestión de proyectos tienen la
capacidad de rastrear
procesos desde la Guía PMBOK ® — Cuarta edición hasta el producto terminado y la respuesta, en un
de manera inequívoca, la pregunta de qué se solicita cuando se le solicita un horario.
The Practice Standard for Scheduling: la segunda edición se centró en agregar más claridad a los
problemas y
conceptos de la edición anterior:
• El Capítulo 2 se reorganizó para alinearse más estrechamente con la Guía PMBOK ® Cuarta edición
con
énfasis específico en la gestión del modelo de cronograma y proporcionar claridad adicional sobre los
diversos
Programar métodos y técnicas.
Página 11
xi
• El Capítulo 3 se reorganizó para enfatizar las buenas prácticas en las áreas de gestión del modelo,
modelo
creación, mantenimiento, análisis y comunicación e informes.
• El Capítulo 4 sigue centrado en los diversos componentes de un modelo de programación. La
actualización introduce
El concepto de cuatro grupos de componentes requeridos , además de dos grupos de
componentes opcionales . Esta
El refinamiento se desarrolló para abordar las áreas de preocupación planteadas en la edición de 2007,
ampliando
El alcance de la cobertura del valor ganado, el riesgo y la aplicación de recursos.
• El Capítulo 5 se reescribió para continuar permitiendo la evaluación de un modelo de cronograma
dentro de
Las pautas más complejas de múltiples componentes requeridos y opcionales. También abordó un
preocupación expresada en la edición anterior sobre el proceso de evaluación.
Este estándar de práctica es consistente con la Guía PMBOK ® — Cuarta edición. También incluye
información.
de prácticas de gestión de proyectos aceptadas de muchas industrias. El Instituto de gestión de
proyectos
El programa de estándares continuará actualizando periódicamente este estándar como parte de la
evolución general planificada
de documentos de normas PMI. Los comentarios de los profesionales de gestión de proyectos son
solicitados y
Bienvenido.
Pagina 12
Página 13
1
1
CAPÍTULO 1
INTRODUCCIÓN
Este capítulo está diseñado para proporcionar una visión general del contenido de este estándar de
práctica. Este capitulo es
dividido en las siguientes secciones:
1.1 Programación del proyecto
1.2 Por qué programar
1.3 Descripción general
1.4 Propósito
1.5 Aplicabilidad
Cada sección proporciona información adicional sobre el contenido y la terminología utilizada en esta
práctica.
estándar.
1.1 Programación del proyecto
La programación de proyectos es la aplicación de habilidades, técnicas e intuición adquiridas a través
del conocimiento y experiencia para desarrollar modelos de horarios efectivos. El modelo de horario
se integra y organiza lógicamente.
varios componentes del proyecto, como actividades, recursos y relaciones lógicas, para mejorar la
probabilidad de finalización exitosa del proyecto dentro de la duración de referencia.
Los términos modelo de programación, instancia de modelo de programación y presentaciones se
definen en el glosario de
estándar. Estos términos se describen a continuación:
El modelo de cronograma es una representación dinámica del plan para ejecutar las actividades del
proyecto desarrolladas por el partes interesadas del proyecto, aplicando un método de programación
seleccionado a una herramienta de programación utilizando datos específicos del proyecto.
El modelo de programación puede procesarse mediante una herramienta de programación para
producir varias instancias de modelo de programación.
La instancia del modelo de programación es una copia 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 (completado
ciclo de actualización), que se guarda para registro y referencia, como la versión de la fecha de datos,
los modelos de cronograma objetivo y el modelo de cronograma de referencia. Las instancias
producen varias presentaciones de cronograma, como rutas críticas, recursos
perfiles, asignaciones de actividades, registro de logros, etc., y puede proporcionar pronósticos
basados en el tiempo a lo largo de
El ciclo de vida del proyecto. Cuando se usan juntas, las instancias admiten análisis, como el análisis
de varianza.
La presentación es una salida de instancias de modelo de programación, utilizada para comunicar
datos específicos del proyecto para
Informes, análisis y toma de decisiones.
Página 14
2
CAPÍTULO 1 INTRODUCCIÓN
1
1.2 ¿Por qué programar?
Los proyectos son generalmente proyectos complejos; sin embargo, un modelo de cronograma
detallado puede resultar en descomposición
proyectos en fases manejables o agrupaciones. El rendimiento del proyecto se informa y supervisa
cuando
Se registra el progreso de estas actividades e hitos. A medida que se registra el progreso en un
proyecto, el resto
El esfuerzo requiere una reevaluación. La ejecución de un proyecto a menudo no procede exactamente
como era inicialmente
planeado y baselined. En un entorno de proyecto típico, debido a una planificación inadecuada o un
proyecto significativo
cambios, se hace necesario refinar el modelo de programación. Esta evolución iterativa es necesaria
para predecir,
reconocer y abordar aquellos factores y problemas en evolución que potencialmente afectarán el
desempeño del proyecto. los
La clave para el éxito del proyecto es aplicar el conocimiento y la experiencia para crear un plan de
gestión del proyecto y luego
comprometerse a ejecutar el proyecto de acuerdo con el plan. La programación es uno de los
requisitos básicos del proyecto.
planificación y análisis de gestión.
La programación proporciona un plan detallado que representa cómo y cuándo el proyecto entregará
los productos,
servicios y resultados definidos en el alcance del proyecto y pueden servir como una herramienta para
la comunicación, la gestión
expectativas de las partes interesadas y como base para la presentación de informes de desempeño. La
naturaleza dinámica de la ejecución de un proyecto.
se sirve mejor con una herramienta que permita modelar el proyecto, las dependencias internas y
externas del proyecto,
y análisis debido al impacto del progreso y desarrollos imprevistos.
El modelo de programación apoya el proyecto al permitir:
• Fases temporales de las actividades requeridas.
• Movilización de recursos de la manera más eficiente.
• Coordinación de eventos dentro del proyecto y entre otros proyectos.
• Detección temprana de riesgos o problemas.
• Implementación de acciones para lograr los objetivos del proyecto según lo planeado
• Permitir el análisis de "qué pasaría si"
• Planeación de recursos
• Pronóstico de estimación al final
Esta Norma de práctica para la programación describe los componentes del modelo de programación
(consulte el Capítulo 4) y, en general
reconocidas buenas prácticas 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; hay
consenso sobre su valor y
utilidad. "Buena práctica" significa que existe un acuerdo general de que la aplicación de estas
habilidades, herramientas,
y las técnicas pueden mejorar la probabilidad de éxito en una amplia gama de proyectos. Buena
práctica hace
no significa que el conocimiento descrito siempre debe aplicarse de manera uniforme a todos los
proyectos; 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 dan como resultado un modelo de cronograma utilizable para la planificación, ejecución,
monitoreo, cierre y entrega
Página 15
3
1
del alcance del proyecto a las partes interesadas. El proceso Crear calendario comienza con la
selección de un método de programación
y herramienta de programación que admite el método de programación deseado, seguido de la
incorporación de datos específicos del proyecto
dentro de esa herramienta de programación, creando así un modelo de programación único ". El
resultado es una instancia de modelo de programación
Se utiliza para generar diversas presentaciones e informes. Consulte la Figura 11 para comprender
mejor las interrelaciones.
de los conceptos y terminología de la creación del modelo de cronograma. Este proceso da como
resultado un modelo de cronograma para el proyecto.
ejecución, monitoreo y control que responderán de manera predecible al progreso y los cambios. El
modelo de horario
se actualiza periódicamente para reflejar el progreso y los cambios, como el alcance, la duración, los
hitos, los recursos asignados,
tasas de productividad, metodología de trabajo o lógica de programación. Esta norma de práctica
para la programación también proporciona
Un proceso de evaluación que se puede utilizar para determinar qué tan bien se ajusta el modelo de
programación a este estándar.
Se desarrolla un índice de conformidad (consulte el Capítulo 5 de este estándar de práctica)
determinando qué componentes
se usan y cómo se usan dentro del modelo de programación. Para obtener una evaluación de
conformidad aceptable,
un modelo de programación, como mínimo, debe contener todos los componentes requeridos como se
describe en el Capítulo 4
y Apéndice D. La selección de una herramienta de software de programación adecuada proporciona
acceso a la
componentes necesarios para desarrollar el modelo de cronograma. El uso de este estándar de práctica,
junto con la experiencia,
la habilidad y la madurez organizacional guiarán la correcta 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 supone que todos los modelos de
cronograma deben tener los requisitos
componentes, comportamientos básicos y buenas prácticas; El tamaño y la complejidad del proyecto
solo dan como resultado cambios en la escala
y repetición de los componentes requeridos. Una guía para el cuerpo de conocimiento de gestión de
proyectos (PMBOK ®
Guía): la cuarta edición proporciona procesos para abordar los factores relacionados con el tamaño y
la complejidad del proyecto. En
Además, la definición de "generalmente reconocido" también supone que no hay diferencias
significativas para el
uso de los componentes requeridos en cuanto a las prácticas de programación dentro de varias
industrias. A medida que las prácticas evolucionan
y desarrollar dentro de la comunidad de gestión de proyectos después de la publicación de este
estándar de práctica, el
La definición de “generalmente reconocido” también evolucionará. Se pueden agregar más
componentes al conjunto central, y bueno
las prácticas deberían volverse menos subjetivas.
1.4 Propósito
El propósito de este Estándar de práctica para la programación es proporcionar pautas para el uso
efectivo de
gestión del tiempo para un proyecto al proporcionar conocimiento sobre la creación de modelos de
cronograma. Esta práctica
El estándar amplía la información contenida en el Capítulo 6 (sección Gestión del tiempo del
proyecto) del
Guía PMBOK ® — Cuarta edición. Además, para abordar adecuadamente las necesidades expresadas
por la dirección del proyecto
comunidad, es esencial proporcionar un medio para evaluar el grado de conformidad con esta práctica
estándar. Al hacerlo, este estándar de práctica establece un conjunto básico de componentes necesarios
para ser utilizados
para establecer un modelo de cronograma que cumpla con un grado mínimo aceptable de conformidad
con este
estándar de práctica y un método para acceder a un modelo de programación para la conformidad con
este estándar. El conjunto
Los componentes necesarios para cada modelo de cronograma deben describirse en el modelo de
cronograma del proyecto.
plan de manejo (ver Sección 3.1).
El objetivo final de este estándar de práctica es crear modelos de cronograma que tengan un valor
creciente para el
proyectos que representan.
Página 16
4 4
1
Figura 11. Programación
Página 17
5 5
1
No es el propósito de este estándar de práctica proporcionar una guía completa sobre cómo desarrollar
un
modelo de horario. Para obtener instrucciones completas sobre el desarrollo de un modelo de horario,
consulte los cursos y el texto.
libros sobre el tema.
1.5 Aplicabilidad
Este estándar de práctica está dirigido a profesionales de gestión de proyectos con conocimientos en el
fundamentos de la programación de proyectos. Para los propósitos de este estándar de práctica, estos
practicantes serán conocidos como planificadores.
La premisa de este estándar de práctica es que: el lector tiene un conocimiento básico del proyecto
Grupos de proceso de gestión y áreas de conocimiento tal como se definen en la Guía PMBOK ®
— Cuarta edición,
el proyecto tiene una estructura de desglose de trabajo (WBS) que se ajusta a los procesos definidos en
la Práctica
Norma para las estructuras de desglose del trabajo: segunda edición, y que se ha realizado la
planificación adecuada.
A medida que avanza el desarrollo del cronograma, los estándares de práctica relacionados, como
el Estándar de Práctica para Ganados
Gestión del valor: se puede aplicar la segunda edición.
Este estándar de práctica es aplicable solo a proyectos individuales, no a programas o carteras. Sin
embargo,
porque los programas y las carteras son colecciones de proyectos individuales, cualquier modelo de
calendario individual dentro de
esas estructuras deberían hacer uso de, y ser evaluadas de acuerdo con este estándar de práctica.
Además, una organización que abraza los principios y buenas prácticas descritos en esta norma y
los aplica globalmente en toda la organización asegura que todos los modelos de cronograma
desarrollados en apoyo de
Los proyectos de la organización se realizan de manera coherente en toda la organización.
Página 18
Página 19
7 7
2
CAPITULO 2
EL MODELO DE HORARIO PRINCIPIOS Y
CONCEPTOS
Este capítulo está diseñado para proporcionar orientación e información sobre los principios y
conceptos asociados.
con la creación y uso del modelo de programación. Este capítulo está dividido en las siguientes
secciones:
2.2 Métodos de programación
2.3 Técnicas de programación
2.4 La herramienta de programación
2.5 El modelo de horario
2.6 Las instancias y presentaciones del modelo de programación
Cada sección proporciona requisitos adicionales, terminología y funcionalidad asociada con estos
temas.
Estas secciones vinculan los procesos descritos en este capítulo con las buenas prácticas descritas en el
Capítulo 3 y
Los componentes de programación definidos en el Capítulo 4.
Los principios y conceptos del modelo de cronograma se representan en la Figura 21. La gestión del
modelo de horarios
plan identifica el método de programación y la herramienta de programación utilizada para crear el
modelo de programación. los
El proceso Crear programación incorpora todos los procesos definidos asociados con la programación
del proyecto.
esfuerzo (iniciación, planificación, ejecución, seguimiento y control y cierre). Dentro de este proceso
de modelado, todos
de las actividades e hitos requeridos del proyecto se definen y secuencian para lograr los objetivos del
proyecto.
El proceso Crear calendario incluye Definir actividades, Actividades de secuencia, Recursos
estimados de actividad,
Estime las duraciones de las actividades y desarrolle procesos de programación (consulte la Guía
de PMBOK ®, cuarta edición). los
el modelo de programación puede generar instancias de modelo de programación que producen
presentaciones (consulte la Figura 21). los
las instancias del modelo de programación pueden incluir, la línea base aprobada, los objetivos
seleccionados y los modelos de programación hipotéticos.
El proceso Crear programación da como resultado un modelo de programación aprobado utilizado por
los procesos en la Ejecución y
Monitoreo y control de grupos de procesos (consulte la Guía de PMBOK ® Cuarta edición), que
reacciona de manera predecible
y lógicamente para proyectar el progreso y los cambios. Una vez creado y aprobado (línea de base
establecida) el cronograma
el modelo se actualiza, según lo requiera el desempeño del proyecto y en apoyo de los informes
regulares del proyecto
intervalos, para reflejar el progreso y los cambios.
Durante la planificación del proyecto, un proceso para crear un modelo de cronograma que satisfaga
las necesidades del proyecto y su
los interesados comienzan.
Página 20
8
CAPÍTULO 2 EL MODELO DE HORARIO PRINCIPIOS Y CONCEPTOS
2
Figura 21. Programación de creación
Página 21
9 9
2
Muchos de los términos y conceptos discutidos en este resumen se explican con mayor detalle en el
Capítulo 3 de este estándar de práctica Las actividades definidas, basadas en el proyecto WBS, deben
identificarse y describirse de manera única,
comenzando con un verbo, incluye al menos un objeto específico único y aclarando adjetivos cuando
sea necesario.
Las actividades se secuencian con relaciones lógicas apropiadas. La cantidad, el nivel de habilidad y
las capacidades de
Se deben considerar los recursos necesarios para completar cada actividad, además de consultar la
actividad.
artistas al determinar la duración de cada actividad. Restricciones, incluidos los factores de tiempo de
adelanto / retraso,
no debe usarse en el modelo de programación para reemplazar la lógica de programación. La creación
del modelo de programación proporciona
una línea de base para permitir la comparación del progreso con el plan aprobado. Una descripción
general de la programación de creación
El proceso se ilustra en el diagrama de flujo y en la tabla de mapeo de componentes del proceso que se
muestra en las Figuras 22 (a)
y 22 (b).
2.2 Métodos de programación
El método de programación proporciona el marco para la creación del modelo de programación. La
programación más común.
El método, soportado por todas las principales herramientas de programación, es el método del
diagrama de precedencia (PDM). Con este
uso común y generalizado, a menudo se lo denomina método de ruta crítica (CPM). Otro popular
El método es una cadena crítica que se basa en CPM. Dentro de estos métodos, hay varias técnicas
como
como rolling wave, PERT, Monte Carlo, programación maestra integrada y ágil. El primer paso en
Crear
El proceso de programación es la selección de un método y una técnica apropiados. Algunas
organizaciones estandarizan
en una herramienta de software específica. En este caso, la decisión del método de programación ya se
ha tomado, ya que es
inherente a la herramienta, y no necesita hacerse de nuevo. Dado que es el método más utilizado, este
La práctica estándar se centra en CPM.
2.2.1 Método de ruta crítica
El método de ruta crítica (CPM) determina la duración total mínima del proyecto y lo más pronto
posible
fecha de finalización del proyecto, así como la cantidad de flexibilidad de programación (flotante
total) en el modelo de programación. A
aplicar CPM, se desarrolla un modelo de cronograma, que se compone de actividades del
proyecto. Fechas de inicio y finalización tempranas
se calculan para cada actividad mediante un pase adelantado, a partir de una fecha específica del
proyecto. Comienzo y finalización tardíos
las fechas se determinan para cada actividad mediante un pase hacia atrás, comenzando desde la fecha
de finalización temprana del proyecto
determinado durante el cálculo del avance o de una fecha de finalización específica del proyecto
(restricción).
Un principio básico de CPM es que cada actividad se terminará antes de que su sucesor pueda
comenzar. Sin
Varias mejoras, la red de CPM puro permite solo flotante total cero o positivo. CPM puro no
acomodar muchas de las características comunes de las aplicaciones de programación
actuales; incluyendo recurso,
calendarios de proyectos y actividades, restricciones, definiciones variables de criticidad, recursos,
duraciones transcurridas,
retrasos, dependencias externas, prioridades de actividad y la asignación de fechas reales de inicio y
finalización a
ocupaciones.
De uso común, el término CPM se refiere al método predominante utilizado en las herramientas de
programación modernas. En estos
herramientas, el método real suele ser el método de diagrama de precedencia (PDM) y esta práctica
estándar sigue
esa convención de uso común.
Página 22
10
2
Figura 22 (a). Diagrama de flujo para el modelo de programación
Página 23
11
2
Figura 22 (b). Tabla de mapeo de componentes del proceso
Página 24
12
2
2.2.2 Método del diagrama de precedencia
El concepto original de CPM era un proceso de modelado computarizado que utilizaba el estilo de
actividad en flecha
de diagramación. El método de diagramación de precedencia (PDM) se introdujo unos años más tarde
como un "no
enfoque computarizado para la programación "que ofrece una representación gráfica de la red más
limpia y fácil de seguir;
describió las actividades involucradas en un proyecto como cuadros o nodos, e introdujo relaciones
lógicas mejoradas (en
además de fin a inicio) y el uso de leads y rezagos. El resultado resultante es un diagrama de
precedencia, también conocido
como diagrama de red del proyecto. El enfoque de PDM a CPM se computarizó rápidamente y las
herramientas de programación modernas
colocar las actividades en nodos con flechas que vinculan actividades; los nodos de actividad pueden
contener información sobre la duración,
costo, recursos y limitaciones. La adición de múltiples calendarios de proyectos y restricciones
específicas del proyecto aún más
complicar los cálculos de CPM y el análisis de la red. Las aplicaciones de programación
computarizadas de hoy
hace que sea mucho más fácil lidiar con estos factores durante el cálculo del modelo de
programación. El resultado final es que para
En la mayoría de los proyectos, la ruta crítica ya no es una ruta de flotación cero, como estaba
presente en los primeros CPM. La salida resultante es
un diagrama de precedencia, también conocido como diagramas de red del proyecto. El PDM coloca
actividades en nodos con flechas
actividades de enlace; los nodos de actividad pueden contener información sobre duración, costo,
recursos y restricciones. PDM
toma menos nodos que ADM para describir el mismo conjunto de datos del proyecto. Aunque la
adición de múltiples calendarios
y las restricciones complican aún más los cálculos de pasadas hacia adelante y hacia atrás y el análisis
de red de
la red PDM, las aplicaciones de programación computarizadas de hoy completan los cálculos
adicionales sin
problemas. En la mayoría de los proyectos, la ruta crítica ya no es una ruta de flotación cero, como lo
era en los primeros CPM.
Los diagramas de precedencia ilustran las relaciones entre las actividades de izquierda a derecha (en
fases temporales), lo que permite
las actividades del proyecto fluirán desde un hito de inicio del proyecto hasta el hito completo del
proyecto. Relaciones entre
las actividades en fases temporales están representadas por flechas direccionales. Las relaciones
lógicas necesitan ser satisfechas.
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 la ejecución de manera realista y práctica. Los extremos
abiertos en un horario son
aquellas actividades que carecen de una actividad predecesora y / o sucesora, creando así un agujero o
brecha en el
Programe la lógica de principio a fin del proyecto. Los únicos fines abiertos que se deben esperar son
el inicio del proyecto.
y hitos de finalización del proyecto. El uso de restricciones, incluidos los adelantos y retrasos, debe
restringirse a aquellos
condiciones que no pueden ser adecuadamente definidas y modeladas por la aplicación de la lógica de
actividad.
En PDM, una actividad se puede conectar desde su inicio o su finalización. Esto permite una lógica de
inicio a fin
presentación sin necesidad de desglosar aún más el trabajo. Otra característica de los diagramas PDM
es el uso.
de componentes de plomo y retraso.
Un ejemplo de un diagrama de precedencia se muestra en la Figura 23.
2.2.3 Método de cadena crítica
La disponibilidad de recursos compite con la capacidad de ejecutar tareas en las fechas
planificadas. Como tal, muchos
los programas de software permiten nivelar los recursos (para que no se les asigne demasiadas
tareas); esto puede estirar el proyecto
duración y fechas de inicio y finalización programadas para las actividades. El modelo de
programación resultante, considerando el
disponibilidad de recursos, a menudo se denomina ruta crítica con recursos limitados y es el punto de
partida para
Página 25
13
2
programación de cadenas. El método de cadena crítica se desarrolla a partir del enfoque de CPM y
considera los efectos de
asignación de recursos, nivelación de recursos e incertidumbre de duración de la actividad en la ruta
crítica determinada por CPM.
Para hacerlo, el método de cadena crítica introduce el concepto de buffers y gestión de buffer. Tres
tipos de
los buffers están alimentando buffers, buffers de recursos y buffers de proyecto:
Tampones de alimentación. Se agregó un búfer (en duración) al modelo de programación al fusionar
rutas no críticas con
La ruta crítica del proyecto desde el CPM.
Buffers de recursos. El paso frecuente de las fechas de finalización del pronóstico a una actividad
predecesora que alerta a los recursos de la actividad sucesora que se preparará para comenzar a
trabajar en la fecha de finalización prevista de la actividad predecesora.
Buffers de proyecto. Una duración agregada al final del proyecto entre la última actividad del
proyecto y la final fecha de entrega o fecha de finalización contratada.
Los amortiguadores son márgenes de seguridad agregados y determinados estadísticamente asignados
a cadenas de actividades individuales.
Los buffers se crean asignando tiempos de realización de actividades agresivas para eliminar los
márgenes de seguridad ocultos y
agregando los ahorros resultantes de los tiempos planificados en buffers. En lugar de extender los
márgenes de seguridad entre
En todas las actividades, el margen de seguridad se concentra al final de una cadena y se usa solo si
existe riesgo (cualquiera que sea,
resultando en incertidumbres de recursos y duración) se materializa. Este efecto es similar a la gestión
de la flotación total.
y flotante libre en el método CPM. Un ejemplo de una cadena crítica se muestra en la Figura 24.
Figura 23. Ejemplo de diagrama de CPM / PDM
Page 26
14
2
Figura 24. Ejemplo de cadena crítica
El camino más largo a nivel de recursos a través del cronograma, incluidos los buffers, es la cadena
crítica, y a menudo es
diferente de la ruta crítica en CPM. Los factores que definen el método de la cadena crítica son las
actividades de amortiguación,
recursos que no son multitarea, nivelación de recursos y gestión de búfer.
El primer paso cuando se utiliza el método de cadena crítica para la programación es crear un método
agresivo (pero no
necesariamente detallado) plan de proyecto nivelado de recursos. La fecha de finalización del
proyecto se define como el final de la crítica
cadena, incluidos los amortiguadores para tener en cuenta los riesgos y resbalones del
proyecto. Durante la ejecución del proyecto, si las actividades
Si consumen una duración mayor a la prevista por el método de la cadena crítica, el buffer del
proyecto se consume gradualmente.
Según el grado de consumo de búfer (también denominado gestión de búfer), el equipo del proyecto
puede abordar
acciones correctivas necesarias; de "no es necesario reaccionar" a "planificar la respuesta" a "ejecutar
realmente el
respuesta planificada para recuperar el búfer del proyecto ". Mientras el total de deslizamientos sea
menor que el búfer, hay
efecto limitado en el alcance del proyecto, duración y presupuesto.
La cadena crítica se presenta como diferente de CPM en cuatro aspectos principales:
La constatación de que riesgos importantes e inesperados, que fueron imprevistos, se materializarán
durante un proyecto
y requerirá acciones proactivas.
El foco de atención gerencial —la cadena crítica— permanecerá bastante fijo durante todo el
proyecto.
Página 27
15
2
La contención de recursos es de tal magnitud en las estructuras organizacionales esbeltas de hoy en
día que la duración
de los proyectos depende de la disponibilidad de recursos en un grado no menor que en la secuencia
lógica de actividades.
En CPM, un margen significativo está contenido en todas las actividades, pero cuando está expuesto y
agregado (en lugar de ser
distribuido y oculto en actividades individuales), su absorción de riesgos será mayor en órdenes de
magnitud.
2.3 Técnicas de programación
Una vez que se establece un método de programación, se puede aplicar un grupo de técnicas a un
método. Algunos de los
Las técnicas más comunes son la planificación de olas rodantes, la programación ágil, PERT y la
simulación de Monte Carlo.
2.3.1 Planificación de olas rodantes
Usando la técnica de planificación de ondas onduladas, se realiza una descomposición detallada de las
actividades de alto nivel.
solo para aquellas actividades en el "corto plazo", por ejemplo, los próximos 90 días. La técnica de
planificación de ondas ondulantes
asume que es muy probable que el equipo del proyecto tenga información precisa y detallada sobre el
corto plazo
actividades y menos información sobre actividades en el futuro o más adelante en el proyecto. Un
principio importante para
la planificación de la ola rodante consiste en realizar la planificación detallada a intervalos
regulares. La planificación detallada para el próximo
El intervalo debe completarse mucho antes del inicio de la ejecución de la próxima ola.
Para períodos más allá de la ola de planificación detallada, las actividades se enumeran como
"paquetes de planificación" con mucho
Menos detalles. Estas actividades de planificación pueden contener información sobre costos y
recursos, que se fija en
La duración y el costo de referencia. Cuando se lleva a cabo una planificación detallada, reemplaza los
paquetes de planificación con
Detalles adicionales. La figura 25 ilustra un ejemplo de planificación de ondas onduladas.
Figura 25. Ejemplo de planificación de olas rodantes
Página 28
dieciséis
2
2.3.2 Técnica ágil
La gestión ágil de proyectos es similar a la planificación de la ola rodante, al tiempo que enfatiza el
logro de la capacidad de uso
resultados de forma rápida e iterativa. El equipo del proyecto Agile utiliza la programación de CPM
para cada ciclo de desarrollo, denominado
un sprint, que generalmente dura de dos a cuatro semanas. La gestión ágil de proyectos se centra en un
desarrollo más corto
ciclos y resultados tangibles a intervalos frecuentes e incrementales; el foco está en la realización de
beneficios provisionales
en lugar de completar actividades. Los elementos más importantes de una técnica ágil incluyen tener
múltiples
iteraciones de las fases del proyecto en lugar de pasar de una fase a otra. Otro ingrediente clave de la
Los métodos ágiles son la participación de las partes interesadas clave, principalmente el cliente /
usuario final, al final de cada
iteración para aprobar los productos de trabajo provisionales.
2.3.3 Evaluación del programa y técnica de revisión
Si bien es similar en principio a CPM y PDM, la técnica de evaluación y revisión del programa
(PERT) está enfocada
en duración de la actividad. PERT permite la duración de la actividad aleatoria y pondera la duración
estimada de la actividad en
el rango de estimaciones de duración proporcionadas por las partes interesadas. El desarrollo adicional
de las técnicas de estimación es
proporcionado en el Estándar de práctica para la estimación de proyectos .
Comenzando con un diagrama de precedencia, PERT permite que las estimaciones de duración de la
actividad se determinen permitiendo
por la incertidumbre contenida en el proceso de estimación de duración. Se requieren tres
estimaciones de duración para
cada actividad:
Duración optimista (la duración mínima de la actividad en las condiciones más favorables)
Duración más probable (la duración de la actividad que ocurrirá con mayor frecuencia)
Duración pesimista (la duración de la actividad en las condiciones menos favorables)
Duración de la actividad
IMPERTINENTE
Duración optimista 4 ( Duración más probable ) Duración pesimista
6 6
Las duraciones determinadas por la ecuación anterior se usan en el diagrama PERT como actividad
estimada
duraciones En general, las duraciones se establecen en un nivel de significación estadística específico
(por ejemplo,
95% de nivel de confianza). La ponderación en la ecuación fue una aproximación manual de la
distribución estadística.
Con cálculos más sofisticados, principalmente utilizando computadoras, una implementación de
estadística o múltiple
simulaciones PERT (SPERT) es posible, acercándose a los métodos y resultados del análisis de Monte
Carlo.
2.3.4 Simulación de Monte Carlo
La simulación de Monte Carlo considera la incertidumbre en la duración, el costo, los recursos y las
relaciones de una actividad,
etc., utilizando los riesgos del registro de riesgos para generar la incertidumbre en la duración de la
actividad o estimando esos
duraciones directamente como estimaciones optimistas, más probables y pesimistas para las
actividades. Una distribución de probabilidad
puede asignarse a cada actividad, que considera el nivel de confianza que las partes interesadas tienen
en las estimaciones.
Cuando hay más confianza en la estimación, una distribución de probabilidad con una desviación
estándar menor es
seleccionado y viceversa.
Página 29
17
2
Después de asignar estimaciones y distribuciones de probabilidad, se ejecuta la simulación de Monte
Carlo. Una simulación es
compuesto por muchas iteraciones, cada una de las cuales representa un posible resultado del
proyecto. Para cada iteración, duraciones
(y los costos resultantes, etc.) son seleccionados por el software de simulación Monte Carlo para ser
consistentes con el
distribuciones de probabilidad y tipos de actividad especificados por el equipo del proyecto. Esto
produce un horario grabado
instancia modelo con atributos para ruta crítica, duración y costo. Este proceso se repite varias veces,
resultando en una distribución de probabilidad de duración, costo, fechas de inicio y fechas de
finalización para cada actividad seleccionada
y finalmente el proyecto. La Figura 26 muestra una distribución de probabilidad de muestra para una
sola actividad.
Un análisis adicional puede determinar la frecuencia de actividades específicas que caen en la ruta
crítica y la identidad
de los riesgos más influyentes al conducir los resultados al nivel deseado de certeza. Actividades más
frecuentes en el
La ruta crítica y las que tienen riesgos de alta prioridad pueden ser monitoreadas de cerca para
aumentar la probabilidad de que
El proyecto se completará a tiempo. Se utiliza un software de aplicación especial para completar la
simulación de Monte Carlo.
2.4 La herramienta de programación
La herramienta de programación suele ser una herramienta específica de software que contiene
componentes de programación y las reglas para
interrelacionando estos componentes. Los componentes de programación se visualizan fácilmente
ejecutando un software de programación
aplicación y observar las diversas cosas en la herramienta de programación que están disponibles 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 y proporciona los medios
para ajustar varios parámetros y componentes típicos en un proceso de modelado. Por ejemplo, la
herramienta de programación
incluye la capacidad de:
• Seleccione el tipo de relación (como de principio a fin o de principio a fin) entre actividades.
• Agregue retrasos y pistas entre las actividades.
Figura 26. Distribución de probabilidad de duración de ejemplo para una sola actividad
Página 30
18 años
2
• Aplicar recursos a las actividades y utilizar la información de recursos junto con la disponibilidad de
recursos para
ajustar la programación de actividades.
• Asignar prioridades a las actividades que utilizan los mismos recursos durante el mismo período de
tiempo.
• Agregar restricciones a actividades donde la lógica (por ejemplo, relaciones de precedencia con otras
actividades) solo
no es adecuado para cumplir con los requisitos del proyecto, especialmente cuando se considera un
cronograma externo
controladores y disponibilidad de recursos.
• Capture una instancia de modelo de programación específica como línea de base.
• Realizar varios escenarios de análisis hipotético dentro del modelo de cronograma para obtener
diferentes proyectos finales.
fechas.
• Analizar el impacto que los posibles cambios en el modelo del cronograma tendrían sobre los
objetivos del proyecto.
• Compare la instancia de modelo de programación más reciente con una instancia de modelo de
programación anterior o
contra la instancia de línea base aprobada para identificar y cuantificar las variaciones y tendencias.
2.5 El modelo de horario
La introducción de datos específicos del proyecto, como las actividades, duraciones, recursos,
relaciones y
Las restricciones en la herramienta de programación crean un modelo de programación para el
proyecto dado.
El análisis del modelo de programación compara los cambios en el modelo de programación según las
actualizaciones de progreso, costo,
y alcance con las expectativas del equipo del proyecto sobre el impacto de estos cambios. El equipo
del proyecto utiliza el
modelo de programación para predecir las fechas de finalización del proyecto en forma de instancias
de modelo de programación. El modelo de horario
proporciona pronósticos basados en el tiempo, reaccionando a los aportes y ajustes realizados a lo
largo del ciclo de vida del proyecto.
2.6 Las instancias y presentaciones del modelo de programación
La instancia del modelo de programación se utiliza para producir presentaciones para informar sobre
elementos, como
rutas, perfiles de utilización de recursos, listas de actividades, listas de asignación de actividades,
registros de logros, ganado
datos del sistema de gestión de valor, presupuesto por etapas y costos por etapas. Las instancias del
modelo de programación
Se utilizan para generar diversas presentaciones. Estos resultados de datos específicos del proyecto
respaldan el análisis de
equipo del proyecto, incluidos los interesados (ver Figura 27).
Una presentación, en su forma más simple, es una tabla de actividades con las fechas programadas
asociadas. Presentaciones
se utilizan para comunicarse con los interesados cuando se espera que ocurran actividades y eventos
del proyecto.
Las presentaciones de recursos también pueden identificar el recurso, ya sea por una persona
específica, rol o sistema / herramienta / etc. ese
será requerido para completar las actividades.
El término "cronograma" a menudo se usa para referirse tanto al modelo de cronograma como a la
salida de actividades con
sus fechas asociadas Para mayor claridad y coherencia con la Guía PMBOK ® — Cuarta edición, esta
práctica
El estándar define los datos específicos del proyecto dentro de la herramienta de programación como
un modelo de programación y el resultado
salidas, basadas en los datos específicos del proyecto, como presentaciones de instancias de modelo de
programación (ver Figuras 21 y
27). Las presentaciones de instancias del modelo de programación se pueden representar de muchas
maneras, que incluyen pero no se limitan a
Page 31
19
2
listas simples, gráficos de barras con fechas, diagramas lógicos de red con fechas, patrones de uso de
recursos y costos,
hitos, horarios maestros, listas de trabajo departamentales, listas de trabajo en equipo y fechas de
entrega entregables. Existen
muchas otras posibles presentaciones de horarios. Programar presentaciones de instancias modelo
puede tomar la forma de un
programa de inicio temprano, programa de inicio tardío, programa de línea de base, programa de
recursos limitados u horario objetivo.
Otros tipos de horarios son en realidad derivados de estos cinco tipos básicos de horarios. Dichos
derivados incluyen
horarios maestros, horarios importantes y horarios resumidos. El uso de estos términos puede variar de
proyecto a proyecto y organización a organización.
Figura 27. Programar presentaciones de instancias de modelo
Página 32
Page 33
21
3
CAPÍTULO 3
PROGRAMA MODELO BUENAS PRÁCTICAS
RESUMEN
Este capítulo está diseñado para proporcionar orientación e información sobre buenas prácticas
generalmente aceptadas
asociado con los procesos de planificación, desarrollo, mantenimiento, comunicación y presentación
de informes de una efectiva
modelo de horario. Este capítulo está dividido en las siguientes secciones:
3.1 Gestión del modelo de horarios
3.2 Programación de la creación del modelo
3.3 Programa de mantenimiento del modelo
3.4 Análisis del modelo de programación
3.5 Comunicación e informes
Cada sección proporciona requisitos comunes, terminología y funcionalidad asociada. Estas secciones
vincular la discusión de los procesos de programación descritos en el Capítulo 2 a los componentes de
programación definidos
en el Capítulo 4. Este capítulo proporciona una visión general, con ejemplos, de cómo crear y
mantener una
modelo de horario.
3.1 Gestión del modelo de horarios
La gestión del modelo de programación abarca los esfuerzos relacionados con la programación del
equipo del proyecto como parte de
el proceso Desarrollar el Plan de Gestión del Proyecto de acuerdo con la Sección 4.2 de la Guía
PMBOK ® Cuarto
Edición. La gestión del modelo de horarios ayuda a garantizar que todo el proceso de gestión de
proyectos aplicable
Los grupos y las áreas de conocimiento se integran adecuadamente dentro del modelo de
programación general. Un modelo de horario
requiere planificación y diseño de la misma manera que cada proyecto entregable es planeado y
diseñado.
El equipo del proyecto debe considerar una serie de factores para crear un modelo de cronograma que
pueda ser una herramienta útil para
el proyecto. Esta herramienta se utilizará para monitorear el desempeño del proyecto, comunicar
información sobre
el trabajo y compare el trabajo planificado con el progreso real. Estos conceptos se desarrollarán en
apoyo
del desarrollo del plan de gestión del proyecto de acuerdo con la guía PMBOK ® .
La gestión del modelo de programación aborda lo siguiente:
• Procesos y procedimientos para la gestión de datos del modelo de programación, como el formato de
datos, el control de versiones,
accesibilidad, almacenamiento y recuperación de los datos.
• Políticas relacionadas con la metodología que se utilizará en el desarrollo del modelo de cronograma
y
mantenimiento, como umbrales de rendimiento, contenido y frecuencia de presentaciones e informes,
implementación e integración de gestión del valor ganado (EVM), compatibilidad con otros proyectos
planes, seguimiento de riesgos y granularidad de actividad. Al determinar la granularidad de la
actividad, demasiados detalles
34
22
CAPÍTULO 3 PROGRAMA MODELO BUENAS PRÁCTICAS RESUMEN
3
produce un modelo de programación confuso y demasiado grande que es difícil y costoso de
administrar; también
Un pequeño detalle significa que no hay información suficiente para el control continuo del proyecto.
• Consideraciones sobre obligaciones contractuales y posibles responsabilidades contractuales
(reclamos, mediación, arbitraje,
litigios, etc.).
• Procesos y procedimientos para planificar, actualizar y mantener el modelo de programación durante
el
ciclo de vida del proyecto; determinación de un ciclo apropiado para recopilar el estado del proyecto y
actualizar
El modelo de horario. El tiempo de ciclo entre actualizaciones debe ser suficiente para la información
del
La última actualización será emitida, analizada y aplicada por el equipo del proyecto antes de la
próxima actualización. los
el ciclo de actualización debe cumplir con el contrato o los activos del proceso organizacional.
• Requisitos de capacitación para los miembros del equipo del proyecto, como una comprensión
común de la programación.
políticas, procedimientos y tecnologías de software, por ejemplo, informes de progreso, captura de
proyectos
riesgos, y reflejando actividades de mitigación en el modelo de cronograma.
3.1.1 Plan de gestión de datos programados
Antes de agregar datos al modelo de cronograma, el equipo del proyecto debe enfocarse en el diseño
adecuado del modelo de cronograma.
El equipo del proyecto debe definir algunas entradas del modelo de programación básica y las salidas
esperadas para garantizar que
Se establece una infraestructura mínima, necesaria para respaldar los requisitos de las partes
interesadas. Además, el alcance,
la estructura de desglose del trabajo (WBS), la definición de recursos (cuando sea necesario) y otros
componentes del cronograma deben
ya esté definido para que el equipo no tenga que definir estos elementos mientras desarrolla el
cronograma
modelo. Como mínimo, el equipo del proyecto debe considerar lo siguiente al desarrollar los datos del
cronograma
plan de gestión:
• Defina la lista de usuarios programados, los derechos de acceso y las responsabilidades que tendrá
cada uno. por
Por ejemplo, algunos usuarios proporcionarán progreso, mientras que otros tendrán un mayor acceso a
la programación y serán
responsable de las funciones administrativas.
• Determine la frecuencia (es decir, diaria, semanal o mensual) para la copia de seguridad de los datos
del cronograma. Las copias de seguridad son
Una parte importante de la gestión de la configuración de datos programados. Las frecuencias
requeridas de las copias de seguridad son
a menudo establecido por las expectativas de los interesados.
• Determine cómo se recuperarán las versiones anteriores de la programación, a qué intervalos, y
verifique que
Los procedimientos para la recuperación de datos son precisos. Un error común es que se realizan
copias de seguridad
pero no hay procedimiento de recuperación.
• Determinar los requisitos de retención de datos para los datos del cronograma.
• Identificar los riesgos asociados con el desarrollo del modelo de cronograma relacionado con los
datos del cronograma.
administración.
• Determinar los requisitos de la jerarquía de datos para fines de informes (como se define en la
comunicación
plan) y cómo estos requisitos afectarán el proceso y los datos de gestión de datos programados
modelo. Por ejemplo, los tipos de actividades que se muestran al comité directivo son diferentes a las
mostrado al gerente del proyecto.
Página 35
23
3
3.1.2 Plan de gestión del modelo de programación
El plan de gestión del modelo de programación es una colección de procesos, métodos, plantillas y
herramientas para
cumpliendo los objetivos del cronograma del proyecto. La buena práctica dicta que, todos los modelos
de horario deberán ser
guiado por una metodología que proporciona una lista de verificación de requisitos para el modelo de
programación con el fin de garantizar
La calidad del modelo de horario.
El plan de gestión del modelo de programación permite que los miembros del equipo del proyecto se
desempeñen de manera consistente.
Los proyectos sin plan tienden a ser ineficientes, lo que resulta en un mayor costo, un mayor riesgo y
una mayor duración del proyecto.
El plan de gestión del modelo de programación incluye lo siguiente:
.1 Selección de un método de programación
El equipo del proyecto, con el planificador como facilitador, debe tener acceso a la documentación
sobre
Los métodos de programación disponibles aprobados por la organización para cumplir con la
organización
y requisitos del proyecto. En base a esta información, el planificador implementa el método de
programación como
determinado por el equipo del proyecto. (Para obtener más información sobre los métodos de
programación, consulte la Sección 2.2.)
.2 Selección de una herramienta de programación
La selección de la herramienta de programación se basará en el método de programación seleccionado
y
cumplir con los requisitos de organización y proyecto relacionados con la herramienta.
.3 Plan de Creación del Modelo de Horario
El gerente del proyecto, junto con el equipo del proyecto y las partes interesadas clave, determina la
plan para la creación del modelo de horario. Las consideraciones clave incluyen: planificación de olas
rodantes y partes interesadas
participación en el proceso Desarrollar horario de acuerdo con la Guía PMBOK ® — Cuarta edición.
.4 Programar ID de modelo
Cada modelo de cronograma debe tener un método de identificación único específico para el proyecto.
.5 Versión del modelo de programación
Cada instancia del modelo de programación tiene un identificador de versión único. La ubicación de
este
la identificación puede variar según los activos del proceso organizacional y las herramientas
utilizadas para controlarlo. UNA
El identificador único de la versión del modelo de programación es esencial para permitir el archivo
adecuado de los documentos del proyecto.
y procesos de auditoría. El plan de gestión del modelo de programación proporcionará el formato para
este componente
para que no se produzcan nombres redundantes.
.6 Calendarios y períodos de trabajo
Un calendario de proyecto predeterminado se define utilizando períodos de trabajo. Los períodos de
trabajo también se pueden definir para
actividades específicas o partes del proyecto, incluidos los recursos. Algunos de los elementos del
calendario incluyen:
• Definir los días hábiles en una semana.
• Defina el número de turnos que se trabajarán cada día.
• Definir la cantidad de horas a trabajar cada turno o día.
Page 36
24
3
• Definir cualquier período de trabajo programado de "horas extras".
• Definir el tiempo no laborable (por ejemplo, días festivos, paradas, fechas restringidas, horarios
restringidos, etc.).
Estos elementos juegan un papel importante en la determinación del número y la estructura de los
calendarios del proyecto.
requerido para el horario. El uso de múltiples calendarios introduce una complejidad significativa en
el cálculo del flotador y la ruta crítica. Sin embargo, mientras que la programación se simplifica
mediante el uso de un solo
calendario, un calendario puede ser inadecuado para administrar el proyecto (p. ej., un equipo de
proyecto internacional
con feriados locales asociados).
La práctica generalmente aceptada es usar 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
del proyecto será usado
como el calendario predeterminado para las actividades del proyecto. Esta práctica permite al equipo
del proyecto establecer y
programar diferentes períodos de trabajo o calendarios, si es necesario, para ciertas actividades.
.7 Ciclo de actualización del proyecto
El ciclo de actualización es el intervalo regular en el que se informa el estado del proyecto. los
Se determina la frecuencia apropiada para realizar actualizaciones y reportar el estado en relación con
el cronograma.
Esto incluye determinar en qué punto del ciclo se producirá la actualización y con qué frecuencia el
estado
será reportado El ciclo de actualización refleja cómo la administración tiene la intención de utilizar los
datos generados a partir de
el modelo de cronograma, que incluye el momento de las reuniones de revisión, los requisitos de
informes de gestión,
y ciclos de pago que a menudo están vinculados a actualizaciones. Seleccione un ciclo de
actualización que proporcione administración
con un nivel óptimo de información de control sin ser demasiado gravoso para las personas que lo
hacen
El informe y el análisis. El ciclo óptimo de actualización variará con la industria y la intención del
proyecto:
desde actualizaciones por hora para proyectos de interrupción planificada para instalaciones de
fabricación / producción hasta semanalmente o
actualizaciones mensuales para grandes proyectos de construcción o desarrollo de software. El ciclo
de actualización elegido
tiene una relación directa sobre 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:
informes de progreso
y mantenimiento. 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 una serie de factores, como la tasa de
cambio en el
proyecto, la duración del proyecto, etc. Para proyectos relativamente estables, a largo plazo, de bajo
riesgo, mensualmente o
El ciclo de estado bimensual puede ser apropiado. Para proyectos volátiles de alto riesgo, se pueden
requerir actualizaciones
por cada cambio de turno o por hora.
El equipo del proyecto debe considerar qué escala de tiempo se debe usar: minutos, horas, días,
semanas,
o meses; la respuesta depende de la frecuencia de los procesos de control y del nivel de detalle
necesario
en las actividades La mayoría de las veces, las escalas de tiempo de actividad permanecerán
consistentes durante todo el proyecto.
Sin embargo, las evoluciones de proyectos específicos pueden requerir diferentes escalas de tiempo
efectivas para esa evolución.
.8 Estructura de codificación de hitos y actividades
Comprender los tipos de informes, necesarios desde el modelo de programación para crear una
presentación (consulte la Figura 27) del modelo de programación proporciona orientación sobre las
estructuras de codificación que se incorporarán al
modelo de horario.
Page 37
25
3
Se debe desarrollar una estructura de codificación para seleccionar, ordenar y agrupar los datos del
cronograma.
Se puede lograr fácilmente. Esta codificación proporcionará asistencia en el desarrollo y
mantenimiento.
del modelo de cronograma, así como cumplir con los requisitos de informes del
proyecto. Codificación bien diseñada
las estructuras también son útiles para analizar los datos de rendimiento del proyecto agrupando,
seleccionando y ordenando
para resaltar tendencias y anomalías.
Se debe enfatizar el uso de una estructura de codificación de actividad sólida y bien concebida que sea
separado del identificador de actividad. Las actividades se pueden codificar con más de un código
para cada actividad,
con cada código que tiene un valor separado, lo que permite personalizar las salidas para diferentes
propósitos. por
Por ejemplo, los códigos se pueden utilizar para identificar fases del proyecto, subfases, ubicación del
trabajo, eventos del proyecto, puertas,
logros importantes, fuentes de suministro, fuente de diseño, la persona u organización responsable
para realizar la actividad, etc. Estos códigos se pueden usar solos o en múltiples combinaciones. Para
lograr flexibilidad
y la funcionalidad mejorada, la mayoría del software de programación admite múltiples códigos para
cada actividad.
Un esquema estructurado de numeración o identidad de la actividad debe formar parte del diseño
general de codificación.
El uso de un sistema estructurado de identificación de actividades proporciona a los usuarios del
horario una mejor comprensión.
de cómo una actividad particular encaja en la imagen más grande del proyecto al comprender la
importancia de la actividad
identificador en sí mismo. Por ejemplo, el esquema de identidad puede incluso vincularse al proyecto
WBS. Como mínimo,
Un identificador de actividad debe ser único y seguir un esquema apropiado para el proyecto.
.9 Planificación de recursos
Si el modelo de programación debe incluir recursos de cualquier tipo, la gestión del modelo de
programación plan identifica los elementos necesarios para la planificación y gestión de recursos. Los
elementos a considerar son
disponibilidad de recursos, calendarios de recursos y conjuntos de habilidades de recursos. Aunque la
carga de recursos de la no se requiere un modelo de horario, este estándar de práctica lo considera una
buena práctica y reconoce
que el equipo del proyecto debe considerar los recursos al determinar la duración de la actividad y
secuencia de actividad. Un cronograma cargado de recursos indica claramente las interdependencias e
impactos.
que la disponibilidad de recursos tendrá en la duración del proyecto y el costo.
.10 Indicadores de rendimiento
Para que los interesados sepan cómo se está desempeñando el proyecto, muchos proyectos definen el
desempeño clave indicadores (KPI) que permiten al equipo del proyecto medir el progreso y el
rendimiento hacia valores predefinidos objetivos del proyecto (p. ej., calificaciones / comentarios del
cliente, calificaciones del equipo del proyecto y EVM). EVM tiene la habilidad
combinar medidas de alcance, cronograma y costo en un solo sistema integrado que proporciona
Indicadores basados en costos. EVM se puede ampliar para incluir el concepto de cronograma ganado,
que tiene
El objetivo de proporcionar indicadores basados en el tiempo para complementar los indicadores
basados en los costos del proyecto
actuación. Para obtener más información sobre EVM y el horario ganado, consulte el Estándar de
práctica para
Gestion del valor ganado.
.11 Modelo de horario maestro
El modelo de programación puede diseñarse y construirse como un proyecto maestro que contiene
subproyectos. los
Los subproyectos pueden estructurarse de acuerdo con los diversos equipos que componen el
proyecto, como
38
26
3
ejecución por fases (ingeniería, producción, pruebas e integración), equipos distribuidos globalmente,
o
La estrategia de contratación (proyectos múltiples, gerentes de proyectos múltiples). Estos
subproyectos deben ser
vinculados entre sí en ciertos puntos identificados de entrega / aceptación o interfaz, asegurando que
haya
Es una conexión entre los planes. El plan de gestión del modelo de programación definirá los pasos
utilizados para
crear, administrar y controlar la programación maestra, los subproyectos y las interdependencias del
proyecto.
3.2 Programación de la creación del modelo
Esta sección ofrece una descripción general de los elementos esenciales para desarrollar un buen
modelo de programación.
Las buenas prácticas se muestran para cada componente contenido en la lista de componentes de este
estándar de práctica
en el Capítulo 4. Se recomienda enfáticamente una revisión del Capítulo 4 para comprender todos los
aspectos asociados con
cada componente Es crucial tener en cuenta toda la información, procedimientos y restricciones.
documentado en la sección de gestión del modelo de programación.
El propósito del modelo de cronograma es proporcionar un plan detallado útil que pueda ser utilizado
por el gerente del proyecto
y el equipo del proyecto para ayudarlos a completar el proyecto con éxito. El modelo de horario se
convierte en un
herramienta desarrollada por el equipo del proyecto que documenta la visión del equipo de cómo se
realizará el proyecto.
El modelo de cronograma incluye cuándo se supone que las actividades comienzan y finalizan, y se
modifica adecuadamente para
reflejar los cambios en el progreso, el alcance, etc., a medida que se agregan al modelo de cronograma
durante el ciclo de vida del proyecto.
Un modelo de programación bien desarrollado es una herramienta dinámica que se utiliza para
proporcionar una predicción razonable de cuándo
Se puede esperar que el trabajo restante del proyecto se realice. Simultáneamente, permite que el
equipo del proyecto mire
en el desempeño del proyecto hasta la fecha, y use esos datos para hacer pronósticos precisos de las
evoluciones del proyecto
que quedan por cumplir. Además, una vez que el proyecto se ha completado, se forma el modelo de
cronograma.
Es la base de las actividades de lecciones aprendidas y se convierte en la base de proyectos similares
en el futuro.
El modelo de cronograma describe el trabajo a realizar (qué), los recursos necesarios para realizar el
trabajo (quién
y qué), y la secuencia de actividad óptima que incluye el inicio, el final y las relaciones de la actividad
(cuándo). los
La forma de hacer el trabajo (cómo) está definida por otros documentos en el plan general del
proyecto. Establecer un realista y
El modelo de cronograma alcanzable es una de las acciones iniciales críticas. Algunos puntos
importantes a considerar durante el
la creación del modelo de horario son:
• Determinar que los requisitos del proyecto son entendidos y satisfechos. El equipo del proyecto
revisa y
comprende los documentos de alcance del proyecto con especial énfasis en la WBS. Los proyectos
Los documentos de alcance proporcionan los antecedentes, la información y la comprensión
necesarios para desarrollar el cronograma
modelo. El objetivo es garantizar que todos los aspectos de la ejecución del proyecto se hayan
definido adecuadamente y
incluido en el modelo de horario. Las actividades en el modelo de cronograma representan el trabajo
que produce el
entregables o paquetes de trabajo identificados en la WBS; por lo tanto, todos los paquetes de trabajo
en la WBS deben ser
directamente rastreable a una actividad programada o grupo de actividades. A menudo se pueden
organizar las actividades del horario.
para reflejar la jerarquía de la WBS. Por el contrario, cada actividad debe acumularse en un solo
elemento PEP.
• Verificar disponibilidad de recursos y asignaciones. El equipo del proyecto se beneficia
enormemente de un recurso cargado
programar. La fuerza laboral, el material, el equipo y la infraestructura necesarios para llevar a cabo
las actividades del proyecto.
se puede planificar antes de la necesidad y se pueden mitigar los problemas previstos. Un modelo de
horario básico
Página 39
27
3
producido para un proyecto supone que hay suficiente mano de obra y equipos disponibles para lograr
Las actividades según lo programado. Este no es siempre el caso porque en un proyecto grande o
complejo, puede
No es obvio que existe una deficiencia de recursos. En el caso de proyectos grandes y complejos que
involucren
múltiples organizaciones y tienen una larga duración, puede ser necesario incluir recursos en el
cronograma
modelo. Consulte la Guía PMBOK ® — Cuarta edición para obtener más información sobre los
recursos. Así como los códigos de actividad
se puede usar para clasificar y organizar actividades, se pueden asignar códigos de recursos (atributos)
a los recursos
para clasificar los recursos de acuerdo con la organización, nivel o tipo de habilidad, estructura de
informes, etc. Además,
Las ID de recursos pueden estructurarse en un esquema significativo, similar en naturaleza a las ID de
actividades.
3.2.1 Desarrollar la línea base del modelo de cronograma
El desarrollo de un buen modelo de cronograma se logra a través de la aplicación consistente de
sonido general
prácticas La experiencia adquirida con el tiempo ayudará a seleccionar las respuestas apropiadas a los
requisitos de diseño.
para modelo de horario. Los pasos clave incluyen:
.1 Definir hitos
Una vez que se comprende la estructura general de los datos del proyecto discutidos anteriormente,
comenzar a diseñar los hitos del proyecto. Los hitos tendrán una duración cero, no se asignarán
recursos,
se utilizará como puntos de referencia para medir el progreso y también puede reflejar los puntos de
inicio y finalización para
Varios proyectos de eventos. En general, un hito representará el inicio o la finalización de una parte o
entregable del proyecto y también puede estar asociado con restricciones externas, como la entrega
de permisos o equipos específicos requeridos. Cada proyecto debe tener un hito de inicio y un final
hito. El proyecto contendrá una lista de hitos desarrollados inicialmente como el modelo de
cronograma es
creado. Estos pueden haberse originado en el cliente, los miembros del equipo u otras partes
interesadas. Como el
se desarrolla el modelo de cronograma se agregan hitos adicionales según sea necesario. Es un
proceso iterativo.
(Nota: Las actividades pueden definirse antes de los hitos).
.2 Diseñar las actividades del proyecto
Comience a crear la lista de actividades que deberán realizarse para completar el proyecto, en función
de
en la WBS y elaborado por el equipo que se encargará de la ejecución del trabajo. los
Las características de una actividad bien diseñada incluyen:
• La actividad es un elemento (o bloque) de trabajo medible y discreto que es un elemento tangible
del alcance del proyecto.
• Una sola persona es responsable del desempeño de la actividad. Esto no excluye la
idea de que se pueden requerir múltiples recursos para llevar a cabo la actividad, pero sí requiere que
Una sola entidad es responsable de su desempeño. Esa persona debe ser la misma que lo hará
Informar sobre el progreso de la actividad.
• Las actividades describen el trabajo que debe realizarse. Como tal, la descripción de cada
La actividad comienza con un verbo y contiene un objeto único y específico. Aunque "verter pared"
puede ser
descriptiva de una tarea, la descripción de la actividad debe ser más específica. Los adjetivos pueden
ser útiles.
Page 40
28
3
para aclarar ambigüedades. Por ejemplo, “pour la fundación pared este de X a Y ” o “revisión Capítulo
3
en terminología ". La descripción de cada actividad debe ser única y no dejar lugar a confusión, que
es decir, se puede identificar sin ambigüedad y debe ser independiente de la presentación del horario
agrupación u organización.
• El trabajo representado por una actividad, una vez iniciada, debe ser capaz de continuar hasta su
finalización.
sin interrupción (a excepción de los períodos no laborales que ocurren naturalmente en el
calendario). Si el
el trabajo en una actividad se suspende o retrasa, a menudo es beneficioso dividir la actividad en
dos o más actividades en puntos de ruptura naturales.
Por lo general, la duración de una actividad debe ser inferior a dos veces el ciclo de
actualización. Esto permite la presentación de informes.
del inicio y finalización de una actividad dentro de uno o dos ciclos de actualización, lo que permite a
la administración centrarse en
desempeño y acción correctiva si es necesario. Las excepciones a esta regla general son actividades
continuas (por ejemplo,
actividades sumarias como aburrir un túnel de 2 millas de largo o pavimentar varias millas de
carretera), adquisiciones
actividades donde un solo elemento de trabajo (por ejemplo, fabricar y enviar un componente a un
sitio remoto) puede llevar
significativamente más largo que dos ciclos de actualización, o una actividad de nivel de esfuerzo
(LOE) como el soporte administrativo.
En estos casos, la duración de la actividad simplemente debe reflejar el tiempo previsto para la
actividad. El cuidado necesita
se darán a actividades LOE, porque si se les da duraciones estáticas iguales a la duración de todo el
proyecto,
pueden terminar o conducir el camino crítico. Por su propia naturaleza de apoyar actividades de
trabajo detalladas,
Los LOE no pueden conducir la duración del proyecto y no pueden ser críticos. Es una buena práctica
definir actividades LOE
de tal manera que tomarán su duración de las actividades detalladas que apoyan.
Cuando se complete, la lista de actividades describirá el 100% del trabajo requerido para completar el
proyecto,
aunque no todas las actividades necesariamente deben ser completamente detalladas si se utiliza la
planificación de la ola rodante.
.3 Actividades de secuencia
La secuencia de actividades e hitos junto con la lógica es la base de cualquier modelo de
programación.
El método de conexión se define como una relación. Cada actividad e hito excepto el primero (con
sin predecesor) y el último (sin sucesor) debe estar conectado a al menos un predecesor y uno
sucesor. Con la excepción del hito de inicio, algo debe ocurrir antes de que comience cualquier
actividad,
y a su vez, esa actividad tiene que completarse total o parcialmente para permitir que comience otra
actividad. Asegurando
El cumplimiento de esta práctica evitará que el programa contenga fines abiertos, donde las
actividades o
faltan predecesores o sucesores de hitos, con la excepción del primer y último hito.
Típicamente, cada actividad predecesora terminaría antes del comienzo de su actividad sucesora (o
actividades) (conocido como una relación de fin a inicio (FS)). A veces es necesario superponer
actividades;
se puede seleccionar una opción para usar inicio a inicio (SS), fin a fin (FF) o inicio a fin (SF)
relaciones La Figura 31 proporciona ejemplos de los cuatro tipos de relación en PDM (el más común
metodología de CPM utilizada). Siempre que sea posible, se debe utilizar la relación lógica FS. Si
otros tipos
de las relaciones se usan, deben usarse con moderación y con una comprensión completa de cómo
Las relaciones se han implementado en el software de programación que se utiliza. Idealmente, la
secuencia de
todas las actividades se definirán de tal manera que el inicio de cada actividad tenga una relación
lógica desde
un predecesor y el final de cada actividad tiene una relación lógica con un sucesor.
Page 41
29
3
Actividad X
Actividad Y
Terminar para comenzar
FS
El inicio de la actividad sucesora.
depende de la finalización de la
actividad predecesora.
En este ejemplo, la actividad X debe estar completa
antes de que la actividad Y pueda comenzar.
Finish to Finish
FF
La finalización de la actividad sucesora.
depende de la finalización de la
En este ejemplo, la actividad X debe estar completa
antes de que la actividad Y pueda terminar.
Empezar a empezar
SS
El inicio de la actividad sucesora.
depende de la iniciación de la
En este ejemplo, la Actividad Y puede comenzar después
La actividad X ha comenzado.
Empezar a acabar
SF
La finalización de la actividad sucesora.
depende de la iniciación de la
En este ejemplo, la Actividad Y no puede completarse
hasta que la Actividad X haya comenzado.
Actividad X
Actividad Y
Actividad X
Actividad Y
Actividad X
Actividad Y
Figura 31. Ilustraciones de los tipos de relación en la metodología CPM
Los retrasos también pueden asignarse a algunas relaciones. Un retraso impone un retraso entre el
precedente y
actividad subsiguiente Por ejemplo, si una actividad tiene una dependencia SS con un retraso de 1 5
días, se retrasaría
El inicio de la actividad sucesora hasta 5 días después de que la actividad predecesora haya
comenzado. El planificador es
advirtió a usar 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. Algunos programadores
pueden verse tentados
usar retrasos para representar un período de tiempo en el que el trabajo realmente está ocurriendo,
como la revisión de un documento
antes de que continúe la siguiente fase. Se recomienda que este tipo de trabajo se muestre como
actividades en el
programar el modelo en lugar de usar un retraso. Cuando se incluyen tales actividades, podrían
codificarse para mostrar que
Estas son actividades de las cuales es responsable otra parte, por ejemplo el cliente. Esta práctica
permite
mejora el control del proyecto y lo hace muy visible si una entidad específica está impactando el
proyecto.
El uso de más de un calendario en un modelo de programación puede afectar los resultados de retraso
calculados dentro de
El modelo de horario. Además, comprender cómo los diferentes paquetes de software utilizan
múltiples
Los calendarios son extremadamente importantes.
Page 42
30
3
También es posible asignar restricciones a actividades e hitos que requieren la actividad o hito para
comenzar o terminar en puntos específicos en el tiempo. Estudie los diversos tipos de restricciones
que podrían usarse y comprenda
El efecto y los matices que su uso tiene sobre el programa antes de su uso. 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, como un
Por ejemplo, la utilización de restricciones generalmente se reconoce como necesaria para cumplir con
las obligaciones contractuales.
En general, cada actividad debe tener un predecesor FS o SS y un sucesor FS o FF. Sin estos
tipos de relaciones lógicas, las actividades se denominan "colgantes" y la incertidumbre en su
duración no
necesariamente se transmitirá al resto del modelo de programación como deberían ser.
.4 Determinar recursos para cada actividad
Estimate Activity Resources es el proceso de determinar el tipo y las cantidades de material,
personal, equipo o infraestructura requerida para realizar cada actividad. Si un proyecto está
restringido en
los términos de recursos y la duración del proyecto podrían verse afectados, los recursos deberían
incorporarse en
El modelo de horario. Aunque a veces se realiza en conjunto, el proceso de estimación de recursos de
actividad
debe completarse antes de la Duración estimada de la actividad (consulte la Guía
de PMBOK ®, Cuarta edición para
más información). Las horas necesarias para que un diseñador senior realice la actividad en
comparación con un junior
el diseñador para realizar la misma actividad podría ser considerablemente diferente, lo que afectaría
la duración y
calidad de los resultados de la actividad y, en última instancia, el costo del proyecto. En algunos
proyectos, especialmente aquellos
de menor alcance, definiendo actividades, secuenciando actividades, estimando recursos, estimando
actividad
duraciones y el desarrollo del modelo de programación están tan estrechamente vinculados que se ven
como un solo
proceso. Los recursos definitivamente pueden afectar la ruta crítica si el equipo del proyecto no lo
considera.
.5 Determinar la duración de cada actividad
La duración es una estimación de cuánto tiempo llevará realizar el trabajo involucrado en la actividad.
En muchos casos, la cantidad de recursos que se espera que estén disponibles para realizar una
actividad,
junto con la productividad de esos recursos, puede determinar la duración de la actividad. Un cambio
a
un recurso de conducción asignado a la actividad tendrá un efecto en la duración, pero esto no es
simple
Relación "en línea recta". Otros factores que influyen en la duración son el tipo o nivel de habilidad
del
recursos disponibles para realizar el trabajo, calendarios de recursos y la naturaleza intrínseca del
trabajo.
Algunas actividades (por ejemplo, una prueba de esfuerzo de 24 horas) tomarán una cantidad de
tiempo establecida para 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
recomienda definir primero la actividad, luego vincularla lógicamente a la secuencia general del
cronograma y
luego enfocándose en los recursos y la duración de la actividad. En este momento, la relación entre la
actividad.
la duración y el trabajo en el horario se entenderán más fácilmente; entonces los recursos fluyen, el
equipo de actividad
tamaños, y similares pueden comenzar a determinarse. La relación entre la duración de la actividad y
el costo.
se hará explícito en base a estimaciones o supuestos tanto para el costo como para el cronograma. Esta
el documento debe mantenerse actualizado a medida que cambian las duraciones del cronograma
durante el mantenimiento del modelo de cronograma.
Consulte la Sección 3.3 sobre Mantenimiento del modelo de programación, así como la Sección 3.4
sobre Análisis del modelo de programación
para más información.
Page 43
31
3
Es importante comprender el método utilizado por el modelo de programación para planificar el
actividades relacionadas con la estimación de la duración para cada actividad del cronograma. El
método utilizado puede implicar un
horario determinista o probabilístico. Los modelos de horarios deterministas son redes de actividades
conectado con dependencias que describen el trabajo a realizar, la duración estática y el
Fecha prevista para completar el proyecto si todo va según lo previsto. Horario probabilístico
Los modelos son redes con todos los elementos de un modelo de programación determinista, pero la
duración de la actividad
de las tareas son variables aleatorias. Para obtener más información sobre la estimación de la duración
de la actividad, por favor
consulte el Estándar de práctica para la estimación de proyectos. Para más información sobre las
mejores prácticas.
Para el análisis de riesgo del proyecto utilizando modelos de cronograma probabilístico, consulte
el Estándar de práctica para el riesgo
Administración.
.6 Analizar la salida de programación
Una vez completado, el modelo de cronograma contendrá un conjunto de actividades únicas, que
tendrán diferentes
duraciones, conectadas por relaciones lógicas definidas. Proporciona información al equipo del
proyecto.
sobre lo que debe lograrse y la secuencia requerida para lograr los entregables del proyecto.
Sin embargo, todavía no indica cuándo se deben realizar estas diversas actividades. A fin de que
adquirir esa información, la herramienta de programación se activa para calcular las fechas y otros
valores dentro de
El modelo de programación de acuerdo con el método de programación elegido. A pesar de la
velocidad de muchas computadoras
programas, la función de programación siempre requiere tres procesos distintos para el análisis de
tiempo y un
cuarto proceso, si se está utilizando la nivelación o nivelación de recursos. Los pasos discretos son:
• Se asigna una fecha de inicio al hito de inicio. Luego, moviéndose a través de la red desde
actividad a actividad (de izquierda a derecha) y en la secuencia definida por las relaciones lógicas,
las fechas de inicio y finalización se asignan a cada actividad e hito, según lo determinado por el
definido duraciones Esto se llama pase hacia adelante. Las fechas de inicio y finalización de cada
actividad se denominan
las fechas de inicio temprano y finalización temprana, y cuando el análisis llega al final de la red,
establece la fecha de finalización más temprana posible para el proyecto y la duración más corta del
proyecto
basado en la actividad, duraciones estimadas y relaciones lógicas según lo definido.
• A continuación, se asigna una fecha de finalización al hito de finalización. Esta podría ser la misma
fecha que el
uno calculado por el pase directo o una fecha diferente aplicada como restricción. El analisis
el proceso luego funciona de nuevo a través de la red de derecha a izquierda hasta que vuelve al inicio
hito, y se asigna otro conjunto de fechas de inicio y finalización a cada actividad. Se llama
el pase hacia atrás y establece las fechas de inicio y finalización tardías para cada actividad y
hito.
• Los valores flotantes se calculan comparando las fechas tempranas y tardías de la siguiente manera:
○ La flotación total se calcula restando la fecha de finalización temprana de la fecha de finalización
tardía (o la
inicio temprano desde el inicio tardío). La flotación total negativa significa que las fechas no son
factibles sin
cambiando el plan
○ La flotación libre se calcula restando la fecha de finalización temprana de la actividad desde el
inicio temprano
de los primeros de sus sucesores. La flotación libre nunca es un valor negativo.
Page 44
32
3
• Una vez que se han calculado los valores flotantes, se puede llevar a cabo la nivelación de recursos
para minimizar
recursos sobre asignaciones o reducir las fluctuaciones en la demanda de recursos. Si este proceso es
para hacerse automáticamente, el planificador necesita determinar los procesos y algoritmos para
ser usado. La mayoría de los paquetes de software de programación de proyectos tienen múltiples
opciones y configuraciones que
puede tener un impacto significativo en el cronograma resultante de nivelación de
recursos. Independientemente de lo que
configuración que tiene el software de programación, lo más probable es que haya una compensación
entre permitir
solución de nivelación para extender la duración total del proyecto y permitir el uso de más recursos
de lo permitido inicialmente. Los recursos nivelados en un área podrían asignarse en exceso en otras
áreas.
Se debe revisar una vista completa de la asignación de recursos en todas las actividades antes de
finalizar
La nivelación de recursos. Algunos pueden verse tentados a nivelar los recursos manualmente
ajustando
la lógica o agregar restricciones para retrasar el inicio de ciertas actividades; esta no es una buena
práctica
ya que interfiere con el cálculo de la programación normal.
.7 Aprobar el horario
El equipo del proyecto debe participar activamente en la revisión de los resultados de esta
programación inicial.
proceso. La revisión debe considerar la fecha de finalización del proyecto analizado, las fechas de
finalización del hito,
rutas críticas (la ruta más larga para el proyecto o como restricción), valores flotantes totales y
recursos
requisitos (en comparación con la disponibilidad de recursos) para determinar la aceptabilidad del
cronograma.
Cuando se requieren modificaciones, se realizan cambios en la lógica del cronograma, las
asignaciones de recursos y / o
duraciones, y luego se vuelve a analizar el horario. La alteración requerida más común involucra
acciones
para reducir la duración general del horario. Las técnicas clave utilizadas para comprimir el horario.
se estrellan y rastrean rápido. El bloqueo consiste esencialmente en agregar recursos a actividades
críticas
para acortar sus duraciones mientras que el seguimiento rápido consiste en cambiar la lógica al
superponer las críticas
actividades en lugar de trabajarlas estrictamente en secuencia. El bloqueo solo funciona para
actividades que son
esfuerzo impulsado donde agregar recursos reducirá la duración de la actividad ".
El bloqueo generalmente aumenta los costos del proyecto en algún factor, mientras que el seguimiento
rápido aumenta el
riesgo de retrabajo a medida que las actividades se inician antes de que se completen sus predecesores
iniciales. (ver también
Capítulo 6 del PMBOK ® Guía Cuarto Edición). Estas iteraciones continúan hasta que sea aceptable
se desarrolla un modelo de cronograma, uno que los interesados clave del proyecto pueden acordar es
alcanzable. los
el proceso formal para la aprobación del modelo de cronograma de referencia se definirá en el
cronograma
modelo de plan de manejo.
.8 Línea de base del modelo de programación
Una vez acordado, se aprobará la primera versión del cronograma que esté completa para el
desarrollo.
para capturar o copiar para referencia futura se denomina modelo de cronograma de referencia del
proyecto. Esta línea de base
se convierte en el punto de referencia contra el cual se puede medir el desempeño del proyecto. Es
generalmente
práctica aceptada de que cada proyecto tiene un modelo de cronograma de referencia establecido antes
de la ejecución
del trabajo del proyecto. Una vez que la línea base ha sido aprobada mediante procedimientos
formales, los informes son
distribuidos de acuerdo con el plan de comunicación del proyecto y los cambios en la línea base son
monitoreado y controlado a través del proceso integrado de control de cambios.
Página 45
33
3
3.3 Programa de mantenimiento del modelo
Casi todos los proyectos experimentarán inevitablemente cambios. Para garantizar la ejecución exitosa
del proyecto, un cambio efectivo
son necesarios procedimientos de control y mantenimiento disciplinado. La clave es determinar cómo
funcionará el proyecto
aprobar y realizar un seguimiento de los cambios a medida que ocurren durante el ciclo de vida del
proyecto. El cambio puede ocurrir simplemente por trabajo
progresar más rápido o más lento de lo planeado, así como cuando ocurren cambios en otros
elementos del proyecto
(por ejemplo, cambios en el alcance) y / o si el equipo del proyecto decide modificar su enfoque para
el trabajo del proyecto.
El progreso del seguimiento comienza después de que el modelo del proyecto se base, el trabajo
comience y el monitoreo y
Se implementan procesos de control. Estos procesos son importantes para ayudar a identificar
problemas tan pronto como sea posible.
posible, minimizando su impacto en la finalización exitosa del proyecto. Los principales pasos para el
seguimiento
el progreso es el siguiente:
• Guardar un modelo de cronograma de referencia, que contiene las fechas contra las cuales se
compara el progreso.
El modelo de cronograma actual puede copiarse y aprobarse como línea de base o un cronograma más
adecuado
El modelo puede ser aprobado como referencia.
• El progreso del cronograma se informa a partir de una fecha de datos específica, también conocida
como fecha de estado, fecha de actualización,
fecha actual, hora actual o fecha de finalización. Este progreso, como mínimo, debe incluir el inicio
real
y fechas de finalización reales, duraciones restantes y porcentaje completado.
• Asignar la nueva fecha de datos y volver a calcular todas las fechas de actividad son los últimos
pasos para avanzar
El modelo de horario.
El proceso de estado / actualización ocurre de manera regular determinada durante el proceso de
planificación del proyecto.
Los pasos necesarios para mantener el cronograma en cada estado / actualización se describen en 3.3.1
a 3.3.7.
3.3.1 Recopilar datos reales y trabajo restante
Recopile el estado real del trabajo a intervalos de tiempo predeterminados para el proyecto. La
información
recopilado incluye las fechas de inicio reales para todas las actividades que han comenzado y las
fechas de finalización reales para todos
actividades que se han completado a la fecha de los datos. Cuando una actividad está en progreso, la
cantidad de trabajo
logrado y se determina el tiempo necesario para completar el trabajo restante. Colección de estado
también
incluye cambios en la duración de actividades futuras. Otra información recopilada en este momento
puede incluir datos sobre
utilización de recursos y costos incurridos. Los datos se recopilan a partir de una fecha de datos
nominada (fecha / hora). Esta información
la fecha es análoga al "tiempo ahora" en la gestión del rendimiento del valor ganado (EVPM).
3.3.2 Actualizar y progresar el modelo de programación de acuerdo con los
datos reales
Ingrese la información de estado en el modelo de programación y vuelva a analizar el trabajo restante
para determinar el proyecto
estado. Todo el trabajo incompleto se reprogramará a una fecha / hora igual o posterior a la fecha de
datos. El cuidado debe
se debe tomar, ya que muchas herramientas de software permiten que las fechas reales se apliquen a
trabajos futuros. Prácticas de control de calidad
debe estar en su lugar para identificar la entrada de fechas reales más allá de la fecha de datos y los
valores de porcentaje completado
informó que no son válidos en relación con las fechas.
Página 46
34
3
3.3.3 Comparar y resolver cualquier desviación
Compare los resultados del modelo de cronograma recientemente actualizado con la línea base
almacenada y administre los costos y el cronograma
variaciones. Los umbrales de variación definidos en el plan de gestión del modelo de programación
pueden usarse para determinar qué
Las actividades y condiciones requieren informes y acciones adicionales. Una variación de fecha
comúnmente utilizada es la variación de acabado
entre el final temprano y el final de la línea de base, que generalmente se expresa en unidades tales
como días hábiles. Comparando el
el estado de una actividad contra más de un objetivo puede ser útil; por ejemplo, horario actual vs .:
• El plan original, la línea de base, para ver el deslizamiento en comparación con el plan original.
• El último período de actualización para ver los cambios desde la última actualización.
3.3.4 Actualizar el modelo de programación con cambios aprobados
Actualice el modelo de programación con cualquier cambio aprobado que resulte del proceso general
de control de cambios a
asegúrese de que el modelo de cronograma represente el 100% del alcance de trabajo actual del
proyecto. La actualización y el ajuste.
Los procesos pueden necesitar varias iteraciones para mantener un modelo de programación que siga
siendo realista y alcanzable.
3.3.5 Actualizar el modelo de programación de referencia
Actualice, según el proceso formal de control de cambios, el modelo de cronograma de línea base si
cambia el alcance autorizado
se han incorporado al modelo de programación actualizado, o si se han incorporado otros cambios que
cambiar significativamente la naturaleza de la ejecución del proyecto. Solo las actividades que son
nuevas o aprobadas para el cambio,
y aquellas actividades que estén directa o indirectamente vinculadas a ellas, deben volverse a
clasificar.
3.3.6 Comunicar
Distribuya informes (programe presentaciones de modelos, consulte las Figuras 21 y 27) de acuerdo
con el programa
modelo de plan de gestión y el plan de gestión de comunicaciones del proyecto una vez que se
actualice el cronograma actual
El ciclo ha sido completado.
3.3.7 Mantener los registros
La gestión adecuada de registros es parte del control de configuración. Registros mantenidos
adecuadamente que detallen la inicial
La lógica y los principales puntos de decisión del proyecto y el proceso de pensamiento que se utilizó
para crear el programa de referencia
la lógica de flujo ayuda a defender las acciones tomadas y las lecciones aprendidas. Mantener
registros que expliquen todos los cambios en la actividad.
duraciones o lógica, ya que las modificaciones se realizan en el modelo de programación. Las notas
del registro de actividad a menudo se usan para esto
propósito. Estos registros proporcionarán datos valiosos si es necesario reconstruir lo que sucedió y
por qué.
Muchas de las buenas prácticas y elementos descritos anteriormente también se incluyen en los
detalles de cada
componente contenido en la lista de componentes del modelo de programación tal como se presenta
en el Capítulo 4. Una completa
Es necesario comprender los distintos componentes para maximizar el potencial de su correcto
funcionamiento.
aplicación y el desarrollo de un programa de sonido.
Page 47
35
3
3.4 Análisis del modelo de programación
El análisis de horarios utiliza herramientas y técnicas comunes a lo largo del ciclo de vida del proyecto
para identificar
desviación del modelo de cronograma de referencia. El análisis del cronograma es responsabilidad del
equipo del proyecto y del
El objetivo principal del análisis es la identificación temprana de amenazas y oportunidades para los
Existen varias herramientas y técnicas disponibles para realizar análisis de modelo de
cronograma. Los procedimientos específicos
y las políticas que se utilizarán para un proyecto se describen en el plan de gestión del cronograma del
proyecto. Lo mas
Los elementos comunes revisados durante el análisis del cronograma se describen en 3.4.1 a 3.4.11.
3.4.1 Ruta crítica y actividades críticas
.1 Ruta crítica
La ruta crítica es típicamente, pero no siempre, la secuencia de las actividades del cronograma que
predice
o define la duración más larga del proyecto. En general, es el camino más largo a través del proyecto y
por lo tanto determina la duración del proyecto. Sin embargo, una ruta crítica puede terminar, por
ejemplo, en
un hito del cronograma que está en el medio del modelo de cronograma y que tiene un final no más
tarde que
restricción de fecha. (Recuerde que las restricciones deben usarse selectivamente en los modelos de
programación). Pero los riesgos
y las restricciones pueden alterar la ruta crítica, elevando la importancia de actividades aparentemente
menores y
causando cambios inesperados en la duración y el costo del proyecto. Un proyecto puede tener
múltiples rutas críticas.
Un proyecto con múltiples rutas críticas tiene un mayor nivel de riesgo desde el incumplimiento de
cualquiera de estos
podría resultar en la imposibilidad de completar todos los hitos del proyecto.
.2 Actividades críticas
Es importante distinguir entre las actividades de ruta crítica y las actividades críticas. Camino critico
Las actividades son aquellas actividades contenidas en las rutas críticas. Las actividades críticas son
aquellas actividades vitales para
El éxito del proyecto, incluso si no están en la ruta crítica o cadena crítica prevista por CPM. Crítico
Las actividades son normalmente de alto riesgo en términos de alcance, cronograma y costo y pueden
causar no solo un retraso
en la fecha de finalización del proyecto, pero una mayor probabilidad de fracaso del proyecto. Todas
las actividades en la ruta crítica.
También se consideran actividades críticas. Los cálculos de ruta crítica consideran actividades y
restricciones para
determinar el camino más largo del proyecto. Las actividades críticas pueden estar fuera del camino
crítico.
3.4.2 Flotación total y flotación libre
La flotación libre representa la cantidad de tiempo que una fecha de finalización temprana de CPM de
actividad puede retrasarse sin afectar
la fecha de inicio temprano de cualquier actividad sucesora. La flotación total representa la cantidad
de tiempo que una actividad CPM anticipa
la fecha de inicio o la fecha de finalización temprana de CPM pueden retrasarse sin afectar la fecha de
finalización tardía de CPM de todo el proyecto
o violar una fecha de restricción del modelo de programación. Revise cada actividad de flotación total
y flotación libre para determinar si
han cambiado desde la actualización anterior. Los cambios en la flotación total indican una amenaza
de lograr la finalización del proyecto.
o hitos específicos; La flotación libre indica cómo la falta de progreso afecta a los sucesores
inmediatos. Flotador total y
el flotador libre puede verse reducido por dependencias externas y otras fechas de restricción estrictas
enumeradas en el programa
modelo. Estas dependencias externas deben explicarse en nodos de actividad o vincularse a hitos
externos.
48
36
3
Monitorear y administrar estos dos componentes vitales son críticos para completar el proyecto a
tiempo y
cumpliendo hitos según lo planeado Las disminuciones en la flotación total y la flotación libre indican
dónde deben planificarse los planes de recuperación
ser desarrollado.
3.4.3 Nivel de actividades de esfuerzo (LOE)
Las actividades de nivel de esfuerzo (LOE) son para apoyar otras actividades de trabajo o todo el
esfuerzo del proyecto. Ejemplos
de dicha actividad puede ser la gestión del proyecto, la contabilidad del presupuesto del proyecto, el
enlace con el cliente o la rotación
maquinaria durante el almacenamiento (mantenimiento preventivo), etc.
Dado que una actividad LOE no es en sí misma un elemento de trabajo directamente asociado con la
realización del proyecto final
producto, servicio o resultado, pero más bien uno que respalde dicho trabajo, su duración se basa en la
duración de
Las actividades de trabajo discretas que está apoyando. Por ejemplo, cuando se proporcionan fuerzas
de seguridad para el personal del
entrada al sitio de trabajo, comenzarán cuando comiencen las obras y terminarán cuando finalice el
proyecto. Como un
Como resultado, una actividad LOE nunca debe estar en la ruta crítica del modelo de programación,
ya que nunca agrega tiempo al
proyecto. Por el contrario, la instalación de maquinaria estaría en la ruta crítica y la actividad de
mantenimiento preventivo
se acortaría o alargaría solo si el tiempo de almacenamiento de la maquinaria lo hace. Al insertar
actividades LOE en un
Programa de método de ruta crítica, el LOE generalmente se programa como inicio a inicio (SS) y
final a final
(FF) sucesor de las actividades de conducción. En un diagrama de lógica de red, estas dos relaciones
lo hacen aparecer como
aunque el LOE se cuelga desde el inicio y el final de la actividad discreta. Como resultado, un LOE
diagramado en
esta manera a veces se denomina actividad de hamaca. Una actividad de hamaca es una actividad de
puente, utilizando
Relaciones de SS y FF con actividades de apoyo, o en el caso de LOE, actividades que
apoya. Actividad LOE,
a diferencia de las actividades de hamacas, pueden tener cualquier tipo de relación, como las hamacas,
no se limitan a SS y
Relaciones FF. Pueden tener muchos tipos de relaciones asociadas con ellos. La nivelación de
recursos puede no
se realiza y las restricciones no se pueden aplicar a las LOE; usan sus calendarios asignados para
resumir
sus fechas
3.4.4 Distribución probabilística de la duración de la actividad
Si la duración de la actividad implica una gran incertidumbre, una técnica de estimación comúnmente
utilizada es la
Estimación de tres puntos. Estos tres puntos corresponden a la duración de la actividad definida como
optimista, muy probablemente y
duraciones pesimistas. Además, el registro de riesgos también se puede utilizar para respaldar la
estimación de la incertidumbre en
duraciones de actividad. Con el fin de cuantificar la incertidumbre sobre la duración total del proyecto,
a partir de los tres
estimación puntual de cada actividad, PERT (que utiliza una aproximación de la distribución beta y la
ecuación en
Sección 2.2.3) puede ser utilizada. La duración optimista de la actividad y la duración pesimista de la
actividad representan el
duraciones probables, pero no todo el dominio de valores. Las estimaciones de duración de tres puntos
deben hacerse
por quienes realizan las actividades o por alguien con experiencia que realiza actividades similares. Lo
mas
El enfoque común para crear la distribución probabilística es estimar el valor más probable con la
mayor precisión
como sea posible y luego sesgar la distribución hacia valores máximos o mínimos. El grado en que el
la distribución está sesgada, se sugiere por la forma de una curva que se ajusta a 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 ser
seleccionado para ajustarse mejor a los datos de apoyo para actividades similares.
Página 49
37
3
3.4.5 Riesgo de cronograma
El análisis de riesgos del cronograma se utiliza para establecer y validar contingencias del
cronograma, identificar riesgos prioritarios
y eventos impulsados por 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 conocidos como "sesgo de fusión" o "ruta
convergencia ”. Es demasiado complejo realizar un análisis profundo de este sesgo sin hacer una
simulación como
Simulación de Monte Carlo que determinará la magnitud del sesgo. Cuanto más grande y complejo es
un proyecto, el
mayor impacto acumulativo de riesgo en el proyecto. Las circunstancias que dictan la frecuencia, el
rigor y el uso.
de análisis de riesgos programados están documentados en el plan de gestión del proyecto u otros
documentos contractuales. por
Para obtener más información sobre los conceptos de riesgo, consulte el Estándar de práctica para la
gestión de riesgos del proyecto .
3.4.6 Restricciones de fecha
Las restricciones de fecha restringen el flujo natural de un proyecto, ignoran los efectos del riesgo y
limitan la utilidad de
análisis de riesgos del horario. Las restricciones de fecha deben evitarse siempre que sea posible y
usarse solo cuando sean compatibles
con el curso de desarrollo esperado de un proyecto. Por ejemplo, un uso de una restricción de fecha
podría ser
establecer una fecha no anterior o posterior a las actividades para las cuales no existe un predecesor o
sucesor en el horario. Un ejemplo ilustrativo puede ser la entrega de una pieza de equipo por un
proveedor donde
No es práctico ni deseable incluir las actividades del proveedor en el modelo de programación. Incluso
en este ejemplo,
Se debe tener cuidado para no inyectar una ruptura en la ruta crítica. Las restricciones pueden ser
flexibles (p. Ej., Tan pronto
como sea posible), moderadamente flexible (por ejemplo, terminar no antes de) o inflexible (por
ejemplo, debe comenzar en). Moderadamente
las restricciones flexibles a veces se llaman restricciones suaves y las restricciones inflexibles a veces
se llaman duras
restricciones Dado que las restricciones limitan la flexibilidad de la programación, deben usarse solo
cuando la lógica de la programación no puede
abordar correctamente la situación. Cuando se hace necesaria una restricción de fecha, se prefieren
restricciones flexibles
sobre restricciones inflexibles.
3.4.7 Actividades abiertas
Una actividad abierta es una actividad que carece de un predecesor o un sucesor o ambos. Abierto
las actividades pueden oscurecer las relaciones lógicas entre las actividades del proyecto, crear una
apariencia falsa de flotación en
un proyecto, y reducir el impacto aparente del riesgo durante un análisis de programación. Las únicas
actividades abiertas
en un proyecto deben ser los hitos de inicio y fin al principio y al final del proyecto. A menos que esté
vinculado a
otros proyectos, los hitos de inicio y finalización de un proyecto siempre contendrán extremos
abiertos.
3.4.8 Lógica fuera de secuencia (OOS)
La lógica OOS surge cuando un proyecto ya está en progreso. Una actividad puede ser reportada como
iniciada antes de su
el predecesor se informa como terminado, lo que provoca la lógica OOS. Por ejemplo, si la Actividad
A tiene un fin al inicio (FS)
relación con la Actividad B, pero la Actividad B se actualizó con una fecha de inicio real antes de que
la Actividad A
actualizado con una fecha de finalización real, el resultado es la lógica OOS. La lógica OOS debe
corregirse (p. Ej.
descomposición de la Actividad A) o eliminada para preservar la integridad del análisis de
riesgos. Análisis de horarios
Página 50
38
3
identificará adecuadamente cómo resolver mejor los problemas de lógica OOS; sin embargo, no
confíe ú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, se
puede ser que la relación definida creada durante la etapa de planificación no sea correcta y deba
corregirse
para este proyecto y para referencia futura.
3.4.9 Plomos y retrasos
El riesgo puede consumir o extender retrasos fijos con consecuencias imprevistas para la duración
general del proyecto. Lleva
y los retrasos pueden introducir riesgos en el cronograma y deben modelarse como actividades
discretas con su propia duración
incertidumbre siempre que sea posible. Los clientes potenciales también pueden introducir riesgos de
costos, especialmente en el inventario JIT (justo a tiempo)
administración; Esto, a su vez, puede tener un efecto en cascada en el modelo de programación si el
proyecto se está gestionando
Con un espacio de inventario limitado. Se requiere expresar leads / retrasos como actividades discretas
si la simulación de Monte Carlo
el software no permite la asignación de incertidumbre de duración a un adelanto / retraso. Además,
promoviendo un adelanto / retraso para
una actividad completa le permite asignar atributos adicionales, como un nombre, la 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 del cronograma.
Existe un riesgo específico asociado con cualquier adelanto y retraso aplicado a actividades donde
diferentes calendarios (actividad
o recurso) están en uso. Por lo tanto, es importante tener una comprensión clara de las consecuencias
que conlleva
y los retrasos pueden tener en un modelo de programación. Muchas herramientas de software pueden
permitir definir leads y rezagos como
duración fija o como porcentaje de la duración de la actividad; se necesita juicio para usar el método
correcto mejor
representando la naturaleza de la actividad y el adelanto o retraso.
3.4.10 Relación de principio a fin
Las relaciones de principio a fin (SF) rara vez se usan deliberadamente en la planificación
determinista porque
implican la circunstancia inusual de que una tarea sucesora ocurra antes que su predecesora
lógica. Revisar cualquier SF
relación para garantizar que no sea el resultado de errores de programación y modificarlos si es
necesario. El seguimiento
El ejemplo ilustrativo de una relación SF proporciona una mejor comprensión de esta relación rara:
Ejemplo : suponga que el proyecto requiere la entrega de un equipo para
Apoyar las actividades de construcción. Puede no ser práctico proporcionar lógica para el equipo
actividades de fabricación y entrega, pero el equipo quiere que las actividades de construcción
conduzcan
Las fechas de la entrega. Como el predecesor siempre conduce al sucesor, el SF
La relación proporciona la solución. Entonces la fabricación del equipo puede concluir
El inicio de la actividad que requiere la instalación del equipo.
3.4.11 Enlaces a / desde actividades resumidas
Por lo general, no se recomienda usar enlaces en actividades de resumen porque la lógica puede ser
difícil de
siga y la práctica puede no ser compatible con todas las herramientas de programación. El uso de
enlaces en actividades resumidas puede
producir errores lógicos y crear lógica circular dentro del modelo de programación.
51
39
3
3.5 Comunicación e informes
Las comunicaciones claras crean credibilidad con las partes interesadas. El gerente del proyecto junto
con el proyecto.
el equipo debe crear un plan de gestión de la comunicación (consulte la Guía de PMBOK ® — Cuarta
edición) al principio del
ciclo de vida del proyecto para cumplir con las expectativas identificadas de las partes interesadas
clave.
El modelo de cronograma es un elemento estratégico e importante en el conjunto de herramientas de
un gerente de proyecto para guiar un proyecto
con éxito a su fecha de finalización objetivo. Un modelo de cronograma es una línea de tiempo o
calendario que enumera actividades
con las fechas de inicio y finalización previstas. Un modelo de programación también se puede
superponer con diferentes detalles para permitir
gerentes de proyecto para dirigir y administrar los recursos de manera más fluida, controlar las
evoluciones diarias del proyecto,
comunicarse con mayor frecuencia y eficacia con las partes interesadas, e identificar y monitorear
dependencias y
restricciones entre tareas para minimizar el impacto en el proyecto por retrasos evitables.
La instancia del modelo de programación puede producir múltiples formatos de informes dependiendo
del propósito de
modelo de programación, la etapa del desarrollo del proyecto y el usuario principal del modelo de
programación.
Los clientes pueden requerir varios niveles de presentaciones de instancias de modelo de
programación. Para más información ver el
componente "nivel de modelo de programación" en el Capítulo 4.
Tabla 31. Niveles de presentaciones de instancias de modelo de programa
Page 52
Page 53
41
4 4
CAPÍTULO 4
PROGRAMACIÓN DE COMPONENTES
La siguiente sección proporciona una catalogación detallada de los componentes potenciales de una
herramienta de programación.
Cada entrada incluye ocho tipos posibles de información relacionada con cada componente e indica si
el
Este estándar de práctica considera que el componente es obligatorio, condicional u
opcional. Componentes necesarios
se dividen en cuatro grupos: componentes básicos necesarios (CRC, que se muestra como "R" en las
tablas), recursos necesarios
Componentes (RRC), Componentes requeridos de EVM (ERC) y Componentes requeridos de riesgo
(KRC). Los requisitos
del proyecto determinar qué componentes requeridos deben estar presentes en un modelo de
programación antes de la madurez
Se puede realizar una evaluación. La evaluación de madurez y el índice de conformidad se explican en
detalle en
Capítulo 5. Este capítulo está dividido en las siguientes secciones:
4.1 Cómo usar la lista de componentes. Esta sección 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
El componente se identifica como obligatorio, condicional u opcional.
4.3 Lista detallada de componentes. Esta sección enumera cada componente de programación y sus
tipos asociados.
de información en orden alfabético.
4.1 Cómo usar la lista de componentes
El diseño para una entrada de componente típica se muestra a continuación. Las subsecciones de 4.1
definen el contenido para 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:
Page 54
42
CAPÍTULO 4 PROGRAMACIÓN DE COMPONENTES
4 4
4.1.1 Nombre del componente
Este elemento de datos contiene el nombre del componente dentro de una herramienta de
programación, que puede diferir dentro de
una herramienta seleccionada Los otros atributos deben ser los mismos para que la familiaridad con el
estándar permita
uso adecuado
4.1.2 Uso requerido, condicional u opcional
Este elemento de datos indica si el uso de un componente es: requerido, para cualquier modelo de
programación;
requerido condicionalmente, basado en el estado o acción de otro componente o proceso; u opcional
4.1.3 Manual o calculado
Este elemento de datos indica si los datos dentro del componente son ingresados manualmente o
calculados por
La herramienta de programación. La configuración del atributo manual / calculado depende de la
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. los
El formato de 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
permite la reacción dentro de
La herramienta de programación. Es importante tener en cuenta que todas las descripciones de
comportamiento comienzan con un verbo que indica
acción. El comportamiento real de un componente puede variar entre herramientas de programación o
configuraciones dentro de la misma herramienta.
Página 55
43
4 4
4.1.6 Buenas prácticas
En esta lista, "buenas prácticas" significa que existe un acuerdo general de que la correcta aplicación
de habilidades,
Las herramientas y técnicas, cuando se aplican junto con el componente nombrado, pueden aumentar
las posibilidades de
éxito en una amplia gama de proyectos diferentes. Las buenas prácticas no significan que el
conocimiento descrito
siempre debe aplicarse 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 la acción de este componente depende del estado o acción de otro
componente.
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. los
La definición proporcionada es la misma que se proporciona en el Glosario, cuando corresponda.
4.2 Lista de componentes por categoría
Esta sección contiene una lista de los componentes organizados por categorías. La columna Usar
identifica si un
componente es un componente requerido central (R), componente requerido de recursos (RRC),
Gestión del Valor Ganado
componente requerido (ERC), componente requerido de riesgo (KRC), opcional (O) o no calificado
(NS). Todo lo requerido
los componentes deben estar presentes para lograr una puntuación en el proceso de evaluación de
madurez descrito con mayor detalle
en el capítulo 5.
Page 56
44
4 4
Tabla 41. Lista de componentes por categoría
57
45
4 4
4.3 Lista detallada de componentes
Esta sección identifica componentes individuales y los ocho tipos de información definidos para cada
componente.
Está organizado alfabéticamente.
Costo real de la actividad (AC)
Requerido (ERC)
Calculado
Formato de datos:
Número
Comportamiento: medición del costo
Buenas prácticas: incluya el costo real cuando utilice la metodología del valor ganado en el
cronograma.
Nota condicional / componente asociado: consulte el Estándar de práctica para la gestión del valor
ganado .
Este término también se conoce como costo real del trabajo realizado (ACWP). Este estándar
reconoce que AC solo puede ser
disponible en niveles resumidos de actividades y no para cada actividad discreta en el modelo de
programación.
Definición: El costo total del trabajo completado durante un período de tiempo determinado. Este
valor puede ser calculado
en cualquier nivel de esquema del modelo de programación y entre varias fechas de datos. Si el
cálculo se realiza usando
la fecha de inicio del proyecto y la fecha de datos más actual, los valores se denominan
"acumulativos".
Duración real de la actividad
Necesario
Calculado / Manual
Formato de datos:
Numérico
Comportamiento: define el tiempo transcurrido desde que comenzó la actividad. La unidad de
medida puede
ser tiempo transcurrido o 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 de
la actividad de programación y la fecha de datos del modelo de programación, si la actividad de
programación está en progreso,
o la fecha de finalización real de la actividad, si la actividad del cronograma está completa.
Fecha de finalización real de la actividad
Necesario
Manual
Formato de datos:
Fecha
Comportamiento: define la fecha en que se completó la actividad.
Buenas prácticas: todas las actividades con acabados anteriores a la fecha de los datos deben tener
asignadas fechas de finalización reales.
Las fechas reales reemplazan las fechas de CPM temprana y tardía. Especifica que la actividad está
100% completa.
Nota condicional / componente asociado: porcentaje completado
Definición: El momento en el que se completa una actividad programada.
Fecha de inicio real de la actividad
Necesario
Manual
Formato de datos:
Fecha
Comportamiento: define el progreso iniciado en una actividad.
Buenas prácticas: las fechas reales deben asignarse a todos los inicios reales anteriores a la fecha de
datos. Fechas reales
reemplazar CPM fechas tempranas y tardías.
Nota condicional / componente asociado: el progreso debe haberse iniciado antes del actual
fecha de Datos.
Definición: El momento en el que comenzó una actividad de programación.
58
46
4 4
Calendario de actividades
Opcional
Manual
Formato de datos:
Fecha y hora
Comportamiento: define los períodos de trabajo para la actividad. El calendario de actividades anula
el calendario del proyecto.
para aquellas actividades a las que se aplica.
Buenas practicas:
Definición: Un calendario de períodos laborales y no laborales asignados a la actividad del
cronograma que
define los períodos de trabajo y los períodos no laborales en formato de calendario. El calendario de
actividades, en el horario.
Las actividades a las que está asignado, se utilizan para reemplazar el calendario del proyecto para los
cálculos durante el cronograma.
cálculos Vea también el calendario del proyecto y el calendario de recursos .
Código de actividad
Opcional
Manual
Formato de datos:
Alfanumérico
Comportamiento: indica la clasificación de la tarea / actividad
Buenas prácticas: los códigos de actividad deben usarse para facilitar la clasificación, organización,
resumen y agrupación.
Definición: uno o más valores numéricos o de texto que identifican las características del trabajo o de
alguna manera
categorizar la actividad del cronograma que permite filtrar y ordenar actividades dentro de los
informes.
Categoría de costo de actividad
Opcional
Manual
Formato de datos:
Alfanumérico.
Comportamiento: proporciona desgloses adicionales que se pueden asignar para una cuenta de costo
específica dentro del proyecto.
Buenas prácticas: a efectos contables, los costos deben desglosarse en categorías, como directa,
indirecto, laboral, material, equipamiento, etc.
Definición: un desglose del costo, como el costo laboral, el costo del equipo y el costo del material.
Estimación de costo de actividad
Opcional
Manual
Formato de datos:
Numérico
Comportamiento: Derivado al agregar todas las categorías de costo de actividad individual. Puede
incluir costos adicionales a los
incluido en el valor planificado (PV).
Buenas prácticas: los costos de actividad deben calcularse agregando las categorías de costos de
actividad individuales
que han sido asignados 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 requeridos
para realizar y completar la actividad, incluidos todos los tipos de costos y categorías de costos.
Page 59
47
4 4
Actividad Probabilidad acumulativa Distribución de riesgos
Requerido (KRC)
Manual
Formato de datos:
Tabla de fechas, numéricas (fraccionarias)
Comportamiento: almacena los resultados del método utilizado para cuantificar la incertidumbre en
función de la probabilidad elegida
función de distribución que representa el riesgo de duración de la actividad.
Buenas prácticas: el proceso de análisis de riesgos debe utilizarse para proyectos en los que las
variaciones del cronograma podrían
tener un impacto significativo en los objetivos del proyecto.
Definición: Una tabla de fechas y sus probabilidades acumuladas asociadas de ocurrencia para la
actividad del cronograma.
terminación. 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 a la distribución de riesgo de
probabilidad acumulativa del proyecto.
Requerido (ver Actividad
Actividad Duración Porcentaje completado
Porcentaje físico completo)
Calculado / Manual
Formato de datos:
Numérico (fraccional)
Comportamiento: representa la proporción de la duración real como un porcentaje de la duración
total de la actividad esperada
completado en un punto dado en el tiempo.
Buenas prácticas: en ausencia de una gestión del valor ganado, el porcentaje de duración completa
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
de verdadero progreso, y su uso en lugar de EVM se desaconseja. 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: utilizará el porcentaje de duración de la actividad
completa o la actividad
porcentaje físico completo
Definición: El porcentaje calculado de que la duración real de la actividad es la duración total de la
actividad para
una actividad programada que tiene trabajo en progreso.
Actividad Fecha de finalización temprana
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: identifica la fecha de finalización temprana de la actividad, en función del pase de
avance de CPM.
Buenas prácticas: la fecha se derivará de los cálculos de CPM.
Nota condicional / componente asociado: inicio temprano, duración
Definición: El punto de tiempo más temprano posible cuando la parte incompleta de la actividad del
cronograma puede
ser completado dados los recursos asignados.
Fecha de inicio temprano de la actividad
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: define el inicio temprano de la actividad, en función del pase de avance de CPM.
Buenas prácticas: derivadas de los cálculos de análisis de red programados.
Definición: El punto de tiempo más temprano posible cuando la actividad del cronograma puede
comenzar según el CPM
Pasar adelante de la lógica del modelo de programación.
60
48
4 4
Esfuerzo de actividad / trabajo
Opcional
Manual
Formato de datos:
Numérico
Comportamiento: cuantifica las unidades de trabajo requeridas para una actividad.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se identifica un recurso
laboral, el esfuerzo es
asignado
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 de trabajo requeridas para completar una actividad programada o
un desglose del trabajo.
componente de estructura. El esfuerzo de la actividad generalmente se expresa como horas de
personal, días de personal o semanas de personal. No la
igual que la duración
ID de actividad
Necesario
Calculado
Formato de datos:
Alfanumérico
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 proyectos asignan una estructura razonada o "codificación" a la
ID de la actividad.
Definición: una identificación numérica o de texto única y breve asignada a cada actividad del
cronograma para diferenciar
esa actividad del proyecto de otras actividades. El ID de actividad suele ser único dentro de cualquier
diagrama de Red.
Etiqueta de actividad
Necesario
Manual
Formato de datos:
Alfanumérico
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 de programación utilizada junto con un
identificador de actividad
para diferenciar esa actividad del modelo de programación de otras actividades de programación. La
descripción de la actividad normalmente
describe el alcance del trabajo de la actividad del cronograma. También conocido como nombre de
actividad, nombre de tarea.
Actividad Fecha de finalización tardía
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: identifica el final tardío de la actividad en función del pase hacia atrás de CPM.
Buenas prácticas: derivadas de los cálculos de CPM.
Definición: El último punto posible en el tiempo en que la actividad del cronograma se puede
completar sin violar
una restricción de programación o retrasar la fecha de finalización del proyecto.
Página 61
49
4 4
Actividad Fecha de inicio tardío
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: define el inicio tardío de la actividad, en función del pase hacia atrás.
Definición: El último punto posible en el tiempo en que la actividad del cronograma puede comenzar
sin violar un
restringir el horario o retrasar la fecha de finalización del proyecto.
Actividad Duración más probable
Requerido (KRC)
Manual
Formato de datos:
Numérico
Comportamiento: identifica el tiempo asignado para completar la actividad del cronograma
asumiendo que es normal
condiciones Los riesgos solo se calculan sobre las duraciones restantes.
Buenas prácticas: las duraciones más probables se deben utilizar para los cálculos de riesgo
programados.
Definición: El número total de períodos de trabajo en unidades de calendario asignadas para realizar
la actividad del cronograma,
considerando todas las variables que podrían afectar el rendimiento; se determina que es el más
probable
duración de la actividad.
Duración optimista de la actividad
Requerido (KRC)
Manual
Formato de datos:
Numérico
Comportamiento: identifica el período de tiempo asignado para completar la actividad del
cronograma asumiendo que es el mejor
posibles condiciones. Los riesgos solo se calculan sobre las duraciones restantes.
Buenas prácticas: se deben usar duraciones optimistas para los cálculos de riesgo del cronograma.
considerando todas las variables que podrían afectar el rendimiento; se determina que es lo más corto
posible
Actividad Duración original
Necesario
Manual
Formato de datos:
Numérico
Comportamiento: define el tiempo asignado para completar la actividad del cronograma antes de
informar cualquier
progreso en la actividad. La implementación de la duración original de la actividad depende de la
Buenas prácticas: se debe mantener un registro de cómo se determinó la duración para referencia
futura
y revisiones. En general, las duraciones no deben exceder dos o tres ciclos de informes.
Definición: La duración de la actividad originalmente asignada a una actividad de programación; esta
duración generalmente no es
actualizado a medida que se informa el progreso de la actividad. Se utiliza para comparar con la
duración real de la actividad y
duración restante de la actividad al informar el progreso del cronograma, la duración original de la
actividad es normalmente
desarrollado con una dependencia de datos históricos, especialistas, disponibilidad de recursos,
consideraciones financieras y
volumen de trabajo a realizar.
Page 62
50
4 4
Duración pesimista de la actividad
Requerido (KRC)
Manual
Formato de datos:
Numérico
Comportamiento: identifica el tiempo asignado para completar la actividad del cronograma
asumiendo lo peor
posibles condiciones. Los riesgos solo se calculan sobre las duraciones restantes.
Buenas prácticas: las duraciones más probables se deben utilizar para los cálculos de riesgo
programados.
Nota condicional / Componente asociado: Las asignaciones de recursos pueden afectar la duración
restante de la actividad.
considerando todas las variables que podrían afectar el rendimiento; se determina que es el más largo
posible
Requerido (ver Actividad
Actividad Porcentaje físico completo
Duración Porcentaje completo)
Manual
Formato de datos:
Comportamiento: representa la proporción del trabajo físico real como un porcentaje del total físico
esperado
trabajo completado en un punto dado en el tiempo.
Buenas prácticas: para cualquier actividad iniciada, el porcentaje físico completado debe
actualizarse. El proyecto
el planificador debe tomar una decisión al comienzo del proyecto sobre qué método se utilizará para
La duración del proyecto. Puede haber diferentes métodos para medir la integridad. Estos incluyen el
reglas de ganancias basadas en el valor ganado (consulte el Estándar de práctica para EVM), como la
regla 50/50, cantidades reales,
porcentaje completo, no lineal por hito, etc., así como estimaciones de las personas que trabajan en la
actividad. De
En estos métodos, la evaluación porcentual basada en EV se considera la mejor, ya que tiende a ser
mucho menor.
subjetivo.
Nota condicional / componente asociado: utilizará el porcentaje de duración de la actividad
completa o la actividad
porcentaje físico completo Requiere el uso de la técnica del valor ganado.
Definición: una estimación, expresada como un porcentaje, de la cantidad de trabajo que se ha
completado en un
actividad del cronograma, medida en términos de progreso del trabajo físico o mediante las reglas de
ganancia de ganado
gestión de valor.
Duración restante de la actividad
Necesario
Calculado / Manual
Formato de datos:
Numérico
Comportamiento: define el tiempo necesario para completar la actividad a partir de la fecha de datos.
Buenas prácticas: una vez que una actividad comienza pero no se completa durante un ciclo de
informe, una determinación
debe hacerse en cuanto a la duración que queda para completar el trabajo.
Nota condicional / Componente asociado: Las asignaciones de recursos pueden afectar la duración
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
actividad que no ha comenzado o entre la fecha de datos del cronograma del proyecto y la fecha de
finalización temprana de CPM
de una actividad programada que tiene una fecha de inicio real de actividad. Esto representa el tiempo
necesario para completar
una actividad programada donde el trabajo está en progreso. Nota: Antes del inicio real, Actividad
Duración Actividad
Duración restante
Page 63
51
4 4
Actividad Recurso Cantidad real
Requerido (RRC)
Manual / Calculado
Formato de datos:
Numérico
Comportamiento: Medida de utilización de un recurso a nivel de actividad.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos, "actividad
real
cantidad de recursos "necesita ser utilizado.
Definición: La unidad para expresar la cantidad de un recurso utilizado para una actividad desde la
actividad real
fecha de inicio.
Fecha de finalización del nivel de recursos de la actividad
Opcional
Calculado
Formato de datos:
Fecha
Comportamiento: identifica el final más temprano de una actividad en función de las limitaciones de
recursos.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos y recursos
existe una asignación excesiva, se necesita utilizar la nivelación de recursos.
Definición: El punto en el tiempo asociado con la fecha de finalización programada de la actividad de
un recurso limitado
programar la actividad en un horario limitado de recursos.
Fecha de inicio de nivel de recursos de actividad
Opcional
Manual
Formato de datos:
Fecha
Comportamiento: define el inicio más temprano de una actividad en función de las limitaciones de
recursos.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos y hay un
sobre la asignación de recursos, se debe utilizar la nivelación de recursos.
Definición: El punto en el tiempo asociado con la fecha de inicio programada de la actividad de un
recurso limitado
Actividad Recurso Cantidad total
Requerido (RRC)
Manual / Calculado
Formato de datos:
Numérico
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. Si se asignan recursos, actividad
total
Se debe utilizar la cantidad de recursos.
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
Página 64
52
4 4
Índice de criticidad del riesgo de actividad
Requerido (KRC)
Calculado
Formato de datos:
Numérico
Comportamiento: la probabilidad de que una actividad se convierta en miembro de una ruta crítica.
Buenas prácticas: se debe utilizar un proceso de análisis de riesgos para proyectos donde las partes
interesadas creen que existe
alto riesgo. El análisis de riesgos es apropiado para proyectos en los que las variaciones de horario
tienen un impacto significativo en
Definición: La probabilidad de que la actividad del cronograma esté en una ruta crítica, calculada
dividiendo
el número de veces que la actividad está en una ruta crítica durante la simulación por el número de
iteraciones en ese
simulación.
Definición del alcance de la actividad
Opcional
Manual
Formato de datos:
Alfanumérico
Comportamiento: permite registrar información definida por el usuario sobre el trabajo a realizar.
Buenas prácticas: se debe proporcionar la definición del alcance de la actividad para cada actividad
para unir más
la obra.
Definición: Narrativa documentada que describe el trabajo representado por la actividad.
Duración total de la actividad
Necesario
Calculado / Manual
Formato de datos:
Numérico
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 de programación. por
programar actividades en progreso, incluye la duración real de la actividad más la duración restante de
la actividad.
Actividad Porcentaje de trabajo completado
Opcional
Calculado / Manual
Formato de datos:
Comportamiento: representa la proporción del esfuerzo de trabajo real completado en un punto dado
en el tiempo.
Buenas practicas:
Definición: Una estimación, expresada como un porcentaje de la cantidad de trabajo que se ha
completado en un
programar actividad. Por lo general, se basa en el porcentaje de duración de la actividad completa y el
perfil de horas de trabajo.
asignado a la actividad.
Página 65
53
4 4
Lo más tarde posible
Opcional: sin puntuación
Manual
Formato de datos:
Alfanumérico
Comportamiento: permite programar una actividad para que finalice en su última fecha de
finalización dado el presente
programar la lógica y las restricciones del modelo. El comportamiento de las restricciones lo más
tarde posible es una herramienta de programación
dependiente.
Prac buenos t hielos: No restricciones son para ser un reemplazo para la lógica de la red del
cronograma. El "tan tarde como
posible restricción ”debe usarse con moderación.
Definición: una restricción impuesta a una actividad que hará que se programe para finalizar en una
fecha sin
retrasar las actividades sucesoras.
Tan pronto como sea posible
Manual
Formato de datos:
Alfanumérico
Comportamiento: permite programar una actividad para que finalice en su fecha de finalización
temprana de CPM. El "tan pronto
como posible restricción "depende de la herramienta de programación.
Buenas prácticas: normalmente, la restricción de fecha predeterminada. Se usa 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 su finalización lo antes
posible
fecha posterior a la fecha de inicio del proyecto basada en cualquier actividad predecesora y lógica de
programación.
Modelo de cronograma de referencia
Necesario
Formato de datos:
Varios
Comportamiento: captura los componentes de programación en el momento en que el plan del
proyecto fue aprobado por el proyecto
partes interesadas
Buenas practicas:
Nota condicional / componente asociado: el desarrollo del modelo de programación admite
establecimiento y aprobación de un punto de análisis.
Definición: Un modelo de cronograma de referencia es una copia de los componentes de
programación en el momento en que se planifica el proyecto.
fue aprobado por las partes interesadas del proyecto (el último modelo de cronograma aprobado) y se
utiliza para comparar
a otras instancias de modelo de programación.
Presupuesto al finalizar (BAC)
Requerido (ERC)
Calculado
Formato de datos:
Número
Comportamiento: define el presupuesto autorizado del proyecto.
Buenas prácticas: Incluya recursos y costos asociados en el modelo de programación para definir la
fase de tiempo
presupuesto.
Nota condicional / componente asociado: un BAC aprobado por la administración puede llamarse
aprobado
base.
Definición: La suma total de los costos de recursos enumerados en el modelo de cronograma
aprobado por la administración.
El BAC puede calcularse por actividad y luego sumarse a varios niveles.
Página 66
54
4 4
Identificador de solicitud de cambio
Opcional
Manual
Formato de datos:
Alfanumérico
Comportamiento: identifica cambios autorizados de configuración controlados en el modelo de
programación.
Buenas prácticas: como parte de la gestión de la configuración del horario, utilice el identificador de
solicitud de cambio para
marcar cambios en el modelo de programación aprobados por los procesos de gestión de
configuración Este artículo es normalmente
abordado en un campo personalizado.
Nota condicional / Componente asociado: Consulte el Estándar de práctica para la gestión de la
configuración .
Definición: El identificador de solicitud de cambio es el valor de clave principal para los elementos en
el registro de cambios del programa como
relacionado con el modelo de horario.
ID de cuenta de control
Requerido (ERC)
Manual
Formato de datos:
Alfanumérico
Comportamiento: identifica tareas que pertenecen a una cuenta de cobro de costos establecida.
Buenas prácticas: incluya el Identificador de la cuenta de control cuando utilice la metodología del
valor ganado en el
programar.
ganado.
Definición: un identificador alfanumérico de contabilidad de costos típicamente asignado en la
intersección del trabajo
estructura de desglose y estructura de desglose organizacional en el nivel donde se recaudarán los
costos.
Las cuentas de control contienen paquetes de trabajo.
Gerente de cuentas de control (CAM)
Opcional
Manual
Formato de datos:
Alfanumérico
Comportamiento: identifica a la persona sola responsable del rendimiento de los costos de una
cuenta de control específica.
Buenas prácticas: incluya el identificador CAM cuando utilice la metodología del valor ganado en el
cronograma.
A veces se usa un número de referencia para un CAM sin nombrar a un individuo.
ganado .
Definición: una designación alfanumérica de la persona soltera responsable de los costos y logros
del alcance del trabajo identificado por la cuenta de control; este puede ser el nombre de un individuo
o un único
referencia que identifica al individuo.
Índice de rendimiento de costos (IPC)
Opcional
Calculado
Formato de datos:
Número
Comportamiento: define el rendimiento de los costos en relación con los logros y el presupuesto por
etapas.
Buenas prácticas: incluya el IPC cuando utilice la metodología del valor ganado en el cronograma.
ganado.
Definición: EV / AC, calculado como valores en fases temporales y utilizado para medir la
rentabilidad en un proyecto.
Estos valores se pueden calcular en cualquier nivel de esquema del modelo de programación y entre
varias fechas de datos. Si el
el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los
valores se denominan
"acumulativo."
Page 67
55
4 4
Variación de costo (CV)
Opcional
Calculado
Formato de datos:
Número
Comportamiento: la desviación en el tiempo del rendimiento alcanzado de los costos reales.
Buenas prácticas: incluya la variación de costos al utilizar la metodología del valor ganado en el
cronograma.
ganado .
Definición: EV – AC, calculada como valores en fases temporales y utilizada para medir el
rendimiento de costos en un proyecto. Estas
los valores se pueden calcular en cualquier nivel de esquema del modelo de programación y entre
varias fechas de datos. Si el cálculo es
realizado utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los valores se
denominan "acumulativos".
Porcentaje de variación de costo (% CV)
Opcional
Calculado
Formato de datos:
Número
Comportamiento: la desviación en fases temporales del rendimiento programado del rendimiento
real alcanzado
expresado como un porcentaje.
Buenas prácticas: Incluya el porcentaje de variación de costos al usar la metodología del valor
ganado en el cronograma.
ganado .
Definición: 100 (EV AC) / (EV), calculados como valores en fases temporales. Estos valores pueden
calcularse en
cualquier nivel de esquema del modelo de programación y entre varias fechas de datos. Si el cálculo
se realiza utilizando el
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
Necesario
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 una lógica y
un buen
relaciones de actividad definidas con duraciones derivadas empíricamente para ejecutar todas las
actividades del proyecto en un
Manera práctica. Por lo tanto, no habrá 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 ser
efectivamente dirigido con lógica de 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. En general, es el camino más largo a través del proyecto. Sin embargo, una ruta crítica
puede terminar, por ejemplo,
en un hito de programación que se encuentra en el medio del modelo de programación y que tiene un
final no más tarde que
fecha impuesta restricción de horario. Consulte también ruta crítica del proyecto , ruta
crítica especificada y método de ruta crítica .
Campo personalizado
Opcional
Manual
Formato de datos:
Variable
Comportamiento: proporciona metainformación sobre otros datos del modelo de programación.
Buenas prácticas: el campo personalizado puede utilizar cualquiera de los tipos de atributos; alfa,
alfanumérico, fecha,
tiempo, etc. Una buena práctica es usar campos personalizados para ordenar y agrupar actividades en
el modelo de programación
presentaciones
Definición: Elementos de datos utilizados como característica extendida de entidades de planificación
(por ejemplo, código, campo, etiqueta, etc.).
Página 68
56
4 4
Fecha de Datos
Necesario
Manual
Formato de datos:
Fecha
Comportamiento: define la división entre períodos de progreso históricos y futuros. También
conocido como fecha de estado.
Buenas prácticas: la fecha de los datos se adelantará en el momento del estado del informe, a
intervalos regulares.
Definición: la fecha (incluida la hora del día) a través de la cual el estado del proyecto y el progreso
fueron los últimos
determinado e informado para análisis, como la programación y las mediciones de rendimiento. Es el
ultimo
Fecha histórica pasada. A veces se llama a la fecha. (Advertencia del programador: algunos programas
de gestión de proyectos
utilizado para la programación trata la fecha de datos como la fecha futura inmediatamente después de
que se informa el estado).
Recursos de conducción
Opcional
Manual
Formato de datos: Indicador (determinado por algoritmo (booleano))
Comportamiento: identifica un recurso como conductor para controlar la duración de las actividades.
Buenas prácticas: los recursos de conducción deben considerarse dentro del cronograma.
Definición: Recursos que se consideran que tienen un impacto directo en la duración de la actividad
durante el recurso.
arrasamiento.
Valor Ganado (EV)
Requerido (ERC)
Calculado
Formato de datos:
Número
Comportamiento: Medición de logros.
Buenas prácticas: incluya el valor ganado al usar la metodología de valor ganado en el modelo de
programación.
ganado .
Este término también se conoce como costo presupuestado del trabajo realizado (BCWP).
Definición: El valor en fases temporales del esfuerzo realizado, independiente del costo necesario
para lograr
el logro el costo que se presupuestaría para la cantidad de trabajo completado antes de su
ejecución. Cuando se completa, EV BAC. Estos valores pueden calcularse en cualquier esquema de
nivel y entre varias fechas de datos. Si 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".
Método del valor ganado
Opcional
Manual
Formato de datos:
Alfanumérico
Comportamiento: identifica uno de los métodos reconocidos para recopilar el valor ganado tal como
se define en el proyecto
sistemas de gestión del valor ganado (EVMS).
Buenas prácticas: para la integración de costo / cronograma, incluya el método del valor ganado al
usar ganado
metodología de valor en el cronograma. El método indicado en el programa coincide con el método
del valor ganado
indicado en el paquete de trabajo.
ganado .
Definición: La designación alfanumérica de un método específico para recolectar el valor ganado en
el cronograma.
como se define en el EVMS.
Página 69
57
4 4
Valor Ganado Peso
Opcional
Manual
Formato de datos:
Número
Comportamiento: asigna un porcentaje del valor ganado (EV) para un paquete de trabajo que se
asignará a
ocupaciones.
Buenas prácticas: cuando el EV se asignará sobre una base porcentual, use el peso EV en el
programa
donde corresponda.
Nota condicional / Culo o componentes ciados: Ver la Norma Práctica para la Gestión del Valor
Ganado .
Definición: El porcentaje de EV asignado a un grupo específico de actividades.
Estimación al finalizar (EAC)
Requerido (ERC)
Calculado
Formato de datos:
Número
Comportamiento: define el costo total, incluidos los costos reales ya incurridos, más los costos
adicionales requeridos
para completar el esfuerzo.
Buenas prácticas: asigne un valor que represente los costos totales proyectados incurridos al
finalizar,
independiente de un presupuesto autorizado.
Definición: AC ETC, costos acumulativos reales incurridos (AC) más costos anticipados para
completar el
alcance restante independiente del presupuesto. El EAC se calcula típicamente para cada actividad y
luego se suma a
varios niveles Existen numerosos métodos para calcular el valor de los costos adicionales que se
estima completar
El alcance restante.
Estimación para completar (ETC)
Requerido (ERC)
Calculado
Formato de datos:
Número
Comportamiento: define el costo requerido para completar el alcance restante identificado, sin tener
en cuenta
gastos o presupuesto.
Buenas prácticas: asigne un valor que represente el costo restante proyectado para completar,
independientemente de
Presupuesto autorizado.
Definición: Costos anticipados para completar el alcance restante independientemente del presupuesto
y el real previo
costos El ETC generalmente se calcula para cada actividad y luego se suma a varios niveles. Hay
numerosos
métodos para predecir el valor de los costos restantes para el alcance restante.
Page 70
58
4 4
Acabado esperado
Manual
Formato de datos:
Fecha
Comportamiento: impone una fecha de finalización en una actividad que determina la duración
restante de la actividad
después de que se haya informado como iniciado con un inicio real. El comportamiento de las
restricciones de acabado esperadas son
herramienta de programación dependiente.
Buenas prácticas: las restricciones no deben reemplazar la lógica de red programada. El final
esperado
la restricción 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 la actividad de un en progreso
programar la actividad que afecta cuándo se puede programar la finalización de la actividad del
cronograma y generalmente está en
La forma de una fecha de imposición fija. Esta restricción requiere que la "duración restante de la
actividad" sea igual
a la diferencia entre la fecha de finalización esperada de la actividad y la fecha de datos para forzar la
actividad programada
se programará para finalizar en la fecha impuesta.
Acabado no antes de
Manual
Formato de datos:
Fecha
Comportamiento: impone una fecha de finalización de una actividad antes de la cual la actividad no
puede finalizar. El comportamiento
de "terminar no antes de" depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de red programada. El final no
antes
que 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
programado y generalmente tiene la forma de una fecha de imposición fija. Un acabado no anterior a
la restricción impide que
la actividad está programada para finalizar antes de la fecha impuesta. Impacto de las restricciones
"No antes de"
solo el cálculo de pase directo de CPM y, por lo tanto, solo las fechas tempranas de CPM de una
actividad programada.
Terminar a más tardar
Opcional
Manual
Formato de datos:
Fecha
Comportamiento: impone una fecha al final de una actividad que especifica la última fecha en que
una actividad puede finalizar.
El comportamiento de "finalizar a más tardar" depende de la herramienta de programación.
Buenas prácticas: las restricciones no deben reemplazar la lógica de red programada. El "terminar no
más tarde
que "la restricción debe usarse con moderación.
puede
programado y generalmente tiene la forma de una fecha de imposición fija. Un acabado no posterior a
la restricción impide que
la actividad está programada para finalizar después de la fecha impuesta. Las restricciones "a más
tardar el" solo afectan
el cálculo del pase hacia atrás de CPM y, por lo tanto, el CPM calculó las fechas tardías de una
actividad de programación
Page 71
59
4 4
Terminar en
Manual
Formato de datos:
Fecha
Comportamiento: Impone una fecha en el final de una actividad en la que finalizará. Impacta tanto el
CPM
hacia adelante y el cálculo del pase de CPM hacia atrás y, por lo tanto, las fechas tempranas y tardías
de CPM. Esto causa
la actividad para tener un flotante total cero mientras que sus predecesores y sucesores pueden tener
diferentes valores flotantes.
La fecha de finalización se moverá con la fecha de datos si la fecha de datos es posterior a la fecha de
finalización y si la fecha
La actividad no está completa. El comportamiento de finalizar en restricciones depende de la
Buenas prácticas: las restricciones no deben reemplazar la lógica de red programada. Desde esta
restricción
anula el cálculo de CPM, este componente no debe usarse.
Definición: una restricción de fecha colocada en la actividad de programación que requiere que la
actividad de programación finalice
en una fecha específica Los cálculos de programación no anulan esta restricción. Por lo tanto, un
impuesto "terminar en"
establece las fechas tempranas de pase adelantado 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.
Finish to Finish
Opcional
Manual
Formato de datos:
Alfanumérico (ID de actividad)
Comportamiento: especifica para dos actividades que la actividad sucesora no puede completarse
hasta que la predecesora
La actividad se ha completado.
Buenas prácticas: todas las actividades, excepto la primera y la última, deberán tener al menos un
predecesor "? S"
relación y una relación sucesora "F?", donde "?" puede ser una S o una F, independientemente de
cualquier otra
relaciones que pueden estar presentes. (Donde S comienza y F termina).
Definición: La relación lógica donde la finalización del trabajo de la actividad sucesora no puede
terminar hasta
La finalización del trabajo de la actividad predecesora.
Necesario
Manual
Formato de datos:
Comportamiento: especifica para dos actividades que la actividad sucesora no puede iniciarse hasta
que la predecesora
La actividad se ha completado.
Buenas prácticas: todas las actividades, excepto la primera y la última actividad, deberán tener al
menos un predecesor "? S"
cualquier otra
relaciones que pueden estar presentes. (Donde S comienza y F termina. Normalmente, el más utilizado
relación.
Definición: La relación lógica donde el inicio del trabajo de la actividad sucesora depende de
finalización del trabajo de la actividad predecesora.
Page 72
60 60
4 4
Flotador Libre
Necesario
Calculado
Formato de datos:
Numérico
Comportamiento: representa la cantidad de tiempo que una actividad puede retrasar su finalización
temprana sin afectar al sucesor
actividades de inicio temprano. Es la diferencia entre la fecha de finalización temprana de una
actividad y la fecha de inicio más temprana de
El más cercano de sus sucesores. A medida que se registra el progreso, este valor puede cambiar. Este
valor también puede cambiar
si se revisa el trabajo restante, la lógica o las duraciones.
Buenas prácticas: la flotación libre puede usarse para proporcionar una indicación temprana de
actividad o deslizamiento de horario.
Definición: la cantidad de tiempo que se puede retrasar una actividad del cronograma sin retrasar el
CPM temprano
inicio de las actividades programadas inmediatamente siguientes. Ver también flotación total.
Retraso
Opcional
Manual
Formato de datos:
Numérico
Comportamiento: modifica una relación lógica para imponer un retraso en el inicio o el final 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 deberían ser
usado con moderación. Los retrasos solo deben usarse durante un período de tiempo inmutable que
ocurre entre una actividad
y otro. Un retraso no debería tomar recursos.
Definición: Una modificación de una relación lógica que dirige un retraso en la actividad
sucesora. por
Por ejemplo, en una dependencia de principio a inicio con un retraso de 10 días, la actividad sucesora
no puede comenzar hasta 10 días
después de que la actividad predecesora haya terminado. Ver también plomo .
Dirigir
Manual
Formato de datos:
Numérico
Comportamiento: modifica una relación lógica para imponer una aceleración al comienzo o al final
del sucesor
actividad, análoga al retraso "negativo".
Buenas prácticas: los clientes potenciales no son un reemplazo para la lógica o las actividades de la
red programada. Los cables deben ser
usado raramente. Los leads solo se utilizarán durante un período de tiempo inmutable que ocurre entre
una actividad y
otro. Un líder 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 principio a inicio con una ventaja de 10 días, la actividad
sucesora puede comenzar 10 días
antes de que la actividad predecesora haya terminado. Un plomo negativo es equivalente a un retraso
positivo. Ver también retraso.
Page 73
61
4 4
Fecha de finalización obligatoria
Manual
Formato de datos:
Fecha
Comportamiento: Impone una fecha en el final de una actividad en la que finalizará. Impacta tanto el
CPM
cálculos de fecha de aprobación hacia adelante y hacia atrás y, por lo tanto, fechas tempranas y
tardías. Esto provoca la
actividad para tener un flotante total cero, mientras que sus predecesores y sucesores pueden tener
diferentes valores flotantes. los
El comportamiento de las restricciones obligatorias de la fecha de finalización depende de la
restricción
actividad de programación finalice
en una fecha específica Los cálculos de programación no anulan esta restricción. Por lo tanto un
impuesto obligatorio
terminar establece las fechas de finalización temprana de CPM para todas las rutas que conducen
desde y las fechas de finalización tardía en las rutas que conducen a
la actividad. También conocido como Must Finish On.
Fecha de inicio obligatoria
Manual
Formato de datos:
Fecha
Comportamiento: Impone una fecha en el inicio de una actividad en la que comenzará. Impacta tanto
el CPM hacia adelante
y los cálculos de aprobación hacia atrás y, por lo tanto, las fechas de CPM temprano y tarde. Esto hace
que la actividad
tener un flotante total cero, mientras que sus predecesores y sucesores pueden tener diferentes valores
flotantes. El comportamiento
de las restricciones obligatorias de la fecha de inicio dependen de la herramienta de programación.
restricción
Definición: una restricción de fecha colocada en la actividad de programación que requiere que
comience la actividad de programación
en una fecha específica Los cálculos de programación no anulan esta restricción. Por lo tanto, un
impuesto obligatorio
start establece las fechas tempranas de CPM para todas las rutas que conducen desde y las fechas
tardías de CPM en las rutas que conducen a
actividad. También conocido como Must Start On.
Hito
Necesario
Calculado
Formato de datos:
Indicador (determinado por algoritmo (booleano))
Comportamiento: una actividad que identifica un evento significativo.
Buenas prácticas: el hito no tiene recursos asignados ni duración. Como mínimo, un proyecto de
inicio
y terminar el hito 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 un calendario de eventos .
Page 74
62
4 4
Valor planificado (PV)
Requerido (ERC)
Calculado
Formato de datos:
Número
Comportamiento: la medición por etapas de los gastos anticipados.
Buenas prácticas: incluya el valor planificado cuando utilice la metodología del valor ganado en el
ganado .
Este término también se conoce como costo presupuestado de trabajo programado (BCWS). PV a
veces se conoce como
plan de referencia.
Definición: El valor en fases temporales de la administración aprobó los gastos previstos y necesarios.
para lograr el alcance definido. Cuando se completa el alcance, PV BAC. Estos valores pueden
calcularse en
Distribución de riesgo de probabilidad
Requerido (KRC)
Calculado
Formato de datos:
Numérico
Comportamiento: las distribuciones de riesgo de probabilidad deben asignarse a actividades para el
análisis cuantitativo de riesgo.
Las distribuciones de riesgo de probabilidad comunes incluyen: normal — o curva de campana, log
normal, uniforme, triangular, Beta,
y discreto (definido por el usuario).
Buenas prácticas: se puede encontrar en el Estándar de prácticas para la gestión de riesgos de
proyectos. Riesgo de probabilidad
la distribución debe asignarse a cada actividad en el modelo de programación. Datos, generalmente
determinados por juicio,
se recopila de los participantes del proyecto y otros expertos durante entrevistas de riesgo o talleres.
Definición: define la probabilidad de que determinados atributos o rangos de atributos sean o hayan
sido
observado.
Duración real del proyecto
Necesario
Calculado
Formato de datos:
Numérico
Comportamiento: identifica el tiempo transcurrido desde que comenzó 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
proyecto y la fecha de datos de la instancia del modelo de programación si el proyecto está en
progreso o el proyecto
fecha de finalización real si el proyecto está completo.
Fecha de finalización real del proyecto
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: identifica el final 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.
Página 75
63
4 4
Fecha de inicio real del proyecto
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: define el inicio real de la actividad más temprana del proyecto.
Buenas practicas:
Nota condicional / componente asociado: a partir del detalle.
Definición: El punto en el tiempo asociado con la "fecha de inicio real de la actividad" del primer
horario
actividad en el proyecto.
Calendario del proyecto
Necesario
Manual
Formato de datos:
Fecha y hora
Comportamiento: define los períodos de trabajo predeterminados para el proyecto
Buenas prácticas: a nivel de proyecto, esto constituirá el calendario primario o predeterminado para
el proyecto.
Definición: Un calendario de períodos laborales y no laborales que establece cuándo se programan las
actividades.
trabajó y cuando las actividades del horario están inactivas Normalmente define días festivos, fines de
semana y horas de turno. los
calendario inicialmente asignado para programar actividades y recursos. Ver también calendario de
actividades y recursos.
calendario .
Categoría de costo del proyecto
Opcional
Manual
Formato de datos:
Alfanumérico
Comportamiento: proporciona desgloses adicionales que pueden asignarse para una cuenta de costo
específica dentro del
proyecto.
Buenas prácticas: a efectos contables, los costos deben desglosarse en categorías tales como directas,
indirecto, laboral, material, equipamiento, etc.
Definición: Elementos contables utilizados para integrar el plan tradicional de líneas de cuenta con el
proyecto.
estructura de contabilidad de costos.
Descripción del Proyecto
Opcional
Manual
Formato de datos:
Alfanumérico
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 de la declaración del alcance del proyecto.
Page 76
64
4 4
Requerido (ver Proyecto
Porcentaje de duración del proyecto completado
Porcentaje físico completo)
Calculado
Formato de datos:
Comportamiento: representa el progreso del proyecto como un porcentaje de la duración total
prevista del proyecto.
Buenas practicas:
Nota condicional / componente asociado: se utilizará el porcentaje de duración del proyecto
completado o el proyecto
porcentaje físico completo
Definición: una estimación, expresada como un porcentaje, de la duración total del proyecto que se ha
completado
sobre el proyecto.
Fecha de finalización temprana del proyecto
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: identifica el final temprano de la última actividad.
Definición: El punto en el tiempo asociado con la fecha de finalización temprana de la actividad de la
última actividad del cronograma de
el proyecto.
Fecha de inicio temprano del proyecto
Necesario
Calculado
Formato de datos: fecha
Comportamiento: define el inicio temprano de CPM de la primera actividad del proyecto, en función
del pase de avance de CPM.
Definición: El punto de tiempo más temprano posible asociado con el comienzo de la primera
del proyecto.
Restricción de finalización del proyecto
Opcional
Manual
Formato de datos:
Fecha
Comportamiento: proporciona el punto de partida para el pase hacia atrás de CPM para el
proyecto. Se utiliza la restricción.
como punto de partida para el cálculo del pase hacia atrás para cualquier actividad en el modelo de
programación sin
sucesores y sin restricciones de paso atrás de CPM. Esta fecha puede ser anterior o posterior a la
finalización del proyecto.
fecha que se calcula a partir del pase de CPM hacia adelante.
Buenas prácticas: la fecha de finalización, generalmente definida por el cliente, e incluida en el
Es necesario hacer un esfuerzo para desarrollar un modelo de cronograma alcanzable con flotación
total no negativa. Esta
El esfuerzo debe dar como resultado un modelo de cronograma con un nivel de riesgo aceptable para
todos los interesados. Si esto no es
cumplido, se informará a la parte interesada que define la restricción de finalización del proyecto y se
elaborará un plan de mitigación
acordado.
Definición: Una limitación o restricción colocada en la fecha de finalización tardía del proyecto que
afecta cuando el proyecto
necesita terminar y generalmente tiene la forma de una fecha de imposición fija.
Page 77
sesenta y cinco
4 4
Proyecto Fecha de finalización tardía
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: identifica el final tardío de la última actividad.
Definición: El punto en el tiempo asociado con la fecha de finalización tardía de la actividad de la
última actividad programada de
el proyecto.
Fecha de inicio tardío del proyecto
Necesario
Calculado
Formato de datos:
Fecha
Comportamiento: define el inicio tardío de la primera actividad del proyecto, en función del paso
hacia atrás.
Definición: El último momento posible asociado con el comienzo de la primera actividad del
cronograma.
del proyecto.
Gerente de proyecto
Opcional
Manual
Formato de datos:
Alfanumérico
Comportamiento: muestra el nombre del gerente del proyecto.
Buenas prácticas: deben mostrarse en todos los resultados.
Definición: La persona asignada por la organización ejecutora para lograr los objetivos del proyecto.
Nombre del proyecto
Necesario
Manual
Formato de datos:
Alfanumérico
Comportamiento: describe, en forma abreviada, el proyecto.
Buenas practicas:
Definición: una frase corta o etiqueta para cada proyecto, utilizada junto con el identificador del
proyecto para
diferenciar un proyecto particular de otros proyectos en un programa. También conocido como título
del proyecto.
78 de 1189.
66
4 4
Requerido (ver Proyecto
Proyecto Porcentaje físico completo
Duración Porcentaje completo)
Calculado
Formato de datos:
Comportamiento: representa el progreso del proyecto como un porcentaje del trabajo físico total a
realizar. A
A nivel del proyecto, este valor se calcula típicamente, utilizando técnicas de gestión del valor
ganado. Como progreso
se registra, se calcula el valor ganado a nivel de actividad.
Buenas Prácticas: realizado de acuerdo con la Práctica Estándar para Ganado
Valu e Gestión . Proyecto
el porcentaje físico completo se determina dividiendo las unidades de valor ganado resumidas por el
proyecto
Presupuesto en las mismas unidades.
Nota condicional / Componente asociado: Requiere el uso de la técnica del valor ganado. Deberá
usar cualquiera
porcentaje de duración del proyecto completado o porcentaje físico del proyecto completado.
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 progreso del trabajo físico.
Duración restante del proyecto
Necesario
Calculado
Formato de datos:
Numérico
Comportamiento: identifica el período de tiempo requerido para completar el proyecto desde la fecha
de datos.
Buenas prácticas: una vez que un proyecto comienza pero no se completa durante un ciclo de
informe, una determinación
se realiza en cuanto a la duración que queda para completar el trabajo.
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 programación y la fecha de
finalización temprana 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.
Proyecto Recurso Cantidad real
Requerido (RRC)
Manual / Calculado
Formato de datos:
Numérico
Comportamiento: medida de la utilización de recursos para el proyecto a partir de la fecha de datos
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos, proyecte
real
Se debe utilizar la cantidad.
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 del nivel de recursos del proyecto
Opcional
Calculado
Formato de datos:
Fecha
Comportamiento: identifica el final más temprano para un proyecto en función de las limitaciones de
recursos.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos y recursos
existen más de asignaciones, se debe utilizar la nivelación de recursos.
Definición: El momento en el tiempo asociado con la última fecha de finalización programada de
actividad de un recurso limitado
Página 79
67
4 4
Fecha de inicio de nivel de recursos del proyecto
Opcional
Calculado
Formato de datos:
fechas
Comportamiento: identifica la fecha de inicio de actividad más temprana como restringida por la
disponibilidad de recursos.
Buenas prácticas: los recursos deben ser identificados y asignados. Si un recurso asignado es
limitado, recurso
Se debe realizar la nivelación.
Definición: La fecha de inicio de un proyecto basada en la consideración de disponibilidad de
recursos, limitaciones,
y cantidades
Cantidad total de recursos del proyecto
Requerido (RRC)
Manual / Calculado
Formato de datos:
Numérico
Comportamiento: medida de las asignaciones de recursos del proyecto, generalmente expresadas
como tipo de recurso o
medida.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos, total del
proyecto
Se debe utilizar la cantidad.
Definición: La unidad para expresar asignaciones de recursos en todas las actividades del proyecto.
Restricción de inicio de proyecto
Opcional
Manual
Formato de datos:
Fecha
Comportamiento: proporciona el punto de partida para el pase de avance del proyecto. Se utilizará
como el inicio
apunte para el cálculo del pase directo para cualquier actividad en el modelo de programación sin
predecesores y sin
restricciones de paso adelante.
Buenas prácticas: la fecha de inicio generalmente 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. Esta
el esfuerzo debe tener en cuenta los recursos disponibles y dar como resultado un modelo de
cronograma con un nivel de riesgo aceptable
a todos los interesados. Si esto no se logra, la parte interesada que define la restricción de inicio del
proyecto será
informado y un plan de mitigación acordado.
Definición: Una limitación o restricción colocada en la fecha de inicio temprano del proyecto que
afecta cuándo el proyecto puede
inicio y generalmente tiene la forma de una fecha de imposición fija.
Duración total del proyecto
Necesario
Calculado
Formato de datos:
Numérico
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 la duración real del proyecto más la duración restante del proyecto.
80
68
4 4
Asignación de recursos
Requerido (RRC)
Manual
Formato de datos:
Numérico
Comportamiento: acción para asignar un recurso a una actividad.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos, recurso
Se utilizará la asignación.
Definición: La actividad de asignar un recurso a un elemento del modelo de programación específico.
Disponibilidad de recursos
Requerido (RRC)
Manual
Formato de datos:
Alfanumérico
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 lo
indicado
recurso.
Definición: las fechas y el número de períodos de trabajo en unidades de calendario que un recurso
dado puede ser utilizado
de acuerdo con el calendario de recursos apropiado.
Calendario de recursos
Requerido (RRC)
Manual
Formato de datos:
Fecha y hora
Comportamiento: define los períodos de trabajo para el recurso.
Buenas practicas:
Definición: Un calendario de períodos de trabajo y no laborables asignados al recurso que define el
períodos de trabajo y períodos no laborales en formato de calendario. Normalmente define vacaciones
específicas de recursos y
períodos de disponibilidad de recursos. Vea también el calendario del proyecto y el calendario de
actividades .
Descripción del recurso
Requerido (RRC)
Manual
Formato de datos:
Alfanumérico
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, el
recurso
Se necesita una descripción. Todas las descripciones de recursos serán únicas.
Definición: Una frase que identifica un recurso por tipo, rol o individuo. También conocido como
Nombre del recurso.
ID de recurso
Requerido (RRC)
Calculado
Formato de datos:
Alfanumérico
Comportamiento: identifica el recurso asignado.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se identifica un recurso, la ID
del recurso
necesita ser usado. Todos los ID de recursos serán ú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.
Página 81
69
4 4
Retraso de recursos
Opcional
Manual
Formato de datos:
Numérico
Comportamiento: define el tiempo desde el inicio de la actividad que un recurso específico puede
comenzar a funcionar.
Buenas prácticas: los recursos deben ser identificados y asignados. Los retrasos de recursos solo se
deben utilizar para un
período de tiempo inmutable 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
trabajar en la actividad del horario.
Nivelación de recursos
Opcional
Calculado
Formato de datos:
Fórmula
Comportamiento: implica el proceso de recalcular las fechas programadas, en función de la
disponibilidad de recursos.
Buenas prácticas: la nivelación de recursos requiere la asignación de límites de recursos o
disponibilidades, así como
algunos criterios de priorización para resolver conflictos de recursos. El criterio de priorización más
utilizado es la flotación total.
A menudo, este esfuerzo de nivelación también incluye consideraciones financieras, así como los
límites de los recursos físicos de
cualquier tipo. Los resultados calculados deben evaluarse manualmente frente a las expectativas y
referencias históricas.
Definición: Cualquier forma de análisis de red de cronograma en el que las decisiones de
programación (fechas de inicio y finalización)
son impulsados por limitaciones de recursos (por ejemplo, disponibilidad limitada de recursos o
cambios difíciles de manejar en
niveles de disponibilidad de recursos).
Biblioteca de recursos / Diccionario
Requerido (RRC)
Manual
Formato de datos:
Alfanumérico
Comportamiento: proporciona una lista de recursos aplicados a actividades en el modelo de
programación.
Buenas prácticas: los recursos deben ser identificados y asignados. Una biblioteca de recursos o
diccionario debe ser
organizado en una estructura significativa.
Definición: una tabulación documentada que contiene la lista completa, incluidos los atributos de
recursos, de todos
recursos que pueden asignarse a actividades del proyecto. También conocido como diccionario de
recursos.
Tasas de recursos / precios
Opcional
Manual
Formato de datos:
Numérico
Comportamiento: define el costo por unidad de tiempo para un recurso específico.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se asignan recursos, tasas de
recursos /
Los precios deben ser utilizados.
Definición: La tasa de costo unitario asignada a un recurso específico, incluidas las escaladas de tasas
conocidas.
Page 82
70
4 4
Tipo de recurso
Requerido (RRC)
Manual
Formato de datos:
Alfanumérico
Comportamiento: indica la clasificación del recurso.
Buenas prácticas: los recursos deben ser identificados y asignados. Si se identifica un recurso, el
recurso
tipo debe ser utilizado.
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.
ID de riesgo
Requerido (KRC)
Manual / Calculado
Formato de datos:
Alfanumérico
Comportamiento: distingue los riesgos en el registro de riesgos del proyecto.
Buenas prácticas: se puede encontrar en el Estándar de prácticas para la gestión de riesgos de
proyectos. Las identificaciones de riesgo son
mapeado a actividades en el modelo de cronograma donde sea apropiado.
Definición: Una identificación numérica o de texto única y breve asignada a cada riesgo en el registro
de riesgos del proyecto.
Programar ID de modelo
Necesario
Manual
Formato de datos:
Alfanumérico
Comportamiento: identifica el proyecto programado.
Buenas prácticas: será un identificador único que se pueda generar automáticamente o seguir una
numeración
esquema apropiado para la empresa. Es útil asignar una estructura razonada o "codificación" al
cronograma.
ID del modelo.
Definición: Una identificación numérica o de texto única y breve asignada a cada modelo de
programación para diferenciar
ese modelo de horario de otros. También conocido como el identificador del proyecto.
Page 83
71
4 4
Nivel de modelo de programación
Opcional
Manual
Formato de datos:
Numérico
Comportamiento: define la granularidad o niveles de detalle de la programación o su presentación.
Buenas prácticas: independientemente de la profundidad del nivel físico del cronograma general, se
recomienda que
Se utilizarán las siguientes definiciones de nivel de programación:
1. Nivel 1 — Resumen ejecutivo . Este es un cronograma de nivel de resumen, generalmente solo una
página que incluir los principales hitos contractuales y actividades de nivel de resumen.
2. Nivel 2: Resumen de gestión . Este es un cronograma resumido más extenso, generalmente
cuatro a cinco páginas que incluirán el Nivel 1 e informarán sobre actividades similares por área o
capital
equipo.
3. Nivel 3: calendario de publicaciones . Este será el nivel de detalle utilizado para respaldar el
informe mensual.
Incluirá todos los hitos principales, elementos principales de ingeniería, adquisiciones, construcción y
puesta en marcha.
4. Nivel 4: planificación de ejecución . Esto apoya a los equipos de construcción y comisionamiento
en sus planificación general del proyecto. Normalmente se deben mostrar todas las actividades de más
de una semana de duración.
El calendario de anticipación de 3 semanas se produce a partir del Nivel 4 y superior.
5. Nivel 5: planificación detallada. Este nivel de detalle apoyará la planificación a corto plazo para el
campo, normalmente para aquellas actividades de menos de 1 semana de duración. Las soluciones y
áreas críticas pueden ser
explotó aquí.
Definición: una regla especificada por el equipo del proyecto para la granularidad relativa de las
actividades del cronograma en general
modelo de horario.
Programar presentación del modelo
Necesario
Manual
Formato de datos:
Gráfico
Comportamiento: muestra datos de programación.
Buenas prácticas: 1. Se debe emplear una visualización de las actividades del modelo de cronograma
como un gráfico de barras.
2. Las salidas deben representar la fecha en que se genera la salida.
3. Se incluirán las descripciones de la salida y los elementos principales dentro de la salida.
4. Las salidas deben mostrar tanto el progreso como la fecha de datos actual.
5. Cualquier diagrama de red del proyecto debe tener el menor número posible de puntos de cruce
lógicos,
mientras se asegura suficiente espacio para representar líneas de relación. (Ver Figura 23 para
ejemplo.)
Definición: Una salida de instancias de modelo de programación, utilizada para comunicar datos
específicos del proyecto para
Informes, análisis y toma de decisiones.
84
72
4 4
Programar versión del modelo
Necesario
Calculado
Formato de datos:
Alfanumérico
Comportamiento: indica qué revisión del modelo representa la programación.
Buenas prácticas: el número de versión debe incrementarse de manera consistente como sucesivo
se realizan cambios, lo que da como resultado diferentes versiones de la programación.
Definición: Una designación de la instancia de un modelo de programación. Los ejemplos incluyen
hasta la fecha, revisión
número y códigos de versiones acordados, entre otros.
Índice de rendimiento de programación (SPI)
Opcional
Calculado
Formato de datos:
Número
Comportamiento: define el rendimiento del cronograma comparando el trabajo realizado con el
trabajo programado.
Buenas prácticas: Incluya SPI cuando utilice la metodología del valor ganado en el cronograma.
ganado.
Definición: EV / PV, calculado como valores en fases temporales y utilizado para medir un progreso
relativo a la
programar. Estos valores pueden calcularse en cualquier nivel de esquema del modelo de
programación y entre varios datos
fechas. Si el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual,
los valores
se llaman "acumulativos".
Variación de programación (SV)
Opcional
Calculado
Formato de datos:
Número
Comportamiento: desviación del rendimiento programado del rendimiento real alcanzado.
Buenas prácticas: incluya la variación del cronograma cuando utilice la metodología del valor
ganado en el cronograma.
ganado .
Definición: EV – PV, calculada como valores en fases temporales y utilizada para medir un progreso
relativo a la
programar. Estos valores pueden calcularse en cualquier nivel de esquema del modelo de
programación y entre varios datos
fechas. Si el cálculo se realiza utilizando la fecha de inicio del proyecto y la fecha de datos más actual,
los valores
se llaman "acumulativos".
Porcentaje de varianza programada (SV%)
Opcional
Calculado
Formato de datos:
Número
Comportamiento: desviación del rendimiento programado del rendimiento real alcanzado.
Buenas prácticas: Incluya el porcentaje de variación del cronograma cuando use la metodología del
valor ganado en el cronograma.
ganado .
Definición: 100 (EV – PV) / (PV), calculados como valores en fases temporales. Estos valores pueden
calcularse en
Page 85
73
4 4
Comience no antes de
Manual
Formato de datos:
Fecha
Comportamiento: impone una fecha en el inicio de una actividad antes de la cual la actividad no
puede comenzar. "No antes
que "las restricciones afectan solo el cálculo del avance y, por lo tanto, las fechas iniciales de una
actividad.
Buenas prácticas: las restricciones no deben reemplazar la lógica de red programada. El "comienzo
no antes
que "la restricción debe usarse con moderación.
puede
programado y generalmente tiene la forma de una fecha de imposición fija. Un "comienzo no antes"
que la restricción impide
la actividad programada se programa para comenzar antes de la fecha impuesta.
Comience no más tarde de
Manual
Formato de datos:
Fecha
Comportamiento: impone una fecha al inicio de una actividad que especifica la última fecha en que
puede comenzar una actividad.
Buenas prácticas: las restricciones no deben reemplazar la lógica de red programada. El comienzo no
mas tarde
que la restricción debe usarse con moderación.
puede
programado y generalmente tiene la forma de una fecha de imposición fija. Una restricción de "inicio
a más tardar" impide
la actividad programada se planifica para comenzar más tarde que la fecha impuesta.
Comienza en
Manual
Formato de datos:
Fecha
Comportamiento: Impone una fecha en el inicio de una actividad en la que comenzará. Impacta tanto
el delantero como el
los cálculos de retroceso y, por lo tanto, las fechas tempranas y tardías. Esto hace que la actividad
tenga un
flotante total cero, mientras que sus predecesores y sucesores pueden tener diferentes valores
flotantes. La fecha de inicio será
moverse con la fecha de datos si la fecha de datos es posterior a la fecha de inicio. El comportamiento
de inicio en restricciones
son dependientes de la herramienta de programación.
restricción
actividad de programación comience en
Una fecha específica. Los cálculos de programación no anulan esta restricción. Por lo tanto, un
conjunto de "inicio" impuesto
las fechas tempranas para todos los caminos que conducen desde y las fechas tardías en los caminos
que conducen a la actividad.
86
74
4 4
Empezar a acabar
Manual
Formato de datos:
Comportamiento: especifica para dos actividades que la actividad sucesora no se puede finalizar
hasta que la predecesora
Se inicia la actividad.
cualquier otra
relaciones que pueden estar presentes (donde S comienza y F termina).
Definición: La relación lógica donde la finalización de la actividad del cronograma sucesor depende
tras el inicio de la actividad de programación predecesora. Ver también relación lógica .
Empezar a empezar
Opcional
Manual
Formato de datos:
Comportamiento: especifica para dos actividades que la actividad sucesora no puede iniciarse hasta
que la predecesora
Se inicia la actividad.
cualquier otra
relaciones que pueden estar presentes (donde S comienza y F termina).
Definición: La relación lógica donde depende el inicio del trabajo de la actividad del cronograma
sucesor
sobre el inicio del trabajo de la actividad de programación predecesora. Ver también relación lógica .
Resumen de actividad
Opcional
Calculado
Formato de datos:
Alfanumérico
Comportamiento: Hereda información de actividades subordinadas. Puede expresarse como una
actividad acumulada o
hamaca.
Buenas prácticas: se utiliza para trazabilidad vertical y enrollado.
Definición: Un grupo de actividades de cronograma relacionadas agregadas en algún nivel de
resumen, y mostradas /
reportado como una sola actividad en ese nivel de resumen. Ver también s ubnetwork, subproject.
Modelo de horario objetivo
Opcional
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 copia de los componentes de programación
utilizados para comparar con otros
Horario de modelos. Se puede crear un modelo de programación objetivo a partir de cualquier versión
del modelo de programación, para
ejemplo, último período de actualización.
Page 87
75
4 4
Para completar el índice de rendimiento (TCPI)
Opcional
Calculado
Formato de datos:
Número
Comportamiento: Medida del rendimiento de costos requerido para terminar el proyecto en el EAC o
el BAC indicado.
Buenas prácticas: Incluya TCPI cuando utilice la metodología del valor ganado en el cronograma.
ganado.
Definición: TCPI es el esfuerzo restante dividido por el presupuesto restante (o fondos restantes
autorizados).
TCPI
BAC
( BAC
EV
SEMEN
)
( BAC
C.A.
SEMEN
)
TCPI
EAC
( BAC
EV
SEMEN
)
( EAC
C.A.
SEMEN
)
Flotación total
Necesario
Calculado
Formato de datos:
Numérico
Comportamiento: representa la cantidad de tiempo que una actividad puede retrasar su inicio
temprano de CPM o su finalización temprana de CPM
sin afectar el CPM de finalización tardía del proyecto o violar una restricción de programación. Se
calcula como
la diferencia entre las fechas de inicio y finalización de la actividad de CPM, calculadas a partir de la
CPM hacia atrás y
Pases hacia adelante respectivamente. A medida que se registra el progreso, este valor puede
cambiar. Este valor también puede cambiar
si se revisa la lógica de trabajo restante o las duraciones
Buenas prácticas: la flotación total puede usarse para proporcionar una indicación temprana de la
finalización potencial del proyecto
deslizamiento Esto se hace restringiendo el hito de finalización del proyecto con un final en la
restricción.
Definición: La cantidad total de tiempo que una actividad programada puede retrasarse desde su
actividad CPM temprano
fecha de inicio o actividad Fecha de finalización temprana de CPM sin retrasar la fecha de finalización
tardía de CPM del proyecto o violar un
restricción de horario. Calculado usando la técnica del método de ruta crítica y restando la actividad
Fecha de finalización anticipada de CPM de la actividad Fecha de finalización tardía de CPM o
restando la actividad Fecha de inicio anticipada de CPM
desde la fecha de inicio tardío de la actividad CPM, con esa diferencia expresada en unidades de
calendario. Un valor flotante total
menos de cero indica que la fecha de retraso de CPM de la actividad está programada antes de la fecha
de inicio de CPM de actividad y
la ruta que incluye la actividad no se puede completar a tiempo para cumplir con el final tardío del
proyecto de CPM.
Un valor flotante total de cero o mayor indica que la ruta que incluye la actividad se puede completar
en
tiempo para cumplir con el CPM finalización tardía del proyecto y algunas actividades programadas
en ese camino pueden ser
retrasado. Ver también flotador libre.
Unidad de medida
Necesario
Manual
Formato de datos:
Alfanumérico
Comportamiento: proporciona unidades cuantificables para varios componentes a lo largo del
cronograma.
Buenas prácticas: las unidades de medida deben definirse de manera consistente a lo largo del
cronograma.
Definición: Una designación del tipo de cantidad que se está midiendo, como horas de trabajo, yardas
cúbicas o
líneas de código.
Page 88
76
4 4
Diferencia
Opcional
Calculado
Formato de datos:
Numérico
Comportamiento: cuantifica la salida desde un punto de referencia de fecha (como fecha de inicio,
fecha de finalización, costo, línea de base
fechas y costo, y duración).
Buenas prácticas: la variación debe revisarse para las tendencias a intervalos regulares para dar
indicaciones tempranas
de desviación y para determinar si se requiere una acción correctiva.
Definición: La diferencia entre dos atributos seleccionados expresados en unidades apropiadas como
trabajo
días o moneda.
ID de la WBS
Requerido (ERC)
Manual
Formato de datos:
Alfanumérico
Comportamiento: asigna la actividad o tarea a la estructura de desglose del trabajo del
proyecto. Define el "padre
elemento "de la actividad dentro de la WBS.
Buenas prácticas: se puede encontrar en el Estándar de prácticas para estructuras de desglose del
trabajo.
Definición: una identificación numérica o de texto única y breve asignada a cada estructura de
desglose del trabajo
(WBS) para diferenciar una WBS particular de cualquier otro elemento WBS en un programa.
Identificador del paquete de trabajo
Requerido (ERC)
Manual
Comportamiento: identifica el paquete de trabajo EVMS en los horarios.
Buenas prácticas: para la integración de costo / cronograma, incluya el identificador del paquete de
trabajo cuando use
metodología de valor en el cronograma. Un paquete de trabajo puede contener múltiples elementos
PEP. El paquete de trabajo
El identificador de una actividad contendrá un valor único que lo asigna a un único paquete de trabajo.
ganado
y el Estándar de Práctica para la Estructura de Desglose del Trabajo .
Definición: El identificador del paquete de trabajo es una designación alfanumérica de un paquete de
trabajo específico en
El EVMS.
Page 89
77
5 5
CAPÍTULO 5
ÍNDICE DE CONFORMIDAD
Este capítulo está diseñado para proporcionar una visión general del proceso del Índice de
conformidad. Este capitulo esta dividido
en las siguientes secciones:
5.1 Descripción general de conformidad
5.1.1 Categorías de componentes
5.1.2 Utilización de componentes
5.1.3 Evaluación de conformidad
5.2 Proceso de evaluación de conformidad
Cada sección proporciona un diálogo adicional sobre el contenido y la terminología de este estándar
de práctica.
5.1 Descripción general de conformidad
El índice de conformidad proporciona un medio para evaluar qué tan bien incorpora un modelo de
cronograma específico
Pautas, definiciones, comportamientos y buenas prácticas para los componentes definidos en
esta Norma de Práctica
para la programación (Capítulo 4). Si bien algunos gerentes de proyecto pueden optar por no incluir
algunos de estos núcleos
componentes requeridos (CRC), al hacerlo, el modelo de cronograma resultante no cumple con esta
práctica
estándar y puede no ser viable. La premisa básica es que a medida que aumenta el índice de
conformidad, también lo hace el
aplicación adecuada de los componentes del modelo de programación y la probabilidad de que el
modelo de programación desarrollado
representa un plan de sonido El índice también fue construido para reflejar dónde están las debilidades
de los desarrollados.
existen modelos de horarios y las áreas que más necesitan mejorar. Programación de conceptos,
comportamientos, atributos,
y se definen buenas prácticas para todos los componentes del modelo de programación. La
conformidad del modelo de programación es
evaluado evaluando la existencia y la utilización adecuada de los diversos componentes definidos en
esta práctica
estándar de acuerdo con las buenas prácticas.
5.1.1 Categorías de componentes
La lista de componentes en el Capítulo 4 identifica aquellos componentes que son:
• "requerido" en un modelo de horario
• componentes "opcionales" que pueden estar presentes pero no son necesarios
• componentes "no puntuados (NS)", que son componentes opcionales que pueden estar presentes en
un programa
modelo pero no se puntúan en el índice de conformidad
Página 90
78
CAPÍTULO 5 ÍNDICE DE CONFORMIDAD
5 5
Los componentes principales requeridos pueden definirse por cuatro grupos diferentes como se
enumeran a continuación:
• Los componentes centrales son necesarios independientemente de la complejidad del proyecto y se
conocen como el núcleo
componentes requeridos (CRC).
• Los componentes de recursos necesarios (RRC) son necesarios si los documentos del proyecto
requieren recursos
cargando.
• Los componentes de gestión del valor ganado (ERC) son necesarios si los documentos del proyecto
requieren EVM
para ser utilizado en el proyecto.
• Los componentes de riesgo requerido (KRC) son necesarios si los documentos del proyecto
requieren conceptos de riesgo para
ser considerado durante el desarrollo y mantenimiento del cronograma.
5.1.2 Utilización de componentes de programación
El uso de componentes de cronograma en un modelo de cronograma dado generalmente depende del
tamaño del proyecto, el
complejidad del proyecto, o la experiencia del planificador o equipo de gestión. Los componentes
principales (CRC) son
siempre requerido en cualquier horario, independientemente de los requisitos definidos por el proyecto
para cumplir
Con esta práctica estándar. Los otros tipos de componentes requeridos se aplican para un proyecto
específico dependiente
en los requisitos de ese proyecto. Estos requisitos están definidos por varios documentos del proyecto
y son típicamente
contenido dentro de los activos del proceso organizacional, el lenguaje del contrato del proyecto o el
plan de gestión para el proyecto, pero también puede ser cualquier otro documento escrito.
El RRC, ERC y KRC se basan condicionalmente en los requisitos del proyecto. Por ejemplo, si el
proyecto requiere
que los recursos se carguen en el proyecto y no hay otros requisitos para la gestión del valor ganado o
gestión de riesgos, entonces el total de componentes requeridos son CRC + RRC. De manera similar,
cada área requerida
se agregará al CRC cuando el proyecto lo requiera. Si se requieren recursos, riesgo y EVM, entonces
Los componentes requeridos son CRC + RRC + ERC + KRC. Como la complejidad de los requisitos
del proyecto.
aumenta, también lo hace el número total de componentes requeridos.
Los componentes requeridos deben utilizarse plenamente para lograr un nivel mínimo aceptable de
conformidad. Si los documentos del proyecto no proporcionan requisitos para el cronograma, solo el
CRC
se requieren componentes, y el RRC, ERC y KRC siguen siendo componentes opcionales para ese
proyecto. Puntuación para
el índice de conformidad se realiza de acuerdo con el Apéndice D que divide los componentes en tres
básicos
categorías: componentes requeridos centrales (CRC), componentes requeridos condicionalmente
(RRC, ERC, KRC) y opcionales
componentes.
El proceso del índice de conformidad proporciona un medio para ajustar el valor del índice cuando los
componentes opcionales
son utilizados La existencia de un componente, en sí mismo, no es suficiente para agregar al
puntaje. Uso de opcional
los componentes pueden agregarse al índice solo si estos componentes están totalmente de acuerdo
con las buenas prácticas
recomendaciones definidas en la lista de componentes en el Capítulo 4. Los componentes NS pueden
estar presentes en una programación
modelo, pero no se cuentan en el índice de conformidad según la lista de componentes del Capítulo 4.
Page 91
79
5 5
5.1.3 Evaluación de conformidad
El proceso de evaluación consta de dos partes: una para la aplicación de los componentes requeridos y
otra
evaluación para la aplicación de componentes opcionales. Estas dos partes se suman para obtener un
total
valor del índice 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 lo
requerido
los componentes deben estar presentes antes de que se pueda registrar un valor de índice de
conformidad; el específico requerido
los componentes pueden cambiar según los requisitos del proyecto. El CRC siempre estará presente
independientemente de
complejidad del alcance del proyecto.
Una vez que el modelo de cronograma ha sido evaluado para la incorporación de los componentes
requeridos apropiados,
Se pueden lograr mayores grados de conformidad mediante la utilización adecuada de los opcionales
disponibles
Programar componentes. Los componentes opcionales solo se pueden contar si se adhieren
correctamente y por completo
las definiciones, comportamientos y buenas prácticas definidas en el Capítulo 4. Los componentes
opcionales solo deben usarse
para satisfacer las necesidades de un proyecto específico, nunca solo para aumentar el valor del
índice. Como regla general, el
se esperaría encontrar el uso de componentes opcionales en organizaciones más sofisticadas o más
Modelos de horarios complejos. Programe modelos que no utilizan completamente todos los
componentes requeridos y sus
Los conceptos se consideran de naturaleza evolutiva. Los modelos de cronograma de desarrollo aún
pueden evaluarse con
un valor de índice de conformidad pero reflejado como "no cumple con los estándares mínimos de
conformidad".
El proceso de evaluación de conformidad del modelo de cronograma está diseñado para respaldar una
evaluación manual. Cuando
un componente está presente en el modelo de programación y se utiliza adecuadamente, se gana un
punto. La relación del total
cantidad de puntos (requeridos más opcionales) obtenidos en relación con la cantidad total posible de
puntos que podrían ser
otorgado representa el valor de conformidad y se expresa como un porcentaje en el continuo de 0 a
100.
La excepción a esta regla involucra los componentes requeridos. Como se indicó anteriormente, si los
componentes requeridos,
según lo definido por los requisitos del proyecto, no se utilizan completamente (100% empleados),
entonces el modelo de calendario sí
No cumple con la conformidad mínima con este estándar de práctica. Si se alcanza este umbral
mínimo, entonces
el valor de la relación se representa en la escala continua o deslizante, siendo (35) el más bajo y (100)
el
más alto (ver Tabla 51). El valor más bajo (35) representa la relación que vendría de solo el requerido
componentes (CCR), todos los cuales son necesarios en cada modelo de programación.
Si el evaluador determina que no se han cumplido los estándares mínimos de conformidad, el
evaluador puede
terminar el proceso de evaluación o continuar la evaluación para fines de necesidades de desarrollo y
para
ayudar a la organización a identificar áreas específicas que requieren mejoras. En este caso,
independientemente de la
número máximo de puntos anotados, el valor de evaluación del modelo de cronograma no se registrará
en el continuo
porque no cumple con los estándares mínimos de conformidad.
5.2 Proceso de evaluación de conformidad
El Apéndice D contiene una lista de los componentes del cronograma organizados en componentes
básicos requeridos (CRC),
componentes requeridos condicionalmente (RRC, ERC, KRC) y componentes opcionales. La tabla 5
1 refleja el máximo
número de componentes por categoría, así como el número total máximo de componentes que se
puede puntuar. El NS
Página 92
80
5 5
los componentes no están incluidos en esta tabla, por lo que el número total de componentes
disponibles no es igual al total
número de componentes definidos en el Capítulo 4. Utilizando la lista en el Apéndice D, el evaluador
determinará si cada uno
El componente requerido está presente en el modelo de cronograma que se analiza. El planificador
debe entender completamente
Las buenas prácticas asociadas con los diversos componentes requeridos y opcionales.
Para comenzar el proceso de evaluación, el evaluador primero determinará la respuesta a las siguientes
preguntas:
• ¿Existe algún requisito para la carga de recursos?
• ¿Existe algún requisito para utilizar EVM?
• ¿Existe algún requisito para utilizar la gestión de riesgos basada en el cronograma?
• Si la respuesta a alguna de las preguntas es sí, entonces los componentes del cronograma requeridos
para ese grupo
será necesario 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:
• Si se requiere la carga de recursos, se requiere el RRC y el nivel mínimo requerido
componentes es CRC + RRC.
• Si se requiere EVM, el ERC se vuelve necesario, y el nivel mínimo de componentes requeridos es
CRC
+ ERC.
• Si se requiere gestión de riesgos, se requiere el KRC y el nivel mínimo requerido
componentes es CRC + KRC.
• Si se requieren carga de recursos y EVM, el nivel mínimo de componentes requeridos es
CRC + RRC + ERC.
• Si 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 lograr para el pleno cumplimiento
de los requisitos
los componentes pueden variar entre CRC y CRC más la suma de componentes adicionales requeridos
por RRC / ERC /
KRC. Este valor comprende la primera parte del proceso de evaluación llamado "valor de los
componentes requeridos".
Tabla 51. Número de componentes por categoría
Necesario
CRC
36
CRR
11
Condicional
ERC
9 9
KRC
7 7
Opcional
Opcional
40
Total
Disponible
103
Página 93
81
5 5
La parte restante del puntaje de evaluación se compone de todos los componentes "opcionales"
disponibles. por
Por ejemplo, si no se requieren componentes de KRC, todos los componentes de riesgo se consideran
opcionales. Una vez el
los componentes requeridos se contabilizan para todos los componentes restantes están representados
por el "opcional
valor de los componentes ". El evaluador revisará los componentes opcionales restantes y, si están
presentes y
utilizado adecuadamente, otorgará los puntos como se indica.
Cada componente opcional también tiene un valor de uno. El evaluador determina un puntaje bruto al
sumar todos
puntos ganados de los componentes requeridos y los componentes opcionales. Si todos los puntos
asociados con
el "valor de los componentes requeridos" no se obtiene, entonces no se puede registrar un puntaje
bruto final, sin embargo, el
el puntaje bruto se puede compartir con el proyecto para que puedan comprender sus áreas de
mejora. Finalmente, lo crudo
el puntaje se divide por el puntaje máximo total posible para obtener el índice de conformidad. El
valor resultante es
expresado como un porcentaje, y representa la puntuación del índice de conformidad para el modelo
de programación.
La intención básica de evaluar la conformidad de un modelo de programación con este estándar de
práctica y su implicación
se ha alcanzado la madurez y el asesor ha determinado dónde se ubica un modelo de cronograma dado
La evaluación continua. El programador puede determinar acciones específicas para avanzar más
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 E contiene una hoja de puntuación en blanco y algunos ejemplos.
Page 94
Page 95
83
Referencias
[1] Instituto de Gestión de Proyectos. 2008. Una guía para el cuerpo de conocimiento de gestión de
proyectos
( Guía PMBOK ® ) — Cuarta edición. Newtown Square, PA: Autor.
[2] Instituto de Gestión de Proyectos. 2007. Práctica estándar para la programación. Newtown
Square, PA: Autor
[3] Instituto de Gestión de Proyectos. 2006. Estándar de práctica para estructuras de desglose del
trabajo: segunda edición.
Newtown Square, PA: Autor.
[4] Instituto de Gestión de Proyectos. 2005. Norma de práctica para la gestión del valor
ganado . Newtown Square,
PA: Autor.
[5] Instituto de Gestión de Proyectos. 2011. Estándar de práctica para la estimación de
proyectos. Newtown Square, PA: Autor.
[6] Instituto de Gestión de Proyectos. 2009. Norma de práctica para la gestión de riesgos de
proyectos . Newtown Square,
PA: Autor.
[7] Instituto de Gestión de Proyectos. 2007. Práctica estándar para la gestión de la
configuración. Newtown Square,
PA: Autor.
[8] Instituto de Gestión de Proyectos. 2008. Modelo de madurez de gestión de proyectos
organizacionales (OPM3) Segundo
Edición. Newtown Square, PA: Autor.
Page 96
Page 97
85
UNA
APÉNDICE A
DIRECTRICES PARA UN INSTITUTO DE GESTIÓN
DE PROYECTOS
NORMA DE PRÁCTICA
A.1 Introducción
Un estándar de práctica de PMI se caracteriza de la siguiente manera:
• Cada estándar de práctica proporciona pautas sobre la mecánica (por ejemplo, tuercas y tornillos,
conceptos básicos,
fundamentos, guía de uso paso a paso, cómo funciona, cómo hacerlo) de algún proceso significativo
(entrada, herramienta, técnica o salida) que es relevante para un gerente de proyecto.
• Un estándar de práctica no necesariamente refleja las fases del ciclo de vida de muchos
proyectos. Pero,
un estándar de práctica individual puede ser aplicable a la finalización de una o más fases dentro de
un proyecto.
• Un estándar de práctica no necesariamente refleja las áreas de conocimiento dentro de una guía para
el proyecto
Cuerpo de conocimiento de gestión ( Guía PMBOK ® ) , aunque un estándar de práctica individual
proporcionar detalles y antecedentes suficientes para una o más de las entradas, herramientas y
técnicas, y / o
salidas. Por lo tanto, no se requieren estándares de práctica para usar el nombre de ningún Área de
Conocimiento.
• Cada estándar de práctica debe incluir información sobre lo que es y hace el proceso significativo,
por qué es importante, cómo realizarlo, cuándo debe realizarse y, si es necesario, para más
aclaración, quién debe realizarlo.
• Cada estándar de práctica debe incluir información que sea aceptada y aplicable para la mayoría de
los proyectos
la mayor parte del tiempo dentro de la comunidad de gestión de proyectos. Procesos que generalmente
están restringidos
o aplicable a una industria, país o profesión complementaria (es decir, un área de aplicación) puede ser
incluido como un apéndice con fines informativos, en lugar de ser parte del estándar de práctica. Con
fuerte respaldo y evidencia, un proceso específico del área de aplicación puede considerarse como
una extensión
práctica estándar, de la misma manera que se consideran las extensiones de la Guía PMBOK ® .
• Cada estándar de práctica se beneficiará de la inclusión de ejemplos y plantillas. Es mejor cuando
un ejemplo o plantilla incluye una discusión de sus fortalezas y debilidades. Un fondo
La descripción puede ser necesaria para poner esta discusión en el contexto apropiado. Los ejemplos
deberían
estar alineado con la información relevante en el estándar o su apéndice y ubicado cerca de
Esa información.
• Todos los estándares de práctica se escribirán en el mismo estilo y formato general.
• Cada proyecto estándar de práctica evaluará la necesidad de alinearse o hacer referencia a otros
estándares de práctica.
• Cada estándar de práctica será consistente con la Guía PMBOK ® .
• Cada estándar de práctica pretende ser más prescriptivo que la Guía PMBOK ® .
98
Page 99
87
segundo
APÉNDICE B
EVOLUCIÓN DEL ESTÁNDAR DE PRÁCTICAS DE
PMI PARA LA PROGRAMACIÓN
B.1 PreProyecto
El Estándar de práctica para la programación se publicó inicialmente en 2007. En julio de 2009, el
mercado PMI
El Departamento de Desarrollo realizó una Encuesta de Necesidades de Actualización para el estándar
de práctica, que es la preparación
paso para alquilar una actualización de cualquier estándar. En octubre de 2009, el PMI Standards
Manager y los Estándares
El Grupo Asesor de Miembros desarrolló una carta inicial para la actualización de la norma. Una
versión final de la Carta
se firmó en enero de 2010. Según el estatuto, el comité debía revisar, investigar, validar la necesidad y
identifique todos los cambios necesarios para actualizar el Estándar de práctica para la
programación como un estándar de segunda edición.
Actividades específicas incluidas:
• Consideración de todos los comentarios y opiniones relevantes para el Estándar de Práctica para la
Programación que
han sido recibidos por PMI desde su publicación
• Consideración de todos los comentarios, sugerencias y comentarios sobre borradores de exposición
diferidos, incluyendo cualquier
apelaciones y su resolución, con la asistencia del personal de PMI
• Consideración de cualquier información e información de investigación de mercado de PMI
disponible.
• Consideración de cualquier información e información disponible.
• Consideración de iniciar una investigación ad hoc para resolver problemas
• Consideración de consultas con expertos en la materia.
• Consideración de impactos desde y hacia otros productos estándar.
• Implemente el cambio de sintaxis al formato de estándares PMI, es decir, nombreverbo para
nombres de procesos
• Consideración de recomendación para cambios, para ningún cambio (reafirmación), o para retirar el
estándar
• Asamblea de las conclusiones y recomendaciones resumidas del Comité en un informe exhaustivo
para
el gerente de normas
En enero de 2010, el comité se formó bajo el liderazgo de Harold "Mike" Mosley, Jr., PMP,
Presidente,
y Charles Follin, PMP, Vicepresidente.
Página 100
88
APÉNDICE B
segundo
B.2 Trabajo preliminar
Con la formación del comité, PMI proporcionó una lista de voluntarios. Se desarrolló una matriz para
hacer
todos los esfuerzos para abordar las calificaciones y la distribución geográfica de los miembros del
comité. Un conjunto de
Se realizaron entrevistas para evaluar el rango de voluntarios, incluso para determinar si tenían alguna
agendas que perseguían a través de esta oportunidad. Se determinó que un comité de ocho miembros
era
óptimo y se lograron las siguientes métricas:
B.2.1 Calificaciones:
• Ocho PMP
• Cinco PMPSP
• Un PMIRMP
B.2.2 Geográfico:
• Cinco – Norteamérica (cuatro estados, de costa a costa)
• One – EMEA (Lituania)
• Dos: Asia Pacífico (Israel e India)
• Dos: América Latina (Curazao y Brasil)
Nota: Esto suma más de ocho, ya que hubo movimiento de los miembros durante el curso del
esfuerzo.
B.2.3 Mercado:
• Five – Consulting (construcción, tecnología, programa)
• Uno: construcción
• Uno – Finanzas / Automotriz
• Uno: TI / Software
B.2.4 Aplicaciones:
• Artemisa
• La mejor hora
• Maximo
• MicroPlanner
• Proyecto de MS Office
• Plan abierto profesional
Page 101
89
APÉNDICE B
segundo
• Oracle P6
• PERTmaster
• desfile
• Primavera Project Planner (P3)
• Proyecto dos
• PSNext
• Riesgo +
• Proyecto arriesgado
• SureTrak
• @Task
Esta composición proporcionó un equipo muy diverso, optimizando la perspectiva en el desarrollo, el
aplicabilidad en la implementación y la traducibilidad del estándar completado. En febrero de 2010, el
equipo
tuvo su oportunidad inicial de participar en el esfuerzo. Dirigido por Mike Mosley (Presidente) y
Charlie Follin (Vicepresidente),
el comité incluyó a Jim Aksel, Bridget Fleming, Hagit Landman, Sanjay Mandhan, Fernando Oliveira,
Raul
Romer y Elaine Lazar (Especialista en estándares de PMI).
Los esfuerzos iniciales incluyeron la consulta con varios expertos en la materia en busca de aportes
sobre qué áreas
Debía abordarse en la actualización de esta Norma de práctica para la programación . Esta
retroalimentación condujo a la expansión
del estándar para una mejor inclusión de técnicas de valor ganado, aplicación de recursos y gestión de
riesgos.
El comité también estableció un enlace con otras normas en desarrollo concurrente o casi concurrente.
Estos incluyeron el Estándar de Práctica para la Gestión del Valor Ganado 2ª Edición, El Estándar de
Práctica para
Estimación de proyectos, la guía PMBOK ® , quinta edición, y el Comité Léxico. Además, hubo un
enfoque para comprender y luchar por la armonía entre el Estándar de práctica para la programación y
otros publicados
estándares, como el Estándar de práctica para la gestión de riesgos de proyectos y
el PMBOK ® obligatorio
Guía — Cuarta edición. Este esfuerzo también incluyó la revisión y consideración de la especificación
del examen para
Examen PMISP.
Los esfuerzos de desarrollo del comité se desarrollaron de febrero a agosto de 2010. Durante este
período hubo
fueron tres reuniones cara a cara donde se logró un gran progreso a través del "diálogo dinámico", con
cada
La pasión de la persona se expresa en el esfuerzo por aprender y, en última instancia, alcanzar un
consenso sobre un enfoque de equipo.
Una de estas reuniones fue coordinada para estar en conjunto con la Sexta Anual del Colegio de
Programación de PMI
Conferencia, donde se realizó una sesión como una sesión de trabajo abierta de pseudo
estándares. Miembros del comité
también presentado en la Conferencia de Trabajo de la Sociedad Americana de Energía Nuclear, y en
el Congreso Mundial de PMI
América del Norte 2010. Mike Mosley también continuó su papel de enlace con el Colegio de
Programación de PMI (ahora
la Comunidad de práctica de programación), informando a la Junta y publicando actualizaciones en el
sitio web de la comunidad.
Junto con el foro del sitio web del Colegio, varios lugares nuevos participaron en la colaboración y
discusión
del estándar, incluidos los sitios de redes sociales.
Page 102
90
APÉNDICE B
segundo
Probablemente hay dos problemas que parecen seguir generando comentarios:
• Desde que se introdujo el término "modelo de programación" en la Guía PMBOK ®, tercera edición,
existe
ha sido un diálogo sobre la necesidad de un nuevo término. Después del diálogo dinámico interno y
externo,
el comité aún está de acuerdo con la necesidad de términos que sean específicos de lo que se solicita.
En uso común, un cronograma es todo, desde una lista de fechas hasta un modelo matemático que
puede
replicar la ejecución planificada de un proyecto. Los términos utilizados en la norma proporcionan un
propietario,
miembro del equipo o planificador la oportunidad de ser específico en cuanto a las necesidades y
expectativas.
• La definición de "crítico" también ha estimulado la conversación, principalmente en relación con su
uso tradicional,
solo considerando el camino más largo a través de un proyecto y sus componentes. Con el uso de
restricciones, calendarios múltiples y subproyectos múltiples en la mayoría de los proyectos, es muy
común que
tener múltiples rutas críticas basadas en el gerente / subproyecto, área u obligaciones contractuales.
El estándar de práctica para la programación: la segunda edición ofrece a la comunidad un alcance
más amplio, mayor
claridad y un nivel aún más alto de consenso. La lista de componentes ofreció los bloques de
construcción que apoyan
crear un modelo de cronograma, buenas prácticas para su uso y un medio para evaluar la madurez del
cronograma
modelo contra las necesidades del proyecto.
B.3 Exposición y consenso
Esta norma de práctica se presentó como borrador de exposición a fines del otoño de 2010. Hubo 867
comentarios.
La tasa de aceptación de comentarios del equipo (comentarios aceptados directamente o aceptados con
modificaciones) fue de un
casi récord de 85.6%. Solo el 0.6% (seis de 867) de los comentarios fueron diferidos para una edición
futura y solo
3% fueron rechazados. Los comentarios relacionados con el formato o la puntuación se remitieron al
editor de PMI
para la interpretación de la guía de estilo.
Page 103
91 91
do
APÉNDICE C
COLABORADORES Y REVISORES DEL ESTÁNDAR
DE PRÁCTICAS
PARA PROGRAMAR: SEGUNDA EDICIÓN
Este apéndice enumera, alfabéticamente dentro de las agrupaciones, aquellas personas que han
contribuido a la
Desarrollo y producción del Estándar de Práctica para la Programación Segunda Edición.
El Project Management Institute agradece a todas estas personas por su apoyo y agradece
sus contribuciones a la profesión de gestión de proyectos.
C.1 Comité central
Los siguientes individuos sirvieron como miembros, contribuyeron con textos o conceptos, y sirvieron
como líderes
en el Comité:
Harold "Mike" Mosley, Jr., PMP, PE, Presidente
Charles T. Follin, PMP, Vicepresidente
M. Elaine Lazar, MA, MA, AStd, Especialista en Proyectos de Normas PMI
James E. Aksel, PMP, PMISP
Bridget Fleming, PMP, PMISP
Hagit Landman, PMP, PMISP, MBA
Sanjay Mandhan, MBA, PMP
Fernando Nunes de Oliveira, PMP, PMISP, PMIRMP
Raul A. Römer, Ing., PMP, PMISP
C.2 Contribuyentes significativos
Contribuyentes significativos apoyaron actividades clave para la actualización de este estándar de
práctica, incluida la edición
y participación del equipo secundario en los esfuerzos del proyecto, como contenido, autoría, calidad,
comunicaciones e investigación.
Subequipos. Los contribuyentes importantes del proyecto de actualización ofrecieron profundidad de
conocimiento y comprensión como materia
expertos en la materia (PYME) en sus campos de práctica. Además de los miembros del equipo
central del proyecto, el
Las siguientes personas proporcionaron apoyo, aportes o conceptos significativos:
Doug Clark
Marie Gunnerson
Tammo Wilkins
David T. Hulett, PhD
Página 104
92
APÉNDICE C
do
C.3 Exposición de revisores y contribuyentes
Además de los miembros del equipo, las siguientes personas proporcionaron recomendaciones para
mejorar la práctica
Estándar para la programación Segunda edición:
Marcos Abreu
Mohammad Abu Irshaid
Puneet Agrawal
Imran Ahmed
James Aksel
Jose Alcala
Eric Amo
Balamurugan Ananthan
Ondiappan Arivazhagan
Sai Prasad Baba Subramanyan
Stephen Bonk
John Buxton
Kameswaran Chandrasekaran
Supriyo Chatterji
Cynthia Datte
Kian Ghadaksaz
David Giguere
Peter Gilliland
Behnam Goudarzi
Roy Greenia
Nitu Gupta
Miklos Hajdu
George Haney
Ahmed Hasan
Sheriff Hashem
Lee Hindsman
Shirley Hinton
Abdelkader Ibrahim
Mohamed Ishaq
Ashok Jain
Jacob Jerome
Ashish Joshi
Chandrashekhar Joshi
Carl Karshagen
Ramakrishna Kavirayani
Edward Kleinert
Anuj Kulkarni
Marina Link
Bruce Lofland
Jose Machicao
Ramesh Maddali
Mohit Mathur
Amith Mikkilineni
Samit Misra
Shamik Mondal
Balu Muthusamy
Eric Myers
Harishchandra Nayak
Shashank Neppalli
Mohammad Ali Niroomand Rad
Sunil Omanakuttan
Venkateswar Oruganti
Vincent Osbourn
Boopathy Sankar PS
Madhuyukta Pandey
Balau Pasupathy
Valikulangara Pradeepkumar
Ananthakrishnan Ramaswami
Bhaskar Ravivarma
Bhavanam Reddy
Michael Reed
Sadegh Roozbehi
Himadri Roy
Sameer Siddhanti
Gurpreet Singh
Justin Smith
Manish Srivastava
Goparaju Sudhakar
Mark Swiderski
Seyedsoroush Tabatabaei
Page 105
93
APÉNDICE C
do
Biagio Tramontana
Eric Uyttewaal
Vijay Vemana
David Violette
Atin Wadehra
Patrick Weaver
Kevin Wegryn
Alexandra ZouncouridesLull
C.4 Otros contribuyentes
Mark Groff
Gwen Barger
Peter Ripley
Jeff Goodman
C.5 Grupo Asesor de Miembros del Programa de Normas PMI
(MAG)
Las siguientes personas sirvieron como miembros del Grupo Asesor de Miembros del Programa de
Normas de PMI durante
Desarrollo del Estándar de Práctica para la Programación Segunda Edición:
Monique Aubry, PhD, MPM
Margareth FS Carneiro, MSc, PMP
Chris Cartwright, MPM, PMP
Terry CookeDavies, PhD, BA, FAPM, FCMI, FRSA, PMP
Laurence Goldsmith, PMP
David W. Ross, PMP, PgMP
Paul E. Shaltry, PMP
John Zlockie, MBA, PMP, Gerente de Estándares
C.6 Personal de producción
Mención especial se debe a los siguientes empleados de PMI:
Donn Greenberg, Gerente de Publicaciones
Roberta Storer, Editora de Producto
Barbara Walsh, CAPM, Supervisora de Producción de Publicaciones
Quynh Woodward, MBA, Especialista en Cumplimiento de Normas
Page 106
Page 107
95
re
A PÉNDICE D
TABLA DE PUNTUACIÓN DE EVALUACIÓN DE
CONFORMIDAD
La Tabla D1 proporciona 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. Los
componentes son
arreglado en la tabla de acuerdo con el momento en que el componente podría usarse de acuerdo con
el programa típico
evoluciones de modelos; Predesarrollo, Desarrollo y Mantenimiento. Esta tabla también proporciona
la base para
recuento oficial de cada categoría de componentes que se utiliza en la hoja de trabajo de evaluación,
que se muestra en el Apéndice E.
El componente aparece en la primera columna a la izquierda de la tabla. Las siguientes cinco
columnas muestran qué
categoría en la que cae el componente; componentes básicos necesarios (CRC), componentes de
recursos condicionales (RRC),
componentes condicionales de EVM (ERC), componentes de riesgo condicionales (KRC) o
componentes opcionales (OPT). los
La última línea de la tabla refleja un resumen de cada tipo de categoría con un valor total para los
componentes. Éste último
la 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 disponible
puntos en cada categoría.
Tabla D1. Tabla de puntuación de evaluación de conformidad de muestra
Componente
CRC
CRR
ERC
KRC
OPT Comentarios
ID de la WBS
R
ID de actividad
R
Nombre del proyecto
R
Programar ID de modelo
R
Programar versión del modelo
R
Calendario de actividades
O
Calendario del proyecto
R
Calendario de recursos
R
Fecha de Datos
R
Hitos
R
Retraso
O
Modelo de cronograma de referencia
R
Modelo de horario objetivo
O
108
96
APÉNDICE D
re
Componente
CRC
CRR
ERC
KRC
OPT Comentarios
Restricción de inicio de proyecto
O
Etiqueta de actividad
R
Unidad de medida
R
Actividad Duración original
R
Actividad restante
Duración
R
Duración real de la actividad
R
Duración total de la actividad
R
Proyecto restante
Duración
R
Duración real del proyecto
R
Duración total del proyecto
R
Esfuerzo de actividad / trabajo
O
Actividad Porcentaje de trabajo
Completar
O
R
Empezar a empezar
O
Finish to Finish
O
Fecha de inicio temprano de la actividad
R
Actividad Fecha de inicio tardío
R
Fecha de inicio real de la actividad
R
Recurso de actividad nivelado
Fecha de inicio
O
Fecha de inicio temprano del proyecto
R
Fecha de inicio tardío del proyecto
R
Fecha de inicio real del proyecto
R
Proyecto de recursos nivelado
Fecha de inicio
O
Actividad Fecha de finalización temprana
R
Actividad Fecha de finalización tardía
R
Fecha de finalización real de la actividad
R
Recurso de actividad nivelado
Fecha de finalización
O
Fecha de finalización temprana del proyecto
R
Proyecto Fecha de finalización tardía
R
Fecha de finalización real del proyecto
R
Tabla D1. Ejemplo de tabla de puntuación de evaluación de conformidad (continuación)
Page 109
97
APÉNDICE D
re
Componente
CRC
CRR
ERC
KRC
OPT Comentarios
Proyecto de recursos nivelado
Fecha de finalización
O
Flotación total
R
Flotador Libre
R
Camino critico
R
Actividad Porcentaje Físico
Completar
R
El porcentaje de actividad completado debe ser
duración física o física: se requiere UNA
Actividad Duración Porcentaje
Completar
Proyecto Porcentaje Físico
Completar
R
Porcentaje de duración del proyecto
Completar
Código de actividad
O
Categoría de costo de actividad
O
Estimación de costo de actividad
O
Recurso de actividad real
Cantidad
R
Total de recursos de actividad
Cantidad
R
Proyecto Recurso Actual
Cantidad
R
Proyecto Total de recursos
Cantidad
R
Definición del alcance de la actividad
O
Terminar a más tardar
O
Restricción de finalización del proyecto
O
Campo personalizado
O
Valor agregado
R
Valor planificado
R
Costo real de la actividad (AC)
R
Índice de rendimiento de costos
(IPC)
O
Rendimiento programado
índice (SPI)
O
Para completar el rendimiento
Índice (TCPI)
O
Page 110
98
APÉNDICE D
re
Componente
CRC
CRR
ERC
KRC
OPT Comentarios
Variación de programación (SV)
O
Programar varianza%
O
Variación de costo (CV)
O
Variación de costo %
O
Método del valor ganado
O
Valor Ganado Peso
O
Identificador del paquete de trabajo
R
ID de cuenta de control
R
Gerente de cuentas de control
O
Estimación al finalizar
(EAC)
R
Presupuesto al finalizar
(BAC)
R
Estimación para completar
(ETC)
R
Identificador de solicitud de cambio
O
Nivel de cronograma del proyecto
O
Cronograma del proyecto
Presentación
R
Categoría de costo del proyecto
O
Descripción del Proyecto
O
Gerente de proyecto
O
Asignación de recursos
R
Disponibilidad de recursos
R
Descripción del recurso
R
Recursos de conducción
O
ID de recurso
R
Retraso de recursos
O
Nivelación de recursos
O
Biblioteca de recursos /
Diccionario
R
Tasas de recursos / precios
O
Tipo de recurso
R
Actividad Riesgo Crítico
Índice
R
ID de riesgo
R
Página 111
99
APÉNDICE D
re
Componente
CRC
CRR
ERC
KRC
OPT Comentarios
Actividad más probable
Duración
R
Actividad optimista
Duración
R
Actividad pesimista
Duración
R
Actividad acumulativa
Riesgo de probabilidad
Distribución
R
Riesgo de probabilidad
Distribución
R
Resumen de actividad
O
Diferencia
O
Número de componentes en
Categoría
36
11
9 9
7 7
40
Los artículos NS no se cuentan en OPT
103
112
113
101
APÉNDICE E
mi
A PÉNDICE E
HOJAS DE TRABAJO DE EVALUACIÓN DE
CONFORMIDAD
El Apéndice E proporciona varias hojas de trabajo de evaluación. Cada hoja de trabajo se explica con
mayor detalle.
abajo. Los valores utilizados para los recuentos totales en cada categoría de componentes se toman
directamente del Apéndice D.
La Figura E1 refleja los valores potencialmente disponibles para cada categoría completada. Tenga
en cuenta que el condicional
las categorías de componentes se enumeran en ambas secciones en este punto, ya que aún no se ha
determinado si son
requerido para el proyecto dado. La hoja base también refleja el valor requerido para los componentes
principales, el
valores opcionales disponibles y en la parte inferior de la página se muestra el total de puntos
disponibles. Esta hoja base puede
ser reproducido y marcado manualmente para cualquier evaluación.
La Figura E2 refleja una hoja de trabajo completa para un proyecto que solo requirió la carga de
recursos además de la
componentes básicos y refleja la presencia de algunos componentes opcionales también. El ejemplo
refleja
un puntaje de evaluación de 55.
La Figura E3 refleja una hoja de trabajo completa para un proyecto que requiere carga de recursos,
EVM y riesgo
gestión además de los componentes básicos de base y refleja la presencia de algunos componentes
opcionales
también. El ejemplo refleja un puntaje de evaluación de 70.
La Figura E4 refleja una hoja de trabajo completa para un proyecto que requirió la carga de recursos
y la gestión de riesgos
Además de los componentes del núcleo base y refleja la presencia de algunos componentes opcionales
también. los
el ejemplo refleja un puntaje de evaluación de 90. Tenga en cuenta que algunos de los componentes
opcionales calificados son EVM
componentes, pero como no eran necesarios en este proyecto, están en la categoría opcional.
La Figura E5 refleja una hoja de trabajo completa para un proyecto que requirió la carga de recursos
y la gestión de riesgos
Además de los componentes básicos y refleja la presencia de algunos componentes opcionales,
incluidos todos los componentes de EVM. Sin embargo, notará que esta evaluación no tiene puntaje,
porque no
Todos los componentes requeridos están presentes. 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 deberá calificar
grabado. Tenga en cuenta que aún puede ver los puntos ganados versus los disponibles en las áreas
requeridas y opcionales, pero no
Se registra el valor del índice de conformidad.
El Apéndice E fue desarrollado para proporcionar al usuario ejemplos para una mejor comprensión de
cómo
El proceso de evaluación funciona.
114
102
APÉNDICE E
mi
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 algún requisito para utilizar la gestión de riesgos?
Las respuestas a las preguntas anteriores determinarán los valores de los puntos disponibles para que los componentes requeridos y
opcionales sean
colocado en los campos de abajo. El CRC siempre se requiere, por lo que los valores adicionales requeridos de la tabla 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
valor opcional El total disponible siempre será igual al valor de 103.
Necesario
Condicional
Opcional
Total
CRC
CRR
ERC
KRC
Opcional
Disponible
36
11
9 9
7 7
40
103
HOJA DE TRABAJO DE EVALUACIÓN DE HORARIOS
Figura E1. Hoja de trabajo base
Potencial disponible
Necesario
GANADO
Componentes básicos requeridos (CRC)
36
36
Puntos requeridos
Componentes necesarios de recursos (RRC)
11
Componentes requeridos de EVM (ERC)
9 9
Puntos ganados
Componentes de riesgo requerido (KRC)
7 7
Total de componentes requeridos
Puntuación de componentes requeridos
Potencial Disponible Disponible Opcional GANADO
Componentes opcionales
40
40
Puntos disponibles
Componentes necesarios de recursos
11
Componentes requeridos de EVM
9 9
Puntos ganados
Componentes de riesgo requerido
7 7
Componentes opcionales totales
Puntuación de componentes opcionales
Este cuadro solo se completa si TODOS los puntos necesarios se obtienen
Total de puntos disponibles
103
Total
Total de Ganancias
Puntos totales
103
Valor de índice de conformidad sin procesar
Multiplicar por 100
100
Índice de conformidad
Puntaje total
115 de 1189.
103
APÉNDICE E
mi
Sí
No
X
X
X
opcionales sean
agregarán al CRC
Necesario
Condicional
Opcional
Total
CRC
CRR
ERC
KRC
Opcional
Disponible
36
11
9 9
7 7
40
103
Figura E2. Hoja de trabajo de ejemplo de recursos necesarios
Necesario
GANADO
36
36
36
Puntos requeridos 47
11
11
11
9 9
0 0
Puntos ganados
47
7 7
0 0
47
47
40
40
5 5
Puntos disponibles 56
11
0 0
9 9
9 9
5 5
Puntos ganados 10
7 7
7 7
56
10
47
103
10
Total
57
Total de Ganancias
57
Puntos totales
103
0,55
Multiplicar por 100
100
55
Puntaje total
Page 116
104
APÉNDICE E
mi
Sí
No
X
X
X
opcionales sean
agregarán al CRC
Necesario
Condicional
Opcional
Total
CRC
CRR
ERC
KRC
Opcional
Disponible
36
11
9 9
7 7
40
103
Figura E3. Hoja de trabajo de ejemplo de recursos, EVM y riesgo requerido
Necesario
GANADO
36
36
36
11
11
11
9 9
9 9
9 9
Puntos ganados
63
7 7
7 7
7 7
63
63
40
40
9 9
11
0 0
9 9
0 0
Puntos ganados
9 9
7 7
0 0
40
9 9
63
103
9 9
Total
72
Total de Ganancias
72
Puntos totales
103
0,70
Multiplicar por 100
100
70
Puntaje total
Página 117
105
APÉNDICE E
mi
Sí
No
X
X
X
opcionales sean
agregarán al CRC
Necesario
Condicional
Opcional
Total
CRC
CRR
ERC
KRC
Opcional
Disponible
36
11
9 9
7 7
40
103
Figura E4. Recurso y hoja de trabajo de ejemplo de riesgo requerido
Necesario
GANADO
36
36
36
11
11
11
9 9
0 0
Puntos ganados
54
7 7
7 7
7 7
54
54
40
40
30
11
0 0
9 9
9 9
9 9
Puntos ganados 39
7 7
0 0
54
54
54
103
39
Total
93
Total de Ganancias
93
Puntos totales
103
0,90
Multiplicar por 100
100
90
Puntaje total
mi
118
106
APÉNDICE E
mi
NOTA EN ESTE EJEMPLO LOS COMPONENTES MÍNIMOS REQUERIDOS NO ESTÁN TODOS
PRESENTES
Sí
No
X
X
X
opcionales sean
agregarán al CRC
Necesario
Condicional
Opcional
Total
CRC
CRR
ERC
KRC
Opcional
Disponible
36
11
9 9
7 7
40
103
Figura E5. Hoja de trabajo de ejemplo sin puntaje
Necesario
GANADO
36
36
33
11
11
7 7
9 9
0 0
Puntos ganados
47
7 7
7 7
7 7
54
47
40
40
25
11
0 0
9 9
9 9
9 9
Puntos ganados
34
7 7
0 0
49
34
103
Total
Total de Ganancias
81
Puntos totales
103
Multiplicar por 100
100
Puntaje total
Page 119
107
GLOSARIO
GLOSARIO
Muchas de las palabras definidas aquí tienen definiciones de diccionario más amplias y, en algunos
casos, diferentes.
Las definiciones utilizan las siguientes convenciones:
• Los términos utilizados como parte de las definiciones y que se definen en el glosario se muestran
en cursiva .
• Cuando el mismo término del glosario aparece más de una vez en una definición dada, solo el
primero
ocurrencia está en cursiva.
• En algunos casos, un solo término del glosario consta de varias palabras (por ejemplo, cuenta de
control).
• Cuando se incluyen sinónimos, no se da ninguna definición y el lector se dirige al término preferido
(es decir, ver término preferido).
• Los términos relacionados que no son sinónimos tienen referencias cruzadas al final de la definición
(es decir, ver también
término relacionado).
Acrónimos y términos comunes
Acrónimo
Término
C.A.
Costo real
U SE Costo real (CA) ( Guía PMBOK ® — Cuarta edición)
ANUNCIO
Descripción de la actividad
Descripción de la actividad U SE (AD) ( Guía PMBOK ® — Cuarta edición)
ADM
Método de diagrama de flechas
U SE Método de diagrama de flechas (ADM) ( Guía PMBOK ® Cuarta edición)
AF
Fecha de finalización real
U SE Fecha de finalización real (AF) ( Guía PMBOK ® Cuarta edición)
AOA
ActivityonArrow ( Guía PMBOK ® — Cuarta edición)
AON
ActivityonNode ( Guía PMBOK ® — Cuarta edición)
COMO
Fecha de inicio real
U SE Fecha de inicio real (AS) ( Guía PMBOK ® Cuarta edición)
California
Control de cuenta
Cuenta de control U SE (CA) ( Guía PMBOK ® Cuarta edición)
CPM
Método del camino crítico
U SE Método de ruta crítica (CPM) ( Guía PMBOK ® Cuarta edición)
120
108
GLOSARIO
DD
Fecha de Datos
Fecha de datos U SE (DD) ( Guía PMBOK ® Cuarta edición)
DU
Duración
Duración U SE (DU o DUR) ( Guía PMBOK ® Cuarta edición)
DUR
Duración
Duración U SE (DU o DUR) ( Guía PMBOK ® Cuarta edición)
EAC
Estimación al finalizar
Estimación U SE al finalizar (EAC) ( Guía PMBOK ® Cuarta edición)
EF
Fecha de finalización temprana
U SE Fecha de finalización temprana (EF) ( Guía PMBOK ® Cuarta edición)
ES
Fecha de inicio temprano
U SE Fecha de inicio temprano (ES) ( Guía PMBOK ® — Cuarta edición)
ETC
Estimación para completar
U SE Estimate to Complete (ETC) ( Guía PMBOK ® — Cuarta edición)
EV
Valor agregado
U SE Valor Ganado (EV) ( Guía PMBOK ® — Cuarta edición)
EVM
Gestion del valor ganado
U SE Gestión del valor acumulado (EVM) ( Guía PMBOK ® Cuarta edición)
EVT
Técnica de valor ganado
Técnica de valor acumulado de U SE (EVT) ( Guía PMBOK ® Cuarta edición)
FF
FinishtoFinish
U SE Finish to Finish (FF) ( Guía PMBOK ® Cuarta edición)
FF
Flotador Libre
Flotador libre U SE (FF) ( Guía PMBOK ® Cuarta edición)
FS
FinishtoStart
U SE FinishtoStart (FS) ( Guía PMBOK ® Cuarta edición)
LF
Fecha de finalización tardía
U SE Fecha de finalización tardía (LF) ( Guía PMBOK ® Cuarta edición)
LS
Fecha de inicio tardío
U SE Fecha de inicio tardío (LS) ( Guía PMBOK ® Cuarta edición)
sobredosis
Duración original
U SE Duración original (OD) ( Guía PMBOK ® — Cuarta edición)
Page 121
109
GLOSARIO
ordenador personal
Porcentaje completo
U SE Porcentaje completo (PC o PCT) ( Guía PMBOK ® — Cuarta edición)
PCT
Porcentaje completo
U SE Porcentaje completo (PC o PCT) ( Guía PMBOK ® — Cuarta edición)
PDM
Método de diagramación de precedencia
Método de diagrama de precedencia de U SE (PDM) ( Guía PMBOK ® Cuarta edición)
PF
Fecha de finalización planificada ( Guía PMBOK ® Cuarta edición)
PM
Gerente de proyecto
U SE Project Manager (PM) ( Guía PMBOK ® — Cuarta edición)
PMB
Línea de base de medición de rendimiento
U SE Línea de base de medición de rendimiento (PMB) ( Guía PMBOK ® Cuarta edición)
PMO
Oficina de Gestión de Proyectos
U SE Project Management Office (PMO) ( Guía PMBOK ® — Cuarta edición)
PD
Fecha de inicio planificada ( Guía PMBOK ® — Cuarta edición)
RD
Duración restante
U SE Duración restante (RD) ( Guía PMBOK ® Cuarta edición)
SF
Fecha de finalización programada
U SE Fecha de finalización programada (SF) ( Guía PMBOK ® Cuarta edición)
SF
Empezar a acabar
U SE StarttoFinish (SF) ( Guía PMBOK ® Cuarta edición)
SEMBRAR
Declaración de trabajo
Declaración de trabajo de U SE (SOW) ( Guía PMBOK ® Cuarta edición)
SS
Fecha de inicio programada
U SE Fecha de inicio programada (SS) ( Guía PMBOK ® — Cuarta edición)
SS
StarttoStart
U SE StarttoStart (SS) ( Guía PMBOK ® Cuarta edición)
SV
Variación de horario
U SE Schedule Variance (SV) ( Guía PMBOK ® — Cuarta edición)
TF
Fecha objetivo de finalización
U SE Fecha objetivo de finalización (TF) ( Guía PMBOK ® — Cuarta edición)
TF
Flotación total
U SE Total Float (TF) ( Guía PMBOK ® — Cuarta edición)
Page 122
110
GLOSARIO
TS
Fecha de inicio objetivo
U SE Fecha de inicio objetivo (TS) ( Guía PMBOK ® Cuarta edición)
WBS
Estructura de desglose del trabajo
Estructura de desglose del trabajo U SE (WBS) ( Guía PMBOK ® Cuarta edición)
Términos y definiciones
Actividad . Un componente del trabajo realizado durante el curso de un proyecto. Vea también
la actividad del horario .
Actividad Costo real. El costo total del trabajo completado durante un período de tiempo
determinado. Este valor puede ser
calculado en cualquier nivel de esquema del modelo de programación y entre varias fechas de
datos. Si se realiza el cálculo
utilizando la fecha de inicio del proyecto y la fecha de datos más actual, los valores se denominan
"acumulativos".
Duración real de la actividad. El número total de períodos de trabajo en unidades de calendario entre
la actividad real
fecha de inicio de la actividad de planificación y la fecha de datos del modelo de planificación, si la
actividad de planificación está en
progreso, o la fecha de finalización real de la actividad, si la actividad del cronograma está
completa. Ver también duración real .
Actividad Fecha de finalización real. El momento en el que se completa una actividad de
programación. Ver también acabado real
fecha .
Actividad Fecha de inicio real. El momento en el que comenzó una actividad programada.
Atributos de actividad [Salida / Entrada ] . Múltiples atributos asociados con cada actividad de
programación que pueden ser
incluido en la lista de actividades. Los atributos de actividad incluyen códigos de actividad,
actividades predecesoras, sucesor
actividades, relaciones lógicas, clientes potenciales y retrasos, requisitos de recursos, fechas
impuestas, restricciones y
Suposiciones
Fecha de finalización de la línea de base de la actividad. El punto en el tiempo asociado con la
finalización de la actividad del cronograma en un
línea base aprobada del cronograma del proyecto. Ver también actividad fecha de finalización actual .
Duración de la línea de base de la actividad. El número total de períodos de trabajo en unidades de
calendario entre la línea de base de la actividad.
fecha de inicio y fecha de finalización de la línea base de actividad de una actividad de cronograma
según lo determinado por su cronograma de proyecto aprobado
base.
Fecha de inicio de la línea de base de la actividad. El punto en el tiempo asociado con el comienzo
de la actividad del cronograma en un
línea base aprobada del cronograma del proyecto. Ver también actividad fecha de inicio actual .
Cuadro de actividad. Un objeto gráfico que se utiliza para mostrar datos de actividad de
programación de acuerdo con la red de programación
lógica.
Calendario de actividades. Por lo general, el calendario del proyecto u otro calendario
específicamente definido del calendario
biblioteca, asignada a la actividad de programación que define los períodos de trabajo y los períodos
no laborables en el calendario
formato. El calendario de actividades, en las actividades programadas a las que está asignado, se
utiliza para reemplazar el proyecto.
calendario durante el análisis de la red programada. Ver también la biblioteca de calendario .
123
111
GLOSARIO
Código de actividad. Uno o más valores numéricos o de texto que identifican las características del
trabajo o de alguna manera
categorizar la actividad del cronograma que permite filtrar y ordenar actividades dentro de los
informes.
Estimación de costo de actividad. El costo proyectado de la actividad del cronograma que incluye el
costo de todos los recursos
requerido para realizar y completar la actividad, incluidos todos los tipos de costos y componentes de
costos.
Actividad Probabilidad acumulativa Distribución de riesgos. Una tabla de fechas y sus
acumulativos asociados.
probabilidades de ocurrencia para completar la actividad del cronograma. Las fechas se derivan
utilizando técnicas analíticas.
tales como los cálculos de Monte Carlo. Cuando se aplica a la fecha de finalización del proyecto, el
valor es equivalente al proyecto.
distribución de riesgo de probabilidad acumulativa.
Actividad Fecha de finalización actual. La estimación actual del momento en el que la actividad del
cronograma será
completado, donde la estimación refleja cualquier progreso de trabajo informado. Consulte también
la fecha de finalización programada de la actividad,
fecha de finalización de la línea de base de actividad, fecha de finalización actual.
Actividad Fecha de inicio actual. La estimación actual del momento en el que comenzará la
actividad del cronograma,
donde la estimación refleja cualquier progreso de trabajo reportado. Consulte también la fecha de
inicio programada de la actividad, la línea de base de la actividad
fecha de inicio y fecha de inicio actual .
Descripción de la actividad (AD). Una frase corta o etiqueta para cada actividad del cronograma,
utilizada junto con una actividad
identificador para diferenciar una actividad del cronograma del proyecto de otras actividades del
cronograma. La descripción de la actividad.
normalmente identifica el alcance del trabajo de la actividad del cronograma. También conocido como
nombre de actividad o título de actividad.
Definir actividades [Proceso]. El proceso de identificar las actividades específicas del cronograma
que deben realizarse
para producir los diversos entregables del proyecto.
Estimación de la duración de la actividad [Proceso]. El proceso de estimar el número de períodos
de trabajo que serán
necesario para completar actividades de horario individual.
Duración de la actividad. El número total de períodos de trabajo, en unidades de calendario, entre la
fecha de inicio temprano de la actividad y
la actividad fecha de finalización temprana de una actividad programada. Ver 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 del
duración total de la actividad para una actividad programada que tiene trabajo en progreso.
Variación de duración de la actividad. Una desviación, salida o divergencia cuantificable lejos de
una duración dada para
Una actividad programada.
Fecha prevista de finalización de la actividad. Una restricción de fecha colocada en las fechas de
finalización temprana y tardía de la actividad de un
actividad del cronograma en progreso que afecta cuándo la actividad del cronograma puede
programarse para completarse y es
generalmente en la forma de una fecha impuesta fija. Esta restricción requiere que se establezca la
duración restante de la actividad
igual a la diferencia entre la fecha de finalización esperada de la actividad y la fecha de datos para
forzar la actividad programada
se programará para finalizar en la fecha impuesta.
Actividad Fecha de finalización temprana. El punto más temprano posible en el tiempo cuando la
parte incompleta del horario
La actividad puede completarse dados los recursos asignados. Ver también la fecha de finalización
temprana.
Page 124
112
GLOSARIO
Fecha de inicio temprano de la actividad. El punto más temprano posible en el que la actividad del
cronograma puede comenzar según
el CPM pasa la lógica del modelo de programación. Ver también la fecha de inicio temprano .
Fecha de finalización de la actividad. Un punto en el tiempo asociado con la finalización de una
actividad programada en un proyecto. Generalmente
calificado por uno de los siguientes: real, de referencia, actual, temprano, esperado, tardío, obligatorio,
programado o
objetivo. Ver también fecha de finalización.
Grupo de actividad. Un conjunto de actividades del cronograma seleccionado por un miembro del
equipo del proyecto, que comparte alguna actividad común
atributo que permite agrupar e informar las actividades o mostrarlas por separado, como dividirlas en
Una pantalla gráfica de otras actividades con una línea horizontal.
Identificador de actividad. Una identificación numérica o de texto breve y única asignada a cada
actividad del cronograma para diferenciar
esa actividad del proyecto de otras actividades. Típicamente único dentro de cualquier diagrama de
red modelo de programación.
Etiqueta de actividad. Una breve frase o etiqueta para cada actividad de programación utilizada junto
con un identificador de actividad
para diferenciar esa actividad del modelo de programación de otras actividades de programación. La
descripción de la actividad normalmente
describe el alcance del trabajo de la actividad del cronograma. También conocido como nombre de
actividad o nombre de tarea.
Actividad Fecha de finalización tardía. El último momento posible en el que se puede completar la
sin violar una restricción de programación o retrasar la fecha de finalización del proyecto. Ver
también la fecha de finalización tardía .
Actividad Fecha de inicio tardío. El último punto posible en el tiempo en que la actividad del
cronograma puede comenzar sin
violar una restricción de programación o retrasar la fecha de finalización del proyecto. Ver
también fecha de inicio tardío.
Lista de actividades [Salida / Entrada]. Una tabulación documentada de las actividades del
cronograma que muestra la descripción de la actividad,
identificador de actividad, y una definición de alcance de actividad suficientemente detallada para el
trabajo para que los miembros del equipo del proyecto
Comprender qué trabajo se va a realizar. La lista puede tener atributos de actividad adicionales.
Actividad Fecha de finalización obligatoria. Una restricción de fecha de finalización colocada en
una actividad de programación que establece tanto
las fechas de finalización temprana y tardía de la actividad son iguales a una fecha impuesta fija y, por
lo tanto, también limitan el inicio temprano
fechas de las rutas de red que siguen lógicamente esa actividad programada.
Fecha de inicio obligatoria de la actividad. Una restricción de fecha de inicio colocada en una
actividad de programación que establece tanto la actividad
fechas de inicio temprano y tardío igual a una fecha de imposición fija y, por lo tanto, también
restringe la fecha de finalización tardía del
rutas de red que preceden lógicamente esa actividad programada
Nombre de la actividad. Ver descripción de la actividad .
Actividad Duración original. La duración de la actividad originalmente asignada a una actividad
programada, esta duración es
típicamente no se actualiza ya que el progreso se informa en la actividad. Se utiliza para comparar 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 es normalmente
desarrollado por la dependencia de datos históricos, especialistas, disponibilidad de recursos,
consideraciones financieras y volumen
de trabajo a realizar. También puede llamarse duración planificada.
Actividad en flecha (AOA ) . Ver método de diagrama de flechas (ADM).
125
113
GLOSARIO
Actividad en el nodo (AON). Ver método de diagramación de precedencia (PDM)
Actividad Porcentaje físico completo. Una estimación, expresada como porcentaje, de la cantidad de
trabajo que tiene
completado en una actividad programada, medida en términos de progreso del trabajo físico o por
medio de
reglas de ganancia de gestión del valor ganado.
Fecha de finalización planificada de la actividad. Ver actividad fecha de finalización programada.
Fecha de inicio planificada de la actividad. Ver actividad programada fecha de inicio.
Duración restante de la actividad. El número total de períodos de trabajo en unidades de calendario,
(a) igual al original
duración de una actividad que no ha comenzado o (b) entre la fecha de datos del cronograma del
proyecto y el CPM
fecha de finalización temprana de una actividad de programación que tiene una fecha de inicio real de
actividad. Esto representa el tiempo necesario para
completar una actividad programada donde el trabajo está en progreso. Ver también duración
restante.
Recursos estimados de la actividad [Proceso]. El proceso de estimar los tipos y cantidades de
recursos.
requerido para realizar cada actividad programada.
Fecha de finalización del nivel de recursos de la actividad. El punto en el tiempo asociado con la
fecha de finalización programada de la actividad de
una actividad de programación con recursos limitados en una programación con recursos limitados.
Fecha de inicio del nivel de recursos de la actividad. El momento en el tiempo asociado con la
actividad programada fecha de inicio de un
actividad de horario limitado de recursos en un horario limitado de recursos.
Índice de criticidad del riesgo de actividad. La probabilidad de que la actividad del cronograma se
encuentre en una ruta crítica.
Fecha de finalización de la actividad programada. El momento en que el trabajo estaba
programado para completarse en un horario
actividad. La fecha de finalización del cronograma de actividades normalmente está dentro del rango
de fechas delimitadas por la actividad anticipadamente
fecha de finalización y la actividad fecha de finalización tardía. Puede reflejar la nivelación de
recursos de recursos escasos. También conocido como
actividad prevista fecha de finalización. Consulte también la fecha de finalización actual de la
actividad, la fecha de finalización programada.
Fecha de inicio programada de la actividad. El momento en que el trabajo estaba programado para
comenzar en una actividad programada.
La fecha de inicio del cronograma de actividades normalmente está dentro del rango de fechas
delimitadas 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 conocido como actividad
fecha de inicio planificada Consulte también la fecha de inicio actual de la actividad, la fecha de
inicio programada.
Definición del alcance de la actividad. Narrativa documentada que describe el trabajo representado
por la actividad.
Secuencia de actividades [Proceso]. El proceso de identificación y documentación de dependencias
entre horarios
ocupaciones.
Fecha de inicio de la actividad. Un punto en el tiempo asociado con el inicio de la actividad del
cronograma en un proyecto. Generalmente
calificado por uno de los siguientes: real, de referencia, actual, temprano, tardío, programado u
objetivo. Ver también fecha de inicio.
Variación de la fecha objetivo de la actividad. Una desviación, salida o divergencia cuantificable de
una actividad conocida
fecha de inicio objetivo o fecha de finalización objetivo de actividad.
Page 126
114
GLOSARIO
Duración objetivo de la actividad. El número total estimado de períodos de trabajo en unidades de
calendario, necesarios para completar
la actividad del cronograma según lo determinado por un cronograma objetivo específico del
proyecto.
Fecha objetivo de finalización de la actividad. Un punto en el tiempo establecido por el análisis de
la red programada para completar un
programar la actividad dentro de una versión específica del cronograma del proyecto.
Fecha objetivo de inicio de la actividad. Un punto en el tiempo establecido por el análisis de red del
cronograma para comenzar el cronograma.
actividad dentro de una versión específica del cronograma del proyecto.
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 de programación.
Para las actividades programadas en curso, incluye la duración real de la actividad más la duración
Tipo de actividad. Una designación de categorización que diferencia las actividades de horario
discreto que tienen
diferentes funciones dentro del modelo de programación, como hito, tarea, resumen, nivel de esfuerzo
y ficticio.
Costo real (AC). Costes totales realmente incurridos y registrados en la realización del trabajo
realizado durante un determinado
período de tiempo para un componente de estructura de desglose de actividad o trabajo
programado. El costo real a veces puede ser
horas de trabajo directo solo, costos directos solo o todos los costos, incluidos los costos
indirectos. También conocido como el costo real
del trabajo realizado (ACWP). Ver también la técnica del valor ganado (EVT).
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 datos del cronograma del proyecto si la actividad del cronograma está en progreso o la
fecha de finalización real si el
la actividad del horario está completa. Consulte también la duración real de la actividad y la
duración real del proyecto.
Fecha de finalización real. El momento en que el trabajo realmente terminó en una actividad
programada. (Nota: en alguna aplicación
áreas, la actividad del cronograma se considera "terminada" cuando el trabajo está "sustancialmente
completo"). Consulte también la actividad
fecha de finalización real y fecha de finalización real del proyecto.
Fecha de inicio real. Consulte la fecha de inicio real de la actividad y la fecha de inicio real del
proyecto.
Fecha de finalización real (AF). El momento en que el trabajo realmente terminó en una actividad
programada. (Nota: en algunos
áreas de aplicación, la actividad del cronograma se considera "terminada" cuando el trabajo está
"sustancialmente completo")
Fecha de inicio real (AS). El momento en que el trabajo realmente comenzó en una actividad
programada.
Área de aplicación. Una categoría de proyectos que tienen componentes comunes significativos en
tales proyectos,
pero no son necesarios ni están presentes en todos los proyectos. Las áreas de aplicación generalmente
se definen en términos de
producto (es decir, mediante tecnologías o métodos de producción similares) o el tipo de cliente (es
decir, interno versus
sector externo, gubernamental versus comercial) o industrial (es decir, servicios públicos, automotriz,
aeroespacial, información
tecnologías). Las áreas de aplicación pueden superponerse.
Page 127
115
GLOSARIO
Aprobar. El acto de confirmar formalmente, sancionar, ratificar o aceptar algo.
Flecha. La presentación gráfica de una actividad de programación en el método de diagrama de
flechas o una relación lógica
entre actividades programadas en el método de diagramación de precedencia.
Método de diagrama de flecha (ADM) [Técnica]. Una técnica de diagramación de red programada
en la que
programar actividades están representadas por flechas. La cola de la flecha representa el comienzo, y
la cabeza representa
El final de la actividad programada. (La longitud de la flecha no representa la duración esperada del
programar la actividad). Las actividades del cronograma están conectadas en puntos llamados nodos
(generalmente dibujados como pequeños círculos) para
ilustrar la secuencia en la que se espera que se realicen las actividades del cronograma. Ver
también precedencia
Método de diagramación (PDM).
A partir de la fecha. Ver fecha de datos (DD).
Suposiciones [Salida / Entrada]. Los supuestos son factores que, para fines de planificación, se
consideran
verdadero, real o cierto sin prueba ni demostración. Los supuestos afectan todos los aspectos de la
planificación del proyecto, y
son parte de la elaboración progresiva del proyecto. Los equipos de proyecto con frecuencia
identifican, documentan y validan
supuestos como parte de su proceso de planificación. Los supuestos generalmente implican un grado
de riesgo.
Autor. El creador, editor o parte responsable de un documento, como un cronograma, un presupuesto
o
análisis.
Pase hacia atrás. El cálculo de fechas de finalización tardía y fechas de inicio tardía para las partes
incompletas de todos
programar actividades Determinado trabajando hacia atrás a través de la lógica de red programada
desde el proyecto
fecha final. La fecha de finalización puede ser calculada en un pase adelantado o establecida por el
cliente o patrocinador. Ver también
análisis de la red de horarios.
Bar. Un objeto de visualización gráfica de forma rectangular utilizado para representar la aparición de
un componente de datos en un
documento, como una actividad programada en un gráfico de barras cuya longitud está determinada
por el inicio y el final de la actividad
fechas 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 progreso o líneas de base.
Gráfico de barras [Herramienta]. Una visualización gráfica de información relacionada con el
horario. En el gráfico de barras típico, programe actividades
o los componentes de la estructura de desglose del trabajo se enumeran en el lado izquierdo del
gráfico, las fechas se muestran en
arriba, y las duraciones de actividad se muestran como barras horizontales colocadas con
fecha. También conocido como diagrama de Gantt.
Línea base El plan de fases de tiempo aprobado (para un proyecto, un componente de estructura de
desglose de trabajo, un trabajo
paquete o actividad del cronograma), más o menos alcance, costo, cronograma y cambios técnicos
aprobados del proyecto.
Generalmente se refiere a la línea de base actual, pero puede referirse a la línea de base original o
alguna otra. Usualmente usado con
un modificador (p. ej., línea base de costo, línea base de programación, línea base de medición de
desempeño, línea base técnica). Ver
también medición de rendimiento de referencia.
Fecha de referencia. La fecha en que se estableció la línea de base actual. A veces se usa con un
modificador como
como, cronograma del proyecto, alcance del proyecto o costo del proyecto.
Page 128
116
GLOSARIO
Duración basal. Vea la duración de la línea de base de la actividad y la duración de la línea de base
del proyecto.
Fecha de finalización de referencia. Consulte la fecha de finalización de la línea base de la
actividad y la fecha de finalización de la línea de base del proyecto.
Fecha de inicio de referencia. Consulte la fecha de inicio de la línea de base de la actividad y
la fecha de inicio de la línea de base del proyecto.
Presupuesto. La estimación aprobada para el proyecto o cualquier componente de la estructura de
desglose del trabajo o cualquier cronograma
actividad. Ver también estimación .
Costo presupuestado del trabajo realizado (BCWP). Ver valor ganado (EV).
Calendario. Una tabla o registro de fechas que contiene los días de cada mes y semana en uno o más
años. En
gestión de proyectos, cada fecha puede identificarse como un lapso de tiempo para realizar el trabajo
(período de trabajo) o como un tiempo
lapso por no realizar el trabajo, incluidos los días festivos designados (período no laboral) y cada
fecha puede ser adicional
subdividido en segmentos tales como turnos, horas o incluso minutos que pueden designarse como
períodos de trabajo o no
períodos de trabajo Usualmente se usa con un modificador como actividad, año fiscal, gregoriano,
proyecto, programa o recurso.
Biblioteca de calendario. Un conjunto de calendarios que se pueden aplicar a las diversas actividades
y recursos del cronograma. Ver
también 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 en horas,
días o semanas, pero también puede ser en cuartos de año, meses, turnos o incluso en minutos.
Cambio de control. Identificar, documentar, aprobar o rechazar y controlar los cambios en la línea de
base del proyecto.
Componente. Una parte constituyente, elemento o pieza de un todo complejo.
Restricción [Entrada]. El estado, la calidad o la sensación de estar restringido a un curso de acción o
inacción dado. Un
restricción o limitación aplicable, ya sea interna o externa al proyecto, que afectará el desempeño de
El proyecto o un proceso. Por ejemplo, una restricción de programación es cualquier limitación o
restricción colocada en el proyecto
horario que afecta cuándo se puede programar una actividad de horario y generalmente es en forma de
impuesto fijo
fechas. Una restricción de costos es cualquier limitación o restricción colocada en el presupuesto del
proyecto, como los fondos disponibles durante
hora. Una restricción de recursos del proyecto es cualquier limitación o restricción impuesta al uso de
recursos, como qué recurso
las habilidades o disciplinas están disponibles y la cantidad de un recurso dado disponible durante un
período de tiempo específico.
Control [Técnica]. Comparar el rendimiento real con el rendimiento planificado, analizar las
variaciones, evaluar
tendencias para efectuar mejoras en el proceso, evaluando posibles alternativas y recomendando
acción correctiva según sea necesario.
Control Account (CA) [Herramienta]. Un punto de control de gestión donde el alcance, el
presupuesto (planes de recursos), el costo real,
y el cronograma se integran y comparan con el valor ganado para la medición del desempeño. Las
cuentas de control son
colocado en puntos de gestión seleccionados (componentes específicos en niveles seleccionados) de la
estructura de desglose del trabajo.
Cada cuenta de control puede incluir uno o más paquetes de trabajo, pero cada paquete de trabajo
puede estar asociado con
Solo una cuenta de control. Cada cuenta de control está asociada con un componente organizativo
único específico en
La estructura de desglose organizacional (OBS). Anteriormente llamado cuenta de costos. Ver
también paquete de trabajo.
Page 129
117
GLOSARIO
Programa de control [Proceso]. El proceso de controlar los cambios en el cronograma del proyecto.
Acción correctiva. Dirección documentada para ejecutar el trabajo del proyecto para lograr el
rendimiento futuro esperado
del trabajo del proyecto en línea con el plan de gestión del proyecto.
Costo. El valor monetario o precio de una actividad o componente del proyecto que incluye el valor
monetario de la
recursos necesarios para realizar y completar la actividad o componente, o para producir el
componente. Especifico
el costo puede estar compuesto por una combinación de componentes de costos que incluyen horas de
trabajo directo, otros costos directos,
horas laborales indirectas, otros costos indirectos y precio de compra. (Sin embargo, en la gestión del
valor ganado
metodología, en algunos casos, el término costo puede representar solo horas laborales sin conversión
a monetaria
valor.) Vea también el costo real (AC), estimado.
Tipo de costo Una subdivisión del costo, como costo directo, costo indirecto y tarifa.
Componente de costo. Un componente del costo, como el costo laboral, el costo del equipo y el costo
del material.
Estrellarse [Técnica]. Un tipo específico de técnica de compresión del cronograma del proyecto
realizada al tomar medidas
para disminuir la duración total del cronograma del proyecto después de analizar una serie de
alternativas para determinar cómo obtener
La compresión de duración máxima de la programación por el menor costo adicional. Enfoques
típicos para chocar un
el cronograma incluye reducir la duración de las actividades del cronograma y aumentar la asignación
de recursos en el cronograma
ocupaciones. Consulte también seguimiento rápido , compresión de programación
Criterios Estándares, reglas o pruebas en las que se puede basar un juicio o decisión, o por el cual un
producto,
servicio, resultado o proceso pueden ser evaluados.
Actividad crítica Cualquier actividad de programación en una ruta crítica en la programación de un
proyecto. Más comúnmente determinado por
utilizando el método de la ruta crítica. Aunque algunas actividades son "críticas", en el sentido del
diccionario, sin estar en
En la ruta crítica, este significado rara vez se utiliza en el contexto del proyecto.
Método de la cadena crítica [técnica]. Una técnica de análisis de red de cronograma que modifica el
para tener en cuenta los recursos limitados. El método de la cadena crítica combina enfoques
deterministas y probabilísticos para
análisis de la red de horarios.
Camino critico. Generalmente, pero no siempre, la secuencia de actividades del cronograma que
determina la duración de la
proyecto. En general, es el camino más largo a través del proyecto. Sin embargo, una ruta crítica
puede terminar, por ejemplo,
en un hito de programación que se encuentra en el medio del modelo de programación y que tiene un
final no más tarde que
fecha impuesta restricción de horario. Consulte también ruta crítica del proyecto, ruta crítica
especificada y ruta crítica
método.
Método de la ruta crítica (CPM) [Técnica]. Una técnica de análisis de red programada utilizada para
determinar el
cantidad de flexibilidad de programación (la cantidad de flotante) en varias rutas de red lógicas en el
red, y para determinar la duración mínima total del proyecto. Las fechas de inicio y finalización
tempranas se calculan por
significa un pase hacia adelante, utilizando una fecha de inicio especificada. Las fechas de inicio y
finalización tardías se calculan mediante
un pase hacia atrás, a partir de una fecha de finalización especificada, que a veces es la fecha de
finalización temprana del proyecto
determinado durante el cálculo del pase de avance. Ver también ruta crítica.
130
118
GLOSARIO
Fecha de finalización actual. La estimación actual del punto en el tiempo en que se completará una
actividad programada,
donde la estimación refleja cualquier progreso de trabajo reportado. Ver también fecha de finalización
programada, actividad final actual
fecha y fecha de finalización actual del proyecto.
Fecha de inicio actual. La estimación actual del momento en el que comenzará una actividad
programada, donde
la estimación refleja cualquier progreso laboral reportado. Consulte también la fecha de inicio
programada , la fecha de inicio de referencia, la actividad
fecha de inicio actual y fecha de inicio actual del proyecto.
Cliente. La persona u organización que utilizará el producto o servicio o resultado del proyecto. Ver
también usuario.
Fecha de datos (DD). La fecha a través de la cual se determinó por última vez el estado y el progreso
del proyecto y se informó
análisis, como la programación y las mediciones de rendimiento. Es la última fecha histórica
pasada. También conocido
como a la fecha.
Línea de fecha de datos. Línea vertical de arriba a abajo de un informe gráfico, como un gráfico de
barras que muestra la fecha de datos
en relación con la escala de tiempo y las barras.
Fecha. Un 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 [técnica]. Una técnica de planificación que subdivide el alcance del proyecto y los
entregables del proyecto.
en componentes más pequeños y manejables, hasta que el proyecto funcione, asociado con la
realización del proyecto
alcance y proporcionar los entregables, se define con suficiente detalle para apoyar la ejecución,
monitoreo y
controlando el trabajo.
Entregable [Salida / Entrada]. Cualquier producto, resultado o capacidad únicos y verificables para
realizar un servicio que
debe ser producido para completar un proceso, fase o proyecto. A menudo se usa más estrictamente en
referencia a un
entregable externo, que es una entrega que está sujeta a la aprobación del patrocinador del proyecto o
del cliente. Ver
También producto, resultado, servicio.
Dependencia. Ver relación lógica.
Desarrollar horario [Proceso]. El proceso de analizar las secuencias de actividades del cronograma,
la duración de las actividades del cronograma,
requisitos de recursos y restricciones de programación para crear la programación del proyecto.
Disciplina. Un campo de trabajo que requiere conocimientos específicos y 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 registrada al respecto, que generalmente tiene permanencia y
puede leerse
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 consideran que tienen un impacto directo en la duración de
la actividad durante el recurso
arrasamiento.
Página 131
119
GLOSARIO
Duración (DU o DUR). El número total de períodos de trabajo (sin incluir días festivos u otros
períodos no laborables)
requerido para completar una actividad programada o un componente o proyecto de estructura de
desglose de trabajo. Generalmente expresado
como horas de trabajo, días laborables o semanas laborales. A veces incorrectamente equiparado con
el tiempo transcurrido. Contrastar con
esfuerzo . Ver también duración de la actividad y duración del proyecto.
Duración Porcentaje completo. Consulte también porcentaje de duración de actividad
completa y porcentaje de duración del proyecto
completa .
Variación de duración. Ver variación de duración de actividad y variación de duración del
proyecto .
Fecha de finalización temprana (EF). En el método de ruta crítica, el punto de tiempo más temprano
posible en el que
las partes incompletas de una actividad de programación (o el proyecto) pueden finalizar, según la
lógica de la red de programación,
la fecha de datos y cualquier restricción de programación. Las fechas de finalización temprana pueden
cambiar a medida que avanza el proyecto y
a medida que se realizan cambios en el plan de gestión del proyecto. Ver también actividad fecha de
finalización temprana y proyecto temprano
fecha de finalización.
Fecha de inicio temprano (ES). En el método de la ruta crítica, el punto de tiempo más temprano
posible en el que
partes de una actividad programada (o el proyecto) pueden comenzar, en función de la lógica de la red
programada, la fecha de datos,
y cualquier restricción de horario. Las fechas de inicio temprano pueden cambiar a medida que avanza
el proyecto y los cambios son
hecho al plan de gestión del proyecto. Consulte también la fecha de inicio temprano de la actividad y
la fecha de inicio temprano del proyecto.
Valor Ganado (EV). El valor del trabajo realizado expresado en términos del presupuesto aprobado
asignado a ese
trabajar para una actividad de cronograma o componente de estructura de desglose de
trabajo. También conocido como costo de trabajo presupuestado
realizado (BCWP).
Técnica del valor ganado (EVT) [Técnica]. Una técnica específica para medir el desempeño del
trabajo para
un componente de estructura de desglose de trabajo, cuenta de control o proyecto. También se conoce
como las reglas de ingresos y
método de acreditación Consulte también el costo real, el estimado al finalizar (EAC) y el estimado
al finalizar (EVC).
Esfuerzo. El número de unidades de trabajo requeridas para completar una actividad programada o
una estructura de desglose del trabajo
componente. Generalmente se expresa como horas de personal, días de personal o semanas de
personal. Contraste con la duración .
Empresa. Una empresa, negocio, firma, sociedad, corporación o agencia gubernamental.
Estimar [Salida / Entrada]. Una evaluación cuantitativa de la cantidad o resultado
probable. Usualmente aplicado a
costos, recursos, esfuerzo y duraciones del proyecto y generalmente está precedido por un modificador
(es decir, preliminar,
conceptual, factibilidad, orden de magnitud, definitivo). Siempre debe incluir alguna indicación de
precisión
(por ejemplo, x por ciento).
Estimación al finalizar (EAC) [Salida / Entrada]. El costo total esperado de una actividad
programada, un desglose del trabajo
componente de estructura o el proyecto cuando se completará el alcance de trabajo definido. EAC es
igual a
costo real (AC) más la estimación para completar (ETC) para todo el trabajo restante. EAC AC más
ETC. El EAC
puede ser calculado en función del desempeño hasta la fecha o estimado por el equipo del proyecto en
función de otros factores, en
cuyo caso a menudo se conoce como la última estimación revisada. Ver también técnica de valor
ganado (EVT), estimación
para completar (ETC).
Page 132
120
GLOSARIO
Estimate to Complete (ETC) [Salida / Entrada]. El costo esperado necesario para completar todo el
trabajo restante
para una actividad de cronograma, componente de estructura de desglose de trabajo o el proyecto. Ver
también técnica de valor ganado
(EVT), estimación al finalizar (EAC).
Seguimiento rápido [Técnica]. Una técnica de compresión de programación de proyecto específica
que cambia la lógica de red a
superposición de fases que normalmente se realizarían en secuencia, como la fase de diseño y la fase
de construcción, o
para realizar actividades programadas en paralelo. Ver también estrellarse , programar compresión
Fecha de finalización. Un punto en el tiempo asociado con la finalización de una actividad de
programación. Generalmente calificado por uno de los
siguiente: real, de referencia, actual, temprano, estimado, tardío, planificado, programado u
objetivo. Ver también actividad finalizada
fecha y fecha de finalización del proyecto.
Acabado no antes de. Una restricción de programación colocada en la actividad de programación que
afecta cuando una programación
la actividad se puede programar y generalmente tiene la forma de una fecha de imposición fija. Un
acabado no anterior a la restricción
evita que la actividad se programe para finalizar antes de la fecha impuesta. Restricciones "no
anteriores a"
impactar solo en el cálculo del pase de avance de CPM y, por lo tanto, solo en las fechas tempranas de
CPM de una actividad programada.
Terminar a más tardar el. Una restricción de programación colocada en la actividad de
programación que afecta cuando una programación
acabado no posterior a la restricción
evita que la actividad se programe para finalizar después de la fecha impuesta. Restricciones "a más
tardar el"
impactar solo en el cálculo del pase hacia atrás de CPM y, por lo tanto, en las fechas de retraso de
CPM de una actividad programada.
Terminar en Una restricción de fecha colocada en la actividad de programación que requiere que la
actividad de programación finalice en un determinado
fecha. Una restricción Finalizar en evita que la actividad se programe para finalizar antes y después de
lo impuesto
fecha. Las restricciones Finalizar en son una combinación de las restricciones No anterior a y No
posterior a. Estos impactan tanto
el cálculo del pase de CPM hacia adelante y hacia atrás y, por lo tanto, las fechas iniciales y
finales. Esto causa el horario
actividad para tener un flotante total cero mientras que sus predecesores y sucesores pueden tener
diferentes valores de flotante total.
FinishtoFinish (FF). La relación lógica donde la finalización del trabajo de la actividad sucesora no
puede terminar
hasta la finalización del trabajo de la actividad predecesora.
FinishtoStart (FS). La relación lógica donde el inicio del trabajo de la actividad sucesora depende
de
La finalización del trabajo de la actividad predecesora.
Flotador. También se llama holgura. Ver también flotación libre (FF), flotación total (TF).
Previsiones Estimaciones o predicciones de condiciones y eventos en el futuro del proyecto basados
en información
y conocimiento disponible al momento del pronóstico. Las previsiones se actualizan y vuelven a
emitir según el trabajo
información de rendimiento proporcionada a medida que se ejecuta el proyecto. La información se
basa en el pasado del proyecto.
rendimiento y rendimiento futuro esperado, e incluye información que podría afectar el proyecto en el
futuro, como la estimación al finalizar y la estimación para completar.
Pase adelantado. El cálculo de las fechas de inicio temprano y finalización temprana para las
porciones incompletas de todos
actividades de red. Consulte también el paso hacia atrás , el análisis de la red programada .
Page 133
121
GLOSARIO
Flotador libre (FF). La cantidad de tiempo que se puede retrasar una actividad programada sin
retrasar el CPM temprano
inicio de las actividades programadas inmediatamente siguientes. Ver también flotación total (TF).
Gráfico de gantt. Ver gráfico de barras .
Grafico. Una pantalla gráfica visual que utiliza líneas y formas para representar valores de datos,
como el estado del proyecto o
pronóstico de información.
Actividad de hamacas. Una actividad cuya duración se agrega mediante relaciones lógicas de un
grupo de
actividades dentro del modelo de horario. Ver también resumen de actividad.
Fecha impuesta. Una fecha fija impuesta en una actividad del cronograma o hito del cronograma,
generalmente en forma de
Comience no antes de y termine no más tarde de la fecha.
Entrada [ Entrada de proceso]. Cualquier elemento, ya sea interno o externo al proyecto que
requiera un proceso antes
ese proceso continúa. Puede ser una salida de un proceso predecesor.
Integrado. Componentes interrelacionados, interconectados, enclavados o mallados combinados y
unificados en un
funcionamiento o todo unificado.
Lag [Técnica]. Una modificación de una relación lógica que dirige un retraso en la actividad
sucesora. por
Por ejemplo, en una dependencia de principio a inicio con un retraso de diez días, la actividad
sucesora no puede comenzar hasta diez días
después de que la actividad predecesora haya terminado. Ver también plomo.
Fecha de finalización tardía (LF). En el método de ruta crítica, el último punto posible en el tiempo
que una actividad de programación puede
se completará en función de la lógica de la red programada, la fecha de finalización del proyecto y las
restricciones asignadas
a las actividades del cronograma sin violar una restricción del cronograma o retrasar la fecha de
finalización del proyecto. los
las fechas de finalización tardía se determinan durante el cálculo del pase hacia atrás de la red de
cronograma del proyecto. Ver
también actividad fecha de finalización tardía, fecha de finalización tardía del proyecto.
Fecha de inicio tardío (LS). En el método de ruta crítica, el último punto posible en el tiempo que
una actividad de programación puede
comenzará según la lógica de la red programada, la fecha de finalización del proyecto y las
restricciones asignadas a
las actividades del cronograma sin violar una restricción del cronograma o retrasar la fecha de
finalización del proyecto. El tardío
las fechas de inicio se determinan durante el cálculo del paso hacia atrás de la red de cronograma del
proyecto. Ver también
fecha de inicio tardío de la actividad, fecha de inicio tardío del proyecto.
Plomo [Técnica]. Una modificación de una relación lógica que permite una aceleración de la actividad
sucesora.
Por ejemplo, en una dependencia de principio a inicio con una ventaja de diez días, la actividad
sucesora puede comenzar diez días
antes de que la actividad predecesora haya terminado. Un plomo negativo es equivalente a un retraso
positivo. Ver también retraso.
Lecciones aprendidas [Salida / Entrada]. El aprendizaje obtenido del proceso de realización del
proyecto. Lecciones aprendidas pueden
ser identificado en cualquier punto. También se consideró un registro de proyecto, para ser incluido en
la base de conocimiento de lecciones aprendidas.
Nivel de esfuerzo (LOE). Actividad de tipo de soporte (por ejemplo, enlace de vendedor o cliente,
contabilidad de costos del proyecto, proyecto
gestión, etc.), que no produce productos finales definitivos. Generalmente se caracteriza por un
uniforme
tasa de desempeño laboral durante un período de tiempo determinado por las actividades apoyadas.
Page 134
122
GLOSARIO
Arrasamiento. Ver nivelación de recursos.
Lógica. Ver lógica de red.
Diagrama de lógica. Ver diagrama de red del cronograma del proyecto .
Relación lógica Una dependencia entre dos actividades del cronograma del proyecto, o entre un
actividad y un hito de horario. Los cuatro tipos posibles de relaciones lógicas son: de principio a
fin; acabado a
terminar; inicio a inicio; y de principio a fin. Consulte también relación de precedencia, fin a
fin (FF), fin a inicio
(FS), de principio a fin y de principio a inicio.
Horario maestro [herramienta]. Un cronograma del proyecto a nivel de resumen que identifica los
principales entregables y el trabajo.
componentes de la estructura de desglose e hitos clave del cronograma. Ver también calendario de
hitos .
Medio. El tipo de material utilizado para almacenar un documento. Los medios consisten en material
encuadernado en copia impresa, copia impresa
material no vinculado, material de copia electrónica, material electrónico, firmware y software.
Metodología. Un sistema de prácticas, técnicas, procedimientos y reglas utilizados por quienes
trabajan en un
disciplina.
Hito. Un punto o evento significativo en el proyecto. Vea también el hito del horario.
Calendario de hitos [Herramienta]. Un cronograma de nivel de resumen que identifica los principales
hitos del cronograma. Ver también
horario principal .
Duración más probable. El número total de períodos de trabajo en unidades de calendario asignadas
para realizar el cronograma.
actividad, considerando todas las variables que podrían afectar el rendimiento, y se determina que es
la más probable
Actividad casi crítica. Una actividad programada que tiene baja flotación total. El concepto de casi
crítico es igualmente
aplicable a una actividad de programación o ruta de red de programación. El límite por debajo del cual
el flotador total se considera cercano
crítico está sujeto al juicio de expertos y varía de un proyecto a otro.
Red. Vea también el diagrama de red del cronograma del proyecto.
Análisis de red. Ver calendario de análisis de red.
Lógica de red. La colección de dependencias de actividades de programación que conforma una red
de programación de proyectos.
diagrama.
Ruta de red. Cualquier serie continua de actividades programadas relacionadas con relaciones lógicas
en un proyecto
programar diagrama de red.
Nodo. Uno de los puntos definitorios de una red de horarios; un punto de unión unido a algunos o
todos los demás
lineas de dependencia. Consulte también el método de diagrama de flechas (ADM) y el método de
diagrama de precedencia (PDM).
135
123
GLOSARIO
Período no laboral. Una fecha o parte de una fecha identificada como un tiempo para no realizar el
trabajo, incluido el designado
vacaciones. Cada fecha se puede dividir en unidades de calendario, como turnos, horas o incluso
minutos que pueden
ser designado como el período específico no laboral.
Final abierto. Una actividad sin predecesor, sucesor o ambos. Debería haber solo dos actividades /
hitos
en un cronograma con fines abiertos: inicio y finalización del proyecto.
Duración optimista. El número total de períodos de trabajo en unidades de calendario asignadas para
realizar el cronograma.
la más corta
posible duración.
Organización. Un grupo de personas organizadas para algún propósito o para realizar algún tipo de
trabajo dentro de un
empresa.
Duración original La duración de la actividad originalmente asignada a una actividad programada y
no actualizada como progreso
se informa sobre la actividad. Normalmente se usa para comparar con la duración real y la duración
restante cuando
informar el progreso del cronograma. Vea también la duración original de la actividad, duración
original del proyecto.
Salida [ Salida del proceso]. Un producto, resultado o servicio generado por un proceso. Puede ser
una entrada para un sucesor
proceso.
Porcentaje completo (PC o PCT). Una estimación, expresada como un porcentaje, de la cantidad de
trabajo que ha sido
completado en una actividad o un componente de estructura de desglose de trabajo.
Realizar control de cambio integrado [proceso]. El proceso de revisar todas las solicitudes de
cambio, aprobar
cambios y control de cambios en entregables y activos de procesos organizacionales.
Medición del rendimiento de referencia. Un plan de alcance integrado, cronograma y costo
aprobado para el proyecto
trabajo contra el cual se compara la ejecución del proyecto para medir y administrar el
desempeño. Técnica y de calidad
También se pueden incluir parámetros. Ver también línea de base.
Duración pesimista. El número total de períodos de trabajo en unidades de calendario asignadas para
realizar el cronograma.
la más larga
posible duración de la actividad.
Fase. Ver también fase del proyecto.
Progreso de trabajo físico. La cantidad de trabajo realizado físicamente en el proyecto o tarea. Esto
podría ser
diferente de la cantidad de esfuerzo o dinero gastado en el proyecto o tarea. Técnicas predeterminadas
de
reclamar el progreso del trabajo físico que se seleccionó durante la planificación del proyecto se
utiliza para acreditar el valor ganado
cuando el trabajo está parcialmente completo en el momento del informe de progreso.
Duración planificada. Vea también la duración original de la actividad y la duración original del
proyecto.
Fecha de finalización planificada (PF). Consulte también la fecha de finalización programada .
Page 136
124
GLOSARIO
Fecha de inicio planificada (PS). Ver fecha de inicio programada.
Práctica. Un tipo específico de actividad profesional o gerencial que contribuye a la ejecución de un
proceso.
y eso puede emplear una o más técnicas y herramientas.
Método de diagrama de precedencia (PDM) [Técnica]. Una técnica de diagramación de red
programada en la que
Las actividades de programación están representadas por cuadros (o nodos). Las actividades del
cronograma están vinculadas gráficamente por uno o
relaciones más lógicas para mostrar la secuencia en la que se realizarán las actividades. Ver
también flecha
Método de diagramación (ADM).
Relación de precedencia. El término utilizado en el método de diagramación de precedencia para una
relación lógica.
Sin embargo, en el uso actual, la relación de precedencia, la relación lógica y la dependencia son
ampliamente utilizadas.
indistintamente, independientemente del método de diagramación utilizado. Ver también relación
lógica.
Actividad predecesora. La actividad programada que determina cuándo puede comenzar la actividad
sucesora lógica
o fin.
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 actividades con fechas planificadas, duraciones, fechas clave y
asignación de recursos.
Procedimiento. Una serie de pasos seguidos en un orden definitivo regular 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 elemento final en sí mismo o
un elemento componente.
Palabras adicionales para productos son material y bienes. Contraste con resultado y servicio . Ver
también entregable.
Definición del producto. Las características y funciones que caracterizan un producto, servicio o
resultado. Ver también alcance.
Descripción del alcance del producto. La descripción narrativa documentada del alcance del
producto.
Elaboración Progresiva [Técnica]. Mejorar y detallar continuamente un plan como más detallado y
específico.
La información y las estimaciones más precisas están disponibles a medida que avanza el proyecto y,
por lo tanto, producen
Planes más precisos y completos que resultan de las sucesivas iteraciones del proceso de planificación.
Proyecto. Un esfuerzo temporal realizado 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 el
inicio real del proyecto.
fecha del proyecto y la fecha de datos de la instancia del modelo de programación, si el proyecto está
en progreso o el
fecha de finalización real del proyecto, si el proyecto está completo. Ver 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 del último horario
actividad en el proyecto. Ver también fecha de finalización real.
137
125
GLOSARIO
Fecha de inicio real del proyecto. El punto en el tiempo asociado con la fecha de inicio real de la
actividad del primer horario
actividad en el proyecto.
Atributos del proyecto. Múltiples atributos asociados con cada proyecto único que se pueden incluir
dentro del
modelo de horario. Los atributos del proyecto incluyen, entre otros, el identificador del proyecto, el
nombre del proyecto y el proyecto.
descripción, declaración del alcance del proyecto, calendario del proyecto y calendarios de recursos
asignados.
Duración de referencia del proyecto. El número total de períodos de trabajo en unidades de
calendario necesarios para ejecutar el aprobado
cronograma del proyecto de referencia para el proyecto.
Fecha de finalización de la línea de base del proyecto. El punto en el tiempo asociado con la
finalización de la última actividad de programación en
una línea base aprobada del cronograma del proyecto. Consulte también la fecha de finalización
actual del proyecto .
Fecha de inicio de la línea de base del proyecto. El punto en el tiempo asociado con el comienzo de
la primera actividad de programación en
una línea base aprobada del cronograma del proyecto. Consulte también la fecha de inicio actual del
proyecto.
Fecha de inicio del proyecto. El punto en el tiempo establecido por la fecha de inicio temprano del
proyecto según lo determinado por una red de programación
análisis o según lo establecido por una restricción de inicio de proyecto. También conocido como
fecha de inicio del proyecto.
Calendario de proyectos. Un calendario de días hábiles o turnos que establece esas fechas en las que
el horario
Las actividades son días trabajados y no laborables que determinan esas fechas en las que las
actividades del horario están inactivas.
Normalmente define días festivos, fines de semana y horas de turno. Vea también el calendario de
recursos y el calendario de actividades.
Fecha de finalización del proyecto. Ver fecha de finalización del proyecto.
Estimación de costos del proyecto. El costo estimado para todo el proyecto.
Proyecto Ruta Crítica. La ruta de red de programación más larga desde la fecha de inicio del
proyecto o los datos del proyecto actual
fecha hasta la fecha de finalización del proyecto. Ver también ruta crítica.
Fecha de finalización actual del proyecto. La estimación actual del momento en el que se realizó la
última actividad programada en el
se completará el proyecto, donde la estimación refleja cualquier progreso de trabajo informado. Ver
también la fecha de finalización actual,
fecha de finalización programada del proyecto y fecha de finalización de la línea base del proyecto.
Fecha de inicio actual del proyecto. La estimación actual del punto en el tiempo cuando la primera
actividad programada en el
comenzará el proyecto, donde la estimación refleja cualquier progreso de trabajo informado. Ver
también fecha de inicio actual, proyecto
fecha de inicio programada y fecha de inicio de referencia del proyecto.
Descripción del Proyecto. Resumen narrativo documentado de la declaración 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 temprano del proyecto y
La fecha de finalización temprana del proyecto. Ver también duración (DU o DUR).
Porcentaje de duración del proyecto completado. Una estimación, expresada como el porcentaje
que el proyecto real
duración es la duración total del proyecto para un proyecto que tiene trabajo en progreso.
Page 138
126
GLOSARIO
Variación de duración del proyecto. Una desviación, salida o divergencia cuantificable lejos de una
duración dada para
un proyecto.
Proyecto Fecha de finalización temprana. El punto de tiempo más temprano posible asociado con la
finalización del último
programar la actividad del proyecto. Ver también la fecha de finalización temprana.
Fecha de inicio temprano del proyecto. El punto de tiempo más temprano posible asociado con el
comienzo del primer horario
actividad del proyecto. Ver también la 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 una red de programación
análisis o según lo establecido por una restricción de finalización de proyecto. También conocido
como fecha de finalización del proyecto.
Restricción de finalización del proyecto. Una limitación o restricción colocada en la fecha de
finalización tardía del proyecto que afecta cuando el
el proyecto debe finalizar y generalmente tiene la forma de una fecha de imposición 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.
Generalmente calificado por uno de los siguientes: real, de referencia, actual, temprano, tardío,
programado u objetivo. Ver también
fecha de finalización .
Proyecto Finish Variance. Una desviación, salida o divergencia cuantificable de una línea base
conocida del horario
fecha de finalización o fecha de finalización del proyecto. Puede expresarse como un porcentaje o
número de períodos de trabajo.
Identificador del proyecto. Una identificación numérica o de texto única y breve asignada a cada
proyecto para diferenciar un
proyecto particular de otros proyectos en un programa.
Proyecto Fecha de finalización tardía. El último punto de tiempo posible asociado con la
finalización del último horario
actividad del proyecto.
Fecha de inicio tardío del proyecto. El último punto de tiempo posible asociado con el comienzo del
primer horario
actividad del proyecto.
Plan de gestión del proyecto [Producto / Aporte]. Un documento formal y aprobado que define cómo
es el proyecto.
ejecutado, monitoreado y controlado. Puede ser resumido o detallado y puede estar compuesto por uno
o más
planes de gestión subsidiarios y otros documentos de planificación.
Software de gestión de proyectos [Herramienta]. Una clase de aplicaciones de software diseñadas
específicamente
para ayudar al equipo de gestión del proyecto a planificar, monitorear y controlar el proyecto,
incluyendo: costo
estimación, programación, comunicaciones, colaboración, gestión de configuración, control de
documentos, registros
gestión y análisis de riesgos.
Equipo de gestión de proyectos. Los miembros del equipo del proyecto que participan directamente
en el proyecto.
Actividades de gestión. En algunos proyectos más pequeños, el equipo de gestión del proyecto puede
incluir prácticamente todos
Los miembros del equipo del proyecto.
Gerente de Proyecto (PM). La persona asignada por la organización ejecutora para lograr el
proyecto.
objetivos
Page 139
127
GLOSARIO
Nombre del proyecto. Una frase o etiqueta corta para cada proyecto , utilizada junto con
el identificador del proyecto para
diferenciar un proyecto particular de otros proyectos en un programa . También conocido como título
del proyecto.
Duración original del proyecto. La estimación inicial del número total de períodos de trabajo en
unidades de calendario necesarios para
completar un proyecto Por lo general, se determina a partir de la ruta de red más larga inicial a través
del proyecto.
Fase del proyecto. Una colección de actividades de proyectos relacionados lógicamente, que
generalmente culminan en la finalización de un
entregable mayor. Las fases del proyecto (también llamadas fases) se completan principalmente de
forma secuencial, pero pueden superponerse en
Algunas situaciones del proyecto. Las fases se pueden subdividir en subfases y luego
componentes; esta jerarquía, si el
proyecto o partes del proyecto se dividen en fases, está contenido en la estructura de desglose del
trabajo. Un proyecto
La fase es un componente del ciclo de vida de un proyecto. Una fase de proyecto no es un Grupo de
proceso de gestión de proyectos.
Proyecto Porcentaje físico completo. Un cálculo, expresado como un porcentaje, de la cantidad
de trabajo que tiene
completado en el proyecto, medido en términos de progreso del trabajo físico.
Fecha de finalización planificada del proyecto. Vea 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 temprana del proyecto de un proyecto que tiene al
menos una fecha de inicio real de actividad. Esta
representa el tiempo necesario para completar un proyecto donde el trabajo está en progreso. Ver
también la duración restante.
Calendario del proyecto [Producto / Aporte]. Una salida de una instancia de modelo de
programación que presenta el tiempo basado
información requerida por el plan de comunicación, incluidas actividades con fechas planificadas,
duraciones, hitos
fechas y asignación de recursos. Ver también presentación.
Calendario de proyecto Diagrama de red [Salida / Entrada]. Cualquier visualización esquemática de
las relaciones lógicas entre
Las actividades del cronograma del proyecto. Dibujado siempre de izquierda a derecha para reflejar la
cronología del trabajo del proyecto.
Fecha de finalización programada del proyecto. El punto en el tiempo cuando el trabajo estaba
programado para completarse en un proyecto. los
la fecha de finalización programada del proyecto normalmente está dentro del rango de fechas
delimitadas por la fecha de finalización temprana del proyecto y
La fecha de finalización tardía del proyecto. Puede reflejar la nivelación final de recursos de recursos
escasos. A veces llamado proyecto
Fecha de finalización prevista. Consulte también la fecha de finalización actual del proyecto , la fecha
de finalización programada.
Fecha de inicio programada del proyecto. El momento en que el trabajo estaba programado para
comenzar en el proyecto. El proyecto
la fecha de inicio programada normalmente está dentro del rango de fechas delimitadas por la fecha de
inicio temprano del proyecto y
fecha de inicio tardío del proyecto. Puede reflejar la nivelación inicial de recursos de recursos
escasos. También conocido como proyecto planeado
fecha de inicio. Consulte también la fecha de inicio actual del proyecto, la fecha de inicio
programada .
Alcance del proyecto. El trabajo que debe realizarse para entregar un producto, servicio o resultado
con el especificado
caracteristicas y funciones. Ver también alcance .
Declaración de Alcance del Proyecto [Producto / Aporte]. La descripción narrativa del alcance del
proyecto, incluidos los principales
entregables, objetivos del proyecto, suposiciones del proyecto, restricciones del proyecto y una
declaración de trabajo, que proporciona un
140
128
GLOSARIO
base documentada para tomar decisiones futuras del proyecto y para confirmar o desarrollar un
entendimiento común
del alcance del proyecto entre los interesados. La definición del alcance del proyecto: lo que debe
lograrse.
Patrocinador de proyecto. Ver patrocinador.
Proyecto Stakeholder. Ver partes interesadas.
Restricción de inicio de proyecto. Una limitación o restricción colocada en la fecha de inicio
temprano del proyecto que afecta cuando el
el proyecto debe comenzar y generalmente tiene la forma de una fecha de imposición fija.
Fecha de inicio del proyecto. Un punto en el tiempo asociado con el comienzo de la primera
actividad programada en un proyecto. Generalmente
calificado por uno de los siguientes: real, de referencia, actual, temprano, tardío, programado u
objetivo. Ver también fecha de inicio .
Variación de la fecha objetivo del proyecto. Una desviación, salida o divergencia cuantificable de
un proyecto conocido
fecha de inicio objetivo o fecha de finalización objetivo del proyecto.
Duración objetivo del proyecto. El número total estimado de períodos de trabajo en unidades de
calendario, necesarios para completar
el proyecto según lo determinado por un cronograma objetivo específico del proyecto.
Fecha objetivo de finalización del proyecto. El punto en el tiempo seleccionado por el planificador
establecido por el análisis de red programado para
finalización de una versión específica del cronograma del proyecto.
Fecha de inicio objetivo del proyecto. El punto en el tiempo seleccionado por el planificador
establecido por el análisis de red programado para
comenzando una versión específica del cronograma del proyecto.
Equipo de proyecto. Todos los miembros del equipo del proyecto, incluido el equipo de gestión del
proyecto, el gerente del proyecto.
y, para algunos proyectos, el patrocinador del proyecto.
Miembros del equipo del proyecto. Las personas que informan directa o indirectamente al gerente
del proyecto y que
son responsables de realizar el trabajo del proyecto como parte regular de sus tareas asignadas.
Gestión del tiempo del proyecto [Área de conocimiento]. Project Time Management incluye los
procesos necesarios para
lograr la finalización oportuna del proyecto. Los procesos de Gestión del tiempo del proyecto incluyen
Definir actividades,
Actividades de secuencia, recursos estimados de actividad, duraciones estimadas de actividad,
desarrollo de cronograma y control
Programar.
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 progreso, incluye la duración real del proyecto más la duración restante del proyecto.
Proyecto de trabajo. Ver trabajo
Linea de relacion. Una línea de relación lógica dibujada dentro de un diagrama de red del
cronograma del proyecto a partir de uno
programar actividades para una o más actividades de programación que indiquen el tipo de relación
lógica por parte del
posición relativa de los puntos inicial y final de la línea.
141
129 129
GLOSARIO
Duración restante (RD). El tiempo en unidades de calendario, (a) igual a la duración original de una
actividad que tiene
no iniciado o (b) entre la fecha de datos del cronograma del proyecto y la fecha de finalización de una
actividad de cronograma que
tiene una fecha de inicio real Esto representa el tiempo necesario para completar una actividad
programada en la que se encuentra el trabajo.
Progreso. Consulte también la duración restante de la actividad, la duración restante del proyecto.
Columna de informe. Un área de visualización vertical en el cuerpo del documento que representa un
componente de datos o una pieza de
información, como un grupo de proyecto, grupo de actividad o grupo de recursos.
Descripción de los datos del informe. Una breve descripción de texto de un componente de datos en
el informe.
Informe de cuadrículas. Líneas horizontales y verticales dentro de un documento correspondiente a
componentes de datos, como
unidades de tiempo o filas en un gráfico de barras.
Informe de fila. Un área de visualización horizontal en el cuerpo del documento que representa un
componente de datos o una pieza de
información, como un grupo de actividades o un grupo de recursos.
Tabla de informes Una pantalla formateada en filas y columnas de informe, como un documento que
presenta tiempo
información columnar escalada relacionada con el horario.
Requisito. Una condición o capacidad que debe cumplir o poseer un sistema, producto, servicio,
resultado o
componente para satisfacer un contrato, norma, especificación u otros documentos impuestos
formalmente. Requisitos
incluir las necesidades, deseos y expectativas cuantificadas y documentadas del patrocinador, el
cliente y otros
partes interesadas
Recurso. Recursos humanos calificados (disciplinas específicas, ya sea individualmente o en equipos
o equipos), equipos,
servicios, suministros, productos, presupuestos o fondos.
Solicitud de recursos. El porcentaje de la duración del recurso que se estima que aplica el recurso
asignado
al trabajo de la actividad del horario.
Asignación de recursos. La vinculación de uno o más recursos a una actividad programada e
identificación del
cantidad de cada recurso que se necesita para realizar el trabajo en la actividad de ese horario.
Atributos de recursos. Múltiples atributos asociados con cada recurso que se pueden incluir dentro
del recurso
biblioteca. Los atributos del recurso incluyen el identificador del recurso, el nombre del recurso, el
tipo de recurso, la disponibilidad del recurso,
tasa de recursos, código de recursos, restricciones y suposiciones.
Disponibilidad de recursos. Las fechas y el número de períodos de trabajo en unidades de calendario
que es un recurso determinado
disponible de acuerdo con el calendario de recursos apropiado.
Calendario de recursos. Un calendario de días laborables y días no laborables que determina
las fechas en que
cada recurso específico está inactivo o puede estar activo. Por lo general, define vacaciones
específicas de recursos y recursos
períodos de disponibilidad. Consulte también biblioteca de calendarios, calendario de
proyectos y calendario de actividades.
Page 142
130
GLOSARIO
Programa de recursos limitados. Ver horario de recursos limitados.
Diccionario de recursos. Ver biblioteca de recursos.
Duración del recurso. El número de períodos de trabajo en unidades de calendario que se estima que
el recurso asignado gastará
en la ejecución del trabajo de la actividad programada.
Grupo de recursos. Un miembro del equipo del proyecto seleccionó un conjunto de recursos que
comparten algunos atributos de recursos comunes
que permite que esos recursos se notifiquen o se muestren por separado, como agruparse en un gráfico
monitor.
Identificador de recursos. Una identificación numérica o de texto única y breve asignada a cada
recurso específico para
diferenciar ese recurso de otros recursos. Los identificadores de recursos suelen ser únicos dentro de
cualquiera
proyecto.
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
trabajar en la actividad del horario.
Nivelación de recursos [Técnica]. Cualquier forma de análisis de red programada en la que las
decisiones de programación (inicio
y las fechas de finalización) se deben a limitaciones de recursos (p. ej., disponibilidad limitada de
recursos o dificultades de administración
cambios en los niveles de disponibilidad de recursos). Consulte también el cronograma de recursos
limitados y el análisis de red de cronograma.
Biblioteca de recursos. Una tabulación documentada que contiene la lista completa, incluidos los
atributos de recursos, de todos
recursos que pueden asignarse a actividades del proyecto. También conocido como diccionario de
recursos.
Programa de recursos limitados. Un cronograma del proyecto cuya actividad de cronograma, fechas
de inicio programadas y programada
las fechas de finalización reflejan la disponibilidad de recursos esperada. Un horario con recursos
limitados no tiene ningún horario temprano o tardío
fechas de inicio o finalización. La flotación total de la programación con recursos limitados se
determina calculando la diferencia
entre la fecha de finalización tardía del método de ruta crítica y la fecha de finalización programada
con recursos limitados. También conocido
como horario limitado de recursos. Ver también nivelación de recursos.
Nombre del recurso. Una frase corta o etiqueta para cada recurso utilizado junto con un identificador
de recurso para
diferenciar ese recurso de otros recursos. El nombre del recurso normalmente diferencia un recurso
por tipo,
rol, o individual.
Planeación de recursos. Ver actividad de estimación de recursos.
Tasa de recursos. La tasa de costo unitario asignada a un recurso específico, incluidas las escaladas
de tasas conocidas.
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. Los
resultados incluyen resultados
(p. ej., sistemas integrados, proceso revisado, organización reestructurada, pruebas, personal
capacitado, etc.) y
documentos (por ejemplo, políticas, planes, estudios, procedimientos, especificaciones, informes,
etc.). Contraste con producto y
Servicio. Ver también entregable.
Page 143
131
GLOSARIO
Papel. Una función definida que debe realizar un miembro del equipo del proyecto, como probar,
archivar, inspeccionar,
codificación.
Programar. Ver cronograma del proyecto y modelo de cronograma.
Programar actividad. Un componente discreto programado del trabajo realizado durante el curso de
un proyecto. UNA
la actividad del cronograma normalmente tiene una duración estimada, un costo estimado y requisitos
de recursos estimados.
Las actividades de programación están conectadas a otras actividades de programación o hitos de
programación con relaciones lógicas,
y se descomponen de los paquetes de trabajo. Ver también actividad .
Análisis de horarios. Consulte también el análisis de la red programada.
Programar compresión [técnica]. Acortar la duración del cronograma del proyecto sin reducir el
proyecto.
alcance. Consulte también bloqueo y seguimiento rápido.
Programar compresión. Técnicas utilizadas para acortar la duración del cronograma sin reducir el
alcance del proyecto.
Nivel de horario. Una regla especificada por el equipo del proyecto para la granularidad relativa de
las actividades del cronograma en general
modelo de horario.
Programar hito. Un evento significativo en el cronograma del proyecto, como un evento que restrinja
el trabajo futuro
o marcar la finalización de una entrega importante. Un hito de programación tiene cero
duración. También conocido como
actividad de hito. Ver también hito.
Modelo de programa [herramienta]. Una representación dinámica del plan para ejecutar las
actividades del proyecto desarrollado.
por las partes interesadas del proyecto aplicando el método de programación a una herramienta de
programación utilizando datos específicos del proyecto
tales como listas de actividades y atributos de actividad. El modelo de programación puede procesarse
mediante una herramienta de programación para
producir varias instancias de modelo de programación. (método de programación más herramienta de
programación más datos específicos del proyecto
modelo de horario igual).
Programar instancia de modelo [Herramienta]. Una copia 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 (completado
ciclo de actualización), que se guarda para el registro y la referencia, como la versión de la fecha de
datos, los modelos de programación objetivo y el
modelo de cronograma de referencia. Las instancias producen varias presentaciones de cronograma,
como rutas críticas, recursos
perfiles, asignaciones de actividades, registro de logros, etc. y puede proporcionar pronósticos basados
en el tiempo, a lo largo de
El ciclo de vida del proyecto. Cuando se usan juntas, las instancias admiten análisis, como el análisis
de varianza.
Análisis de la red del horario [técnica]. La técnica de identificación de fechas de inicio temprano y
tardío, así como
fechas de finalización temprana y tardía, para las porciones incompletas de las actividades del
cronograma del proyecto. Ver también pase hacia atrás,
método de ruta crítica, método de cadena crítica y nivelación de recursos.
Índice de rendimiento de programación (SPI). Una medida de la eficiencia del cronograma en un
proyecto. Es la proporción de ganado
valor (EV) al valor planificado (PV). El SPI EV dividido por PV. Un SPI igual o mayor que uno
indica
Una condición favorable y un valor inferior a uno indica una condición desfavorable. Ver
también valor ganado
técnica (EVT).
Page 144
132
GLOSARIO
Variación de horario (SV). Una medida del rendimiento del cronograma en un proyecto. Es la
diferencia algebraica entre
el valor ganado (EV) y el valor planificado (PV). SV EV menos PV. Ver también la técnica del valor
ganado (EVT).
Fecha de finalización programada (SF). El momento en que el trabajo estaba programado para
terminar en una actividad programada. los
la fecha de finalización programada normalmente está dentro del rango de fechas delimitadas por la
fecha de finalización temprana y la finalización tardía
fecha. Puede reflejar la nivelación de recursos de recursos escasos. A veces se llama fecha de
finalización planificada. Ver también
fecha de finalización actual, fecha de finalización programada de actividad, fecha de finalización
programada del proyecto .
Fecha de inicio programada (SS). El momento en que el trabajo estaba programado para comenzar
en una actividad programada. los
la fecha de inicio programada normalmente está dentro del rango de fechas delimitadas por la fecha de
inicio temprano y el inicio tardío
fecha. Puede reflejar la nivelación de recursos de recursos escasos. A veces se llama fecha de inicio
planificada. Ver también
fecha de inicio actual, fecha de inicio programada de actividad, fecha de inicio programada del
proyecto .
Método de programación Un sistema de prácticas, técnicas, procedimientos y reglas utilizadas por la
programación del proyecto.
planificadores Esta metodología se puede realizar de forma manual o con un software de gestión de
proyectos.
específicamente utilizado para programar.
Herramienta de programación [Herramienta]. Una herramienta que proporciona nombres de
componentes de programación, definiciones, relaciones estructurales,
y formatos que admiten la aplicación de un método de programación.
Alcance. La suma de los productos, servicios y resultados que se proporcionarán como proyecto. Ver
también alcance del proyecto y
definición del producto.
Servicio. Trabajo útil realizado que no produce un producto o resultado tangible, como realizar
cualquiera de los
funciones comerciales que apoyan la producción o distribución. Contraste
con producto y resultado . Ver también entregable.
Flojo. Ver flotación total (TF) y flotación libre (FF).
Especificación. Un documento que especifica, de manera completa, precisa y verificable, los
requisitos, el diseño,
comportamiento u otras características de un sistema, componente, producto, resultado o servicio y, a
menudo, los procedimientos
para determinar si estas disposiciones se han cumplido. Los ejemplos son: especificación de
requisitos, diseño
especificación, especificación de producto y especificación de prueba.
Ruta crítica especificada. La secuencia más larga de actividades programadas en un miembro del
equipo del proyecto especificado
Programar ruta de red. Ver también ruta crítica.
Patrocinador. La persona o grupo que proporciona los recursos financieros, en efectivo o en especie,
para el proyecto.
Tenedor de apuestas. Persona u organización (p. Ej., Cliente, patrocinador, organización ejecutora o
el público) que es
activamente involucrado en el proyecto, o cuyos intereses pueden verse afectados positiva o
negativamente por la ejecución o
finalización del proyecto. Una parte interesada también puede ejercer influencia sobre el proyecto y
sus entregables.
Estándar. Un documento establecido por consenso y aprobado por un organismo reconocido que
proporciona, para
uso común y repetido, reglas, pautas o características para actividades o sus resultados, dirigido a
logro del grado óptimo de orden en un contexto dado.
Page 145
133
GLOSARIO
Fecha de inicio. Un punto en el tiempo asociado con el inicio de una actividad programada,
generalmente calificado por uno de los siguientes:
real, planificado, estimado, programado, temprano, tardío, objetivo, línea base o actual. Ver también
la fecha de inicio de la actividad,
fecha de inicio del proyecto .
Comience no antes de. Una restricción de programación colocada en la actividad de programación
que afecta cuando una programación
comienzo no anterior a la restricción
evita que la actividad de programación se programe para comenzar antes de la fecha impuesta.
Comience no más tarde que. Una restricción de programación colocada en la actividad de
programación que afecta cuando una programación
comienzo no posterior a la restricción
evita que la actividad programada se programe para comenzar más tarde que la fecha impuesta.
Comienza en. Una restricción de programación colocada en la actividad de programación que afecta
cuando una actividad de programación puede
ser programado y generalmente tiene la forma de una fecha de imposición fija. Una restricción Start
On requiere el horario
actividad para comenzar en una fecha específica.
De principio a fin (SF). La relación lógica donde la finalización de la actividad del cronograma
sucesor depende
tras el inicio de la actividad de programación predecesora. Ver también relación lógica.
StarttoStart (SS). La relación lógica donde el inicio del trabajo de la actividad del cronograma
sucesor
depende del inicio del trabajo de la actividad de programación predecesora. Ver también relación
lógica.
Declaración de trabajo (SOW). Una descripción narrativa de los productos, servicios o resultados
que se proporcionarán.
Situación a la fecha. Un término cuyo significado para el informe de datos de estado varía según la
marca de gestión del proyecto
software 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. Consulte también la fecha de datos o la fecha actual.
Subred. Una subdivisión (fragmento) de un diagrama de red del cronograma del proyecto, que
generalmente representa un
subproyecto o un paquete de trabajo. A menudo se usa para ilustrar o estudiar alguna condición
potencial o propuesta del cronograma,
tales como cambios en la lógica de programación preferencial o el alcance del proyecto. Ver
también resumen de actividad.
Subfase Una subdivisión de una fase.
Subproyecto Una porción más pequeña del proyecto general creado cuando un proyecto se subdivide
en más manejable
componentes o piezas. Los subproyectos generalmente se representan en la estructura de desglose del
trabajo. Un subproyecto
puede denominarse proyecto, gestionarse como proyecto y adquirirse de un vendedor. Puede ser
referido como un
subred en un diagrama de red del cronograma del proyecto. Ver también resumen de actividad.
Finalización sustancial. El punto cuando la lógica de la red programada y los requisitos entregables
de la
la actividad programada está satisfecha y las actividades sucesoras pueden comenzar.
Sucesor. Ver actividad sucesora .
Actividad sucesora. La actividad de programación que sigue a una actividad predecesora, según lo
determinado por su lógica
relación.
Page 146
134
GLOSARIO
Resumen de la actividad. Una representación única de actividades agregadas por atributos comunes
dentro del cronograma.
modelo. Ver también subproyecto y subred .
Sistema. Un conjunto integrado de componentes que interactúan regularmente o son
interdependientes creados para lograr un determinado
objetivo, con relaciones definidas y mantenidas entre sus componentes y el conjunto productor u
operativo
mejor que la simple suma de sus componentes. Los sistemas pueden estar basados en procesos físicos
o en administración
basado en procesos, o más comúnmente una combinación de ambos. Los sistemas para la gestión de
proyectos se componen de proyectos.
Procesos de gestión, técnicas, metodologías y herramientas operadas por el equipo de gestión del
proyecto.
Duración objetivo. Consulte Duración objetivo de la actividad y duración objetivo del proyecto.
Fecha objetivo de finalización. Consulte la fecha de finalización objetivo de la actividad y la fecha
de finalización objetivo del proyecto.
Horario objetivo. Un cronograma adoptado para fines de comparación durante el análisis de red de
cronograma, que puede
ser diferente del cronograma de referencia. Ver también línea de base.
Fecha de inicio objetivo. Consulte la fecha de inicio objetivo de la actividad y la fecha de inicio
objetivo del proyecto.
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, industria y marca de 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,
Organización y presentación de información y datos. Las plantillas a menudo se basan en documentos
creados durante
proyectos Las plantillas pueden reducir el esfuerzo necesario para realizar el trabajo y aumentar la
consistencia de los resultados.
Estimación de tres puntos [técnica]. Una técnica analítica que utiliza tres estimaciones de costo o
duración para
representan los escenarios optimistas, más probables y pesimistas. Esta técnica se aplica para mejorar
el
precisión de las estimaciones de costo o duración cuando la actividad subyacente o el componente de
costo es incierto.
Fecha de hora actual. Ver datos fecha.
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. Generalmente se muestra arriba 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, utilizado 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.
Flotador total (TF). La cantidad total de tiempo que una actividad programada puede retrasarse desde
su fecha de inicio temprano de CPM
o la fecha de finalización anticipada de CPM sin retrasar la fecha de finalización del proyecto o violar
una restricción de programación. Calculado
Page 147
135
GLOSARIO
utilizando la técnica del método de ruta crítica y determinando la diferencia entre las fechas de
finalización temprana de CPM
y fechas de finalización tardía de CPM. Ver también ( flotador, flotador libre FF).
Unidad de medida. Una designación del tipo de cantidad que se está midiendo, 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. Ver
también cliente.
Diferencia. Una desviación, salida o divergencia cuantificables lejos de una línea base conocida o
valor esperado.
Umbral de variación. Un rango predeterminado de resultados normales que se determina durante la
planificación
procesar y establecer los límites dentro de los cuales el equipo practica la administración por
excepción.
Trabajo. Esfuerzo físico o mental sostenido, esfuerzo o ejercicio de habilidad para superar obstáculos
y lograr un
objetivo.
Estructura de desglose del trabajo (WBS) [Salida / Entrada]. Una descomposición jerárquica
orientada a la entrega de la
El trabajo debe ser ejecutado por el equipo del proyecto para lograr los objetivos del proyecto y crear
los entregables requeridos.
Organiza y define el alcance total del proyecto. Cada nivel descendente representa un nivel cada vez
más detallado
definición del trabajo del proyecto. La WBS se descompone en paquetes de trabajo. La orientación
entregable de la
jerarquía incluye entregables internos y externos. Consulte también paquete de trabajo, cuenta de
control (CA) y
estructura de desglose del trabajo por contrato (CWBS).
Desglose del trabajo Estructura Componente. Una entrada en la estructura de desglose del trabajo
que puede estar en cualquier nivel.
Identificador de elemento PEP. Una identificación numérica o de texto única y breve asignada a
cada desglose de trabajo
elemento o componente de estructura (WBS) para diferenciar un elemento WBS particular de otros
elementos WBS. los
El identificador de elemento WBS es típicamente único dentro de cualquier estructura completa de
desglose de trabajo.
Paquete de trabajo. Un componente de trabajo entregable o de proyecto en el nivel más bajo de cada
rama del trabajo
estructura de desglose. El paquete de trabajo incluye las actividades del cronograma y los hitos del
cronograma requeridos para
completar el paquete de trabajo entregable o componente de trabajo del proyecto. Ver también cuenta
de control (CA).
Información de rendimiento laboral [Salida / Entrada]. Información y datos sobre el estado del
Actividades que se realizan para realizar el trabajo del proyecto, recopiladas como parte del proyecto
directo y de gestión.
procesos de ejecución La información incluye: estado de los entregables; estado de implementación
para solicitudes de cambio,
acciones correctivas, acciones preventivas y reparaciones de defectos; estimaciones previstas para
completar; porcentaje reportado
de trabajo realizado físicamente; valor alcanzado de las medidas de rendimiento técnico; fechas de
inicio y finalización de
programar actividades
Período de trabajo. Una fecha o parte de una fecha identificada como un tiempo para realizar el
trabajo. Cada fecha puede dividirse aún más
en unidades de calendario, como turnos, horas o incluso minutos que pueden designarse como el
período de trabajo específico.
Solución alternativa [Técnica]. Una respuesta a un riesgo negativo que ha ocurrido. Distinguido de
contingencia
planifique que no se planifique una solución alternativa antes de que ocurra el evento de riesgo.
148 de 1189.
Page 149
137
UNA
Coste real de la actividad, 45
Duración real de la actividad, 45
Fecha de finalización real de la actividad, 45
Fecha de inicio real de la actividad, 45
Calendario de actividades, 46
Código de actividad, 46
Estructura de codificación de actividad, 2425
Categoría de costo de actividad, 46
Estimación de costo de actividad, 46
Distribución de riesgo de probabilidad acumulativa de actividad, 47
Porcentaje de duración de la actividad completa, 47
Actividad fecha de finalización temprana, 47
Fecha de inicio temprano de la actividad, 47
Actividad esfuerzo / trabajo, 48
ID de actividad, 48
Etiqueta de actividad, 48
Fecha de finalización tardía de la actividad, 48
Fecha de inicio tardío de la actividad, 49
Duración más probable de la actividad, 49
Duración optimista de la actividad, 49
Duración original de la actividad, 49
Porcentaje de actividad completado, 52
Duración pesimista de la actividad, 50
Actividad porcentaje físico completado, 50
Duración restante de la actividad, 50
Cantidad real del recurso de actividad, 51
Fecha de finalización nivelada de recursos de actividad, 51
Fecha de inicio nivelada de recursos de actividad, 51
Cantidad total de recursos de la actividad, 51
Índice de criticidad del riesgo de actividad, 52
Definición del alcance de la actividad, 52
Duración total de la actividad, 52
Reales, 33
Costo real, 45
Duración real, 45, 62
Fecha de finalización real, 45, 62
Fecha de inicio real, 45, 63
Técnica ágil, 16
Analizar salida programada, 31
Aplicabilidad, 5
Aprobar el horario, 32
Lo más tarde posible, 53
Tan pronto como sea posible, 53
Evaluación, conformidad, 3, 79–81
Ver también Evaluación de conformidad
segundo
Pase hacia atrás, 9, 12, 31
Línea de base, 34, 53
Consulte también Programación del desarrollo de la línea base del modelo.
Modelo de cronograma de referencia, 53
Línea de base del modelo de cronograma, 32
Presupuesto al finalizar, 53
Topes, 13–14
do
Calendario, 44, 46
proyecto, 63
recurso, 68
períodos de trabajo y, 2324
Identificador de solicitud de cambio, 54
Recopilar datos reales y trabajo restante, 33
Comunicar, 34
Comunicación, 34, 39
Compare y resuelva cualquier desviación, 34
Componentes, 4, 7, 11, 77–78
Ver también componentes de programación
Evaluación de conformidad, 3, 79–81
Índice de conformidad, 3
Resumen del índice de conformidad, 77–81
evaluación de conformidad, 79–81
programar la utilización de componentes, 78
Restricción, 44
fecha, 37
proyecto terminado, 64
inicio del proyecto, 67
Cuenta de control, 54
Gerente de cuentas de control, 54
Costo, 54–55, 63
actividad, 45, 46
real, 45
tasas / precios de recursos, 69
Índice de rentabilidad, 54
Variación de costo, 55
Porcentaje de variación de costo, 55
ÍNDICE
Page 150
138
ÍNDICE
Estrellarse, 32
Camino crítico, 55
Crear proceso de programación, 3, 7
Actividad crítica, 35
Método de cadena crítica, 9, 12–15
Camino crítico, 35, 55
Método de la ruta crítica (CPM), 9, 28–29
amortiguadores en, 13–14
cadena crítica en comparación con 1415
disponibilidad de recursos y, 12–13
Campo personalizado, 55
re
Datos
formato, 42
proyecto específico, 7
plan de gestión de datos programados, 22
Fecha de datos, 56
Restricción de fecha, 37
Ver también Fecha de finalización; Fecha de inicio
Definir hitos, 27
Diseño de actividades del proyecto, 27
Determinar la duración de cada actividad, 30
Determinar recursos para cada actividad, 30
Desarrollar la línea base del modelo de cronograma, 27
analizar la salida del cronograma, 31
aprobar cronograma, 32
línea de base el modelo de horario, 32
definir hitos, 27
actividades del proyecto de diseño, 27
determinar la duración de cada actividad, 30
determinar recursos para cada actividad, 30
secuencia de actividades, 28
Recursos de conducción, 56
Duración, 44
actividad y, 17, 30–31, 36, 50
real, 45, 62
determinación de, 30–31
distribución de probabilidad, 17
restante, 50, 66
mi
Fecha de finalización anticipada, 47, 64
Fecha de inicio temprano, 47, 64
Valor ganado, 44, 56
Gestión del valor ganado (EVM), 25
Método del valor ganado, 56
Valor ganado peso, 57
Estimación, 36
Costo estimado de la actividad, 46
Recursos estimados de la actividad, 30
Estimación al finalizar, 57
Estimación para completar, 57
Acabado esperado, 58
F
Tampón de alimentación, 13
Fecha de finalización, 31, 44
real, 45, 62
temprano, 47, 64
tarde, 65
Terminar no antes de, 58
Finalizar a más tardar, 58
Terminar el, 59
Fin a fin (FF), 28–29, 59
Finishtostart (FS), 28–29, 59
Valores flotantes, 31–32
Ver también Flotador libre; Flotación total
Diagrama de flujo, para modelo de programación, 10
Flotador libre, 31, 35–36, 60
sol
"Generalmente reconocido", 2
Buena práctica, 2, 21–39, 43
L
Lag, 29, 38, 60, 69
Fecha de finalización tardía, 65
Fecha de inicio tardío, 49, 65
Plomo, 38, 60
Actividad de nivel de esfuerzo (LOE), 28, 36
Enlaces a / de resumen de actividad, 38
METRO
Fecha de finalización obligatoria, 61
Fecha de inicio obligatoria, 61
Mantener registros, 34
Hito, 27, 61
Page 151
139
ÍNDICE
Estructura de codificación de hitos y actividades, 24–25
Simulación de Monte Carlo, 1617
Duración más probable, 49
O
Actividades abiertas, 37
Duración optimista, 49
Duración original, 49
Fuera de la lógica de secuencia, 37–38
Descripción general, 2–3
índice de conformidad, 77–81
de buenas prácticas, 21–39
PAG
Porcentaje completo, 44, 47, 50, 52, 55, 64, 66, 72
Índice de rendimiento
costo, 54
horario, 72
para completar, 75
Indicadores de desempeño, 25
Duración pesimista, 50
Progreso del trabajo físico, 50, 66.
Valor planificado, 62
Planificación
proyecto, 7
recurso, 25
ola rodante, 15
Método de diagrama de precedencia (PDM), 9, 12–13
Presentación, 1, 4
modelo de horario, 71
horario modelo de instancia, 1819, 39
Distribución probabilística de la duración de la actividad, 36
Distribución de probabilidad duración, 17
Distribución de riesgo de probabilidad, 47, 62
Tabla de mapeo de componentes de proceso, 11
Evaluación del programa y técnica de revisión (PERT), 16, 36
Diseño de actividades del proyecto, 27–28
Duración real del proyecto, 62
Fecha de finalización real del proyecto, 62
Fecha de inicio real del proyecto, 63
Buffers de proyecto, 13
Calendario de proyectos, 63
Categoría de costo del proyecto, 63
Descripción del proyecto, 63
Porcentaje de duración del proyecto completado, 64
Fecha de finalización temprana del proyecto, 64
Fecha de inicio temprano del proyecto, 64
Restricción de finalización del proyecto, 64
Información del proyecto, 4
Fecha de finalización tardía del proyecto, 65
Fecha de inicio tardío del proyecto, 65
Nombre del proyecto, 65
Proyecto por ciento físico completo, 66
Planificación del proyecto, 7
Duración restante del proyecto, 66
Cantidad real de recursos del proyecto, 66
Fecha de finalización nivelada de recursos del proyecto, 66
Fecha de inicio nivelada de recursos del proyecto, 67
Cantidad total de recursos del proyecto, 67
Programación de proyectos, 1
Tamaño y complejidad del proyecto, 3
Datos específicos del proyecto, 7
Restricción de inicio del proyecto, 67
Duración total del proyecto, 67
Ciclo de actualización del proyecto, 24
Q
Calificaciones, 5
R
Relación, 28–29, 44
principio a fin, 38
Duración restante
actividad, 50
proyecto, 66
Informes, 39
Requisito, 42
Recurso, 44
Asignación de recursos, 68
Disponibilidad de recursos, 12–13, 26–27, 68
Reserva de recursos, 13
Calendario de recursos, 68
Descripción del recurso, 68
Determinación de recursos, 30
ID de recurso, 68
Retraso de recursos, 69
Nivelación de recursos, 51, 66–67, 69
Biblioteca de recursos / diccionario, 69
Planificación de recursos, 25
Tasas / precios de recursos, 69
Tipo de recurso, 70
Riesgo, 37, 44, 47, 52, 62, 70
Página 152
140
ÍNDICE
Identificación de riesgo, 70
Planificación de olas rodantes, 15
S
Horario, definición de, 18
Programar plan de gestión de datos, 22
Modelo de horario, 1, 4–5, 10, 18, 70, 71
creación de, 7, 26–27
instancias y presentaciones, 18
gestión de 2122
maestro, 25–26
principios y conceptos de, 719
disponibilidad de recursos en, 26–27
Análisis del modelo de horarios, 35
ruta crítica y actividades críticas, 35
restricciones de fecha, 37
adelanta y atrasa, 38
actividades de nivel de esfuerzo, 36
enlaces a / desde actividades resumidas, 38
actividades abiertas, 37
lógica fuera de secuencia, 37–38
distribución probabilística de la duración de la actividad, 36
riesgo horario, 37
relación de principio a fin, 38
flotación total y flotación libre, 35–36
Programar el desarrollo de la línea base del modelo
modelo de cronograma de referencia, 32
determinación de duración para cada actividad, 30–31
definición de hito, 27
diseño de actividades del proyecto, 27–28
determinación de recursos para cada actividad, 30
aprobación de horario, 32
análisis de salida del horario, 31–32
actividades de secuenciación, 2830
Programar la creación del modelo, 26
Programar ID de modelo, 70
Instancia de modelo de horario, 1, 18–19, 39
Nivel de modelo de horario, 71
Programa de mantenimiento del modelo, 10, 33
recoger datos reales y trabajo restante, 33
comunicarse, 34
comparar y resolver desviaciones, 34
mantener registros, 34
actualización y progreso de acuerdo a datos reales, 33
actualizar la línea de base, 34
actualización con cambios aprobados, 34
Gestión del modelo de horarios, 21
plan de gestión de datos programados, 22
plan modelo de plan de gestión, 23
Plan modelo de plan de gestión, 7, 23
calendarios y períodos de trabajo, 23–24
modelo de horario maestro, 25–26
estructura de codificación de hitos y actividades, 24–25
indicadores de desempeño, 25
plan, 7
ciclo de actualización del proyecto, 24
planificación de recursos, 25
plan de plan de creación del modelo, 23
ID de modelo de horario, 23
versión modelo, 23
selección del método de programación, 23
selección de herramienta de programación, 23
Calendario de presentación del modelo, 71
Programar versión del modelo, 72
Análisis de salida del horario, 31–32
Índice de rendimiento del horario, 72
Programa de riesgo, 37, 44
Programadores, 5
Horario varianza, 72
Porcentaje de varianza programada, 72
Programación, 2, 4
Programación de componentes, 41–76
Lista de categorías para, 43–44
costo real de actividad, 45
duración real de la actividad, 45
actividad fecha final real, 45
actividad fecha de inicio real, 45
calendario de actividades, 46
código de actividad, 46
categoría de costo de actividad, 46
costo de actividad estimado, 46
distribución de riesgo de probabilidad acumulativa de actividad, 47
porcentaje de duración de la actividad completa, 47
actividad fecha de finalización temprana, 47
actividad fecha de inicio temprano, 47
esfuerzo de actividad / trabajo, 48
ID de actividad, 48
etiqueta de actividad, 48
actividad fecha de finalización tardía, 48
actividad fecha de inicio tardío, 49
duración más probable de la actividad, 49
duración optimista de la actividad, 49
actividad duración original, 49
porcentaje de actividad completado, 52
actividad pesimista duración, 50
actividad porcentaje físico completado, 50
duración restante de la actividad, 50
cantidad real del recurso de actividad, 51
fecha de finalización nivelada de recursos de actividad, 51
Page 153
141
ÍNDICE
fecha de inicio nivelada de recursos de actividad, 51
cantidad total de recursos de actividad, 51
índice de criticidad del riesgo de actividad, 52
definición del alcance de la actividad, 52
duración total de la actividad, 52
lo más tarde posible, 53
lo antes posible, 53
modelo de cronograma de referencia, 53
presupuesto al finalizar, 53
identificador de solicitud de cambio, 54
ID de la cuenta de control, 54
gerente de cuentas de control, 54
índice de rentabilidad, 54
variación de costo, 55
porcentaje de variación de costo, 55
camino crítico, 55
campo personalizado, 55
fecha de datos, 56
recursos de conducción, 56
valor ganado, 56
método del valor ganado, 56
valor ganado peso, 57
estimación al finalizar, 57
estimado para completar, 57
final esperado, 58
terminar no antes de, 58
terminar a más tardar el 58
terminar en 59
fin a fin, 59
terminar para comenzar, 59
flotador libre, 60
retraso, 60
plomo, 60
fecha de finalización obligatoria, 61
fecha de inicio obligatoria, 61
hito, 61
valor planificado, 62
distribución de riesgo de probabilidad, 62
duración real del proyecto, 62
fecha de finalización real del proyecto, 62
fecha de inicio real del proyecto, 63
calendario de proyectos, 63
categoría de costo del proyecto, 63
descripción del proyecto, 63
porcentaje de duración del proyecto completado, 64
fecha de finalización temprana del proyecto, 64
fecha de inicio temprano del proyecto, 64
restricción de finalización del proyecto, 64
fecha de finalización tardía del proyecto, 65
fecha de inicio tardío del proyecto, 65
gerente de proyecto, 65
nombre del proyecto, 65
proyecto por ciento físico completo, 66
duración restante del proyecto, 66
Cantidad real de recursos del proyecto, 66
fecha de finalización nivelada del recurso del proyecto, 66
fecha de inicio nivelada de recursos del proyecto, 67
cantidad total de recursos del proyecto, 67
restricción de inicio de proyecto, 67
duración total del proyecto, 67
asignación de recursos, 68
disponibilidad de recursos, 68
calendario de recursos, 68
descripción del recurso, 68
ID de recurso, 68
retraso de recursos, 69
nivelación de recursos, 69
biblioteca / diccionario de recursos, 69
tasas / precios de recursos, 69
tipo de recurso, 70
identificación de riesgo, 70
ID de modelo de horario, 70
nivel de modelo de horario, 71
calendario de presentación del modelo, 71
versión del modelo de horario, 72
índice de rendimiento del horario, 72
variación de horario, 72
porcentaje de varianza programada, 72
comenzar no antes de, 73
comenzar a más tardar el 73
empezar, 73
principio a fin, 74
empezar a empezar, 74
resumen de la actividad, 74
modelo de horario objetivo, 74
flotador total, 75
para completar el índice de rendimiento, 75
unidad de medida, 75
varianza, 76
ID de la WBS, 76
identificador de paquete de trabajo, 76
nota condicional / componente asociado, 43
cómo usar la lista, 41
comportamiento, 42
nombre del componente, 42
formato de datos, 42
definición, 43
buenas prácticas, 43
manual o calculado, 42
uso requerido, condicional u opcional, 42
Page 154
142
ÍNDICE
Métodos de programación, 4, 7, 9.
Técnicas de programación, 15
Herramienta de programación, 7, 1718
Ver también herramientas específicas
Actividades de secuenciación, 2830, 3738
Flojo. Ver Flotación libre; Flotación total
Fecha de inicio, 31, 44
real, 45, 63
temprano, 47, 64
tarde, 49, 65
Comience no antes de, 73
Comience a más tardar, 73
Empieza el 73
De principio a fin, 74
Relación de principio a fin, 38
Empieza a empezar, 74
Estado, 7
Resumen de actividad, 74
T
Modelo de horario objetivo, 74
Estimación de tres puntos, 36
Gestión del tiempo, 3
Flotación total, 31, 35–36, 75
Para completar el índice de rendimiento, 75
U
Unidad de medida, 75
Actualización, 7, 24, 28
Actualización y modelo de cronograma de progreso de acuerdo con datos reales,
33
Actualizar el modelo de cronograma de referencia, 34
Modelo de calendario de actualización con cambios aprobados, 34
V
Varianza, 55, 72, 76
W
ID de la WBS, 76
Estructura de desglose del trabajo (WBS), 5, 76
Paquete de trabajo, 76
Identificador del paquete de trabajo, 76
Períodos de trabajo, 2324
155 de 1189.
Page 156

CRONOGRAMA

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CRONOGRAMA

Caricato da

Copyright:

Formati disponibili

Xxxxxxx

Potrebbero piacerti anche