PRACTICE STANDARD FOR SCHEDULING

(SEGUNDA EDICIN) PMI 2011

Este estndar fue desarrollado como un complemento del PMBOK en el rea del
Conocimiento de Gestin del Tiempo del Proyecto. Describe los mtodos
relacionados con programacin del tiempo que se reconocen generalmente como
buenas prcticas para la mayora de los proyectos, la mayora del tiempo. Buena
Prctica significa que existe un acuerdo general que la aplicacin correcta de estas
habilidades, herramientas y tcnicas puede mejorar las posibilidades de xito en un
amplio rango de proyectos. Buena Prctica no significa que el conocimiento descrito
deba siempre ser aplicado uniformemente en todos los proyectos; el equipo del
proyecto ser el responsable de decidir qu es lo ms apropiado para un proyecto en
particular.
Este estndar prctico clarific la distincin entre el cronograma del proyecto y el
modelo de programacin del tiempo.
Primero se selecciona un mtodo de programacin del tiempo seguido de la
seleccin de una herramienta de programacin del tiempo. Luego, se ingresa
informacin especfica del proyecto a la herramienta para producir el modelo de
programacin del tiempo. A partir de aqu, se generan varias versiones del modelo
de programacin del tiempo para uso como plataformas de casos eventuales,
objetivos y para aprobacin formal como lnea de base. Luego se producen varias
presentaciones para una amplia variedad de usos.

CAPTULO 1. INTRODUCCIN

Este captulo est diseado para proveer una visin general del contenido de este
estndar. Este captulo est dividido en las siguientes secciones:
1.1 Programacin del Tiempo del Proyecto
1.2 Por qu programar el tiempo?
1.3 Visin General
1.4 Propsito
1.5 Aplicabilidad
Cada seccin provee informacin adicional del contenido y terminologa usada en este
estndar.

1.1 PROGRAMACIN DEL TIEMPO DEL PROYECTO

La programacin del proyecto es la aplicacin de habilidades, tcnicas e intuicin
adquirida a travs del conocimiento y experiencia para desarrollar modelos efectivos
de programacin del tiempo. El modelo de programacin del tiempo integra y
organiza localmente varios componentes del proyecto, como actividades, recursos y
relaciones lgicas, para mejorar la posibilidad de que el proyecto se complete
satisfactoriamente dentro de la duracin de base.
Definicin de trminos:
Modelo de Programacin del Tiempo: es una representacin dinmica del plan para
la ejecucin de las actividades del proyecto desarrollado por los interesados del
proyecto, aplicando un mtodo de programacin del tiempo seleccionado a una
herramienta de programacin del tiempo usando informacin especfica del proyecto.
El modelo de programacin del tiempo puede ser procesado por una herramienta de
programacin para producir varias versiones de modelos de programacin del
tiempo.
Versin del Modelo de Programacin del Tiempo: es una copia del modelo de
programacin del tiempo, que has sido procesada por una herramienta de
programacin del tiempo y ha reaccionado a entradas y ajustes hechos a los datos de
un proyecto especfico dentro de la herramienta de programacin del tiempo (ciclo de
actualizacin completo), que es guardada como registro y referencia, como una
versin correspondiente a una fecha, modelos de programacin especficos y el
modelo de programacin de base. Las versiones producen varias presentaciones
de la programacin del tiempo como rutas crticas, perfiles de recursos, asignacin
de actividades, registro de logros, etc., y pueden proveer pronsticos basados en
tiempo del ciclo de vida del proyecto. Cuando se utilizan juntas, las versiones apoyan
el anlisis, por ejemplo de varianza.
Presentacin: es una salida de la versin del modelo de programacin del
tiempo, utilizada para comunicar datos especficos del proyecto para reporte, anlisis
y toma de decisiones.

1.2 POR QU PROGRAMAR EL TIEMPO?

Los proyectos generalmente son cometidos complejos, sin embargo un modelo
detallado de programacin del tiempo puede resultar en una descomposicin del
proyecto en fases o grupos ms manejables. El desempeo del proyecto se reporta y
controla cuando se compara el progreso contra estas actividades e hitos. A medida
que se avanza en un proyecto, los esfuerzos remanentes deben ser reasignados. La
ejecucin de un proyecto usualmente no prosigue exactamente como fue inicialmente
planificado y segn la lnea de base. En un ambiente de proyecto tpico, debido a una
planificacin inadecuada o cambios significativos al proyecto, se vuelve necesario
refinar el modelo de programacin del tiempo. Esta evolucin iterativa es requerida
para predecir, reconocer y lograr esos factores en desarrollo y situaciones
problemticas que van a afectar potencialmente el desempeo de un proyecto. La
clave para el xito del proyecto es aplicar el conocimiento y la experiencia en crear un
plan de gestin del proyecto y luego dedicarse a ejecutar el proyecto de acuerdo al
plan. La programacin del tiempo es uno de los requisitos bsicos de la planificacin y
anlisis en la gestin de proyectos.
La programacin del tiempo provee un plan detallado que representa cmo y cundo
se producirn los productos, servicios y resultados del proyecto definidos en el
alcance del proyecto y puede servir como un instrumento para la comunicacin,
gestin de expectativas de los interesados y una base para el reporte del desempeo.
La naturaleza dinmica de la ejecucin del proyecto se ajusta mejor a una herramienta
que permita modelar el proyecto, sus dependencias internas y externas y analizar
debido al impacto del avance y adelantos imprevistos.
El modelo de programacin del tiempo apoya al proyecto, permitiendo:
Distribucin de actividades requeridas en el tiempo
Movilizacin de recursos de una manera ms eficiente
Coordinacin de eventos dentro del proyecto y con otros proyectos
Deteccin temprana de riesgos y problemas
Implementacin de acciones para completar los objetivos del proyecto tal y
como se planearon.
Permite el anlisis de escenarios
Planificacin de recursos
Pronsticos de estimacin a finalizacin

1.3 VISIN GENERAL

Este estndar para la programacin del tiempo describe los componentes del modelo
de programacin del tiempo (captulo 4) y las buenas prcticas generalmente
reconocidas son aplicables a la mayora de proyectos, la mayora del tiempo; existe
consenso sobre su valor y utilidad. Buena Prctica significa que existe acuerdo
general que la aplicacin de estas habilidades, herramientas y tcnicas puede mejorar
la probabilidad de xito dentro de un amplio rango de proyectos. Buena Prctica no
significa que el conocimiento descrito deba siempre ser aplicado uniformemente a
todos los proyectos; el equipo de proyecto deber ser el responsable de determinar
qu es apropiado para un determinado proyecto. El uso adecuado de los
componentes y sus resultados prcticos en un modelo de programacin del tiempo se
usa para planear, ejecutar, monitorear, cerrar y entregar el alcance del proyecto a los
interesados. El proceso Crear el Cronograma comienza con una seleccin del
mtodo de programacin del tiempo y la herramienta de programacin del tiempo
que apoyar el mtodo de programacin del tiempo deseado, seguido de la
incorporacin de datos especficos del proyecto a la herramienta y luego crear un
nico modelo de programacin del tiempo. El resultado es una versin del modelo de
programacin del tiempo usada para generar varias presentaciones y reportes. La
figura 1-1 muestra un mejor entendimiento de las interrelaciones de los conceptos de
creacin y terminologa del modelo de programacin del tiempo. Este proceso resulta
en un modelo de programacin del tiempo para la ejecucin, monitoreo y
control del proyecto, que va a responder predeciblemente al avance y a los cambios.
El modelo de programacin del tiempo es actualizado regularmente para reflejar el
avance y los cambios en el alcance, duraciones, hitos, recursos asignados, eficiencias,
metodologa de trabajo o lgica de programacin. Este Estndar Prctico para
Programacin del Tiempo tambin provee un proceso de valoracin que puede ser
usado para determinar qu tan bien el modelo de programacin del tiempo se alinea
a este estndar. Un ndice de conformidad (vea el captulo 5 de este estndar prctico)
se desarroll para determinar cules componentes son usados y cmo son usados
dentro del modelo de programacin del tiempo. Para obtener una evaluacin
aceptable del ajuste, un modelo de programacin del tiempo, como mnimo, debe
contener todos los componentes requeridos que se describen el en Captulo 4 y en el
Apndice D. La seleccin de la herramienta de software apropiada para la
programacin del tiempo provee acceso a los componentes requeridos necesarios
para desarrollar el modelo de programacin del tiempo. El uso de este estndar junto
con la experiencia, la habilidad y la madurez organizacional va a guiar la aplicacin de
los componentes.
La inclusin de un componente en este estndar prctico no tiene necesariamente
relacin con la complejidad o el tamao de los problemas del proyecto. Este estndar
prctico supone que todos los modelos de programacin del tiempo necesitan tener
los componentes requeridos, comportamientos bsicos y buenas prcticas; el tamao
y la complejidad del proyecto solo dan lugar a cambios en la escala y repeticin de los
componentes requeridos. La Gua de Conocimiento para la Gestin del Proyecto
(PMBOK) provee los procesos para alcanzar los factores que tienen que ver con el
tamao y la complejidad del proyecto. En adicin, la definicin de generalmente
reconocido tambin supone que no existen diferencias significativas para el uso de
los componentes requeridos en las prcticas de programacin del tiempo de diversas
industrias.

1.4 PROPSITO

El propsito de Estndar Prctico para la Programacin del Tiempo es proveer
lineamientos de uso efectivo en la gestin del tiempo de un proyecto, proveyendo
conocimiento en la creacin de modelos de programacin del tiempo. Este estndar
prctico ampla la informacin contenida en el Captulo 6 (seccin de Gestin del
Tiempo) de la Gua PMBOK. Ms an, para suplir adecuadamente las necesidades de
la comunidad de directores de proyecto, es esencial proveer un medio para lograr el
grado de conformidad con este estndar prctico. Al hacer eso, este estndar prctico
establece un ncleo de componentes esenciales para ser utilizados en el
establecimiento de un modelo de programacin del tiempo que alcance un grado
mnimo aceptable de conformidad con este estndar prctico y un mtodo para que el
modelo de programacin del tiempo alcance conformidad con este estndar. Los
componentes requeridos para cada modelo de programacin del tiempo deben ser
descritos en el modelo de programacin del tiempo del proyecto del plan de gestin
(vea la seccin 3.1).
El propsito final de este estndar prctico es crear modelos de programacin del
tiempo que sean de valor creciente para los proyectos que ellos representan.
No es el propsito de este estndar prctico proveer una gua integral de cmo
desarrollar un modelo de programacin del tiempo. Para una instruccin en cmo
desarrollar un modelo de programacin del tiempo, refirase a cursos y libros de texto
sobre el particular.




1.5 APLICABILIDAD

Este estndar prctico se dirige a directores de proyectos que tengan conocimientos
bsicos en programacin del tiempo de los proyectos. Para los propsitos de este
estndar prctico, estos individuos se conocern como programadores.

Se supone que el lector tiene un conocimiento bsico de Gestin de Proyectos, de las
reas del Conocimiento como las define la Gua PMBOK, que el proyecto tiene una
Estructura de Desglose del Trabajo (EDT / WBS) que es conforme con el Estndar
Prctico para Estructuras de Desglose del Trabajo y que se ha planificado
apropiadamente. A medida que el desarrollo del cronograma avance, algunos
estndares prcticos relacionados como el Estndar Prctico para la Gestin del Valor
Ganado podran ser aplicables.

Ms an, una organizacin que abrace los principios y buenas prcticas trazadas en
este estndar y los aplique globalmente a travs de la organizacin, asegurar que
todos los modelos de programacin del tiempo desarrollados para los proyectos de la
organizacin sean hechos de una manera consistente para toda la organizacin.


CAPTULO 2. PRINCIPIOS Y CONCEPTOS DEL
MODELO DE PROGRAMACIN DEL TIEMPO

Este captulo est diseado para proveer gua e informacin en los principios y
conceptos asociados con la creacin del modelo de programacin del tiempo y su uso.
Este captulo est dividido en las siguientes secciones:
2.1 Visin General
2.2. Mtodos de programacin del tiempo
2.3 Tcnicas de Programacin del tiempo

2.4 La herramienta de programacin del tiempo
2.5 El modelo de programacin del tiempo
2.6 Las versiones del modelo de programacin del tiempo y las Presentaciones.
Cada seccin provee requisitos adicionales, terminologa y funcionalidad relacionada
con estos tpicos. Estas secciones ligan los procesos descritos en este captulo a las
buenas prcticas descritas en el captulo 3 y los componentes de programacin del
tiempo del captulo 4.

2.1 VISIN GENERAL

Los principios y conceptos del modelo de programacin del tiempo estn descritos en
la figura 2-1. El plan de manejo del modelo de programacin del tiempo identifica el
mtodo de programacin del tiempo y la herramienta de programacin del tiempo
utilizada para crear dicho modelo. El proceso Crear Cronograma incorpora todos los
procesos definidos que tienen que ver con el esfuerzo de programacin del tiempo del
proyecto (Inicio, Planificacin, Ejecucin, Monitoreo y Control y Cierre). Dentro de
este proceso de modelacin, todas las actividades requeridas del proyecto y todos los
hitos se definen y secuencian para lograr los objetivos del proyecto. El proceso Crear
Cronograma incluye los procesos: Definir Actividades, Secuenciar Actividades, Estimar
Recursos de Actividades, Estimar Duraciones de Actividades y Desarrollar el
Cronograma (segn el PMBOK). El modelo de programacin del tiempo puede
generar diversas versiones del cronograma, las cuales producen presentaciones (ver
figura 2-1). Las versiones del cronograma pueden incluir, la lnea de base aprobada,
objetivos seleccionados y modelos condicionados (si-entonces). El proceso Crear
Cronograma tiene como resultado un modelo de programacin del tiempo aprobado
utilizado en los Grupos de Proceso de Ejecucin y Monitoreo y Control (PMBOK), el
cual reacciona predeciblemente y lgicamente al progreso y a los cambios del
proyecto. Una vez creado y aprobado (cuando se establece la lnea base), el modelo de
programacin del tiempo se actualiza, de acuerdo a las necesidades de desempeo del
proyecto y en apoyo a los intervalos regulares de reportes del proyecto, para reflejar
progreso y cambios.
Durante la planificacin del proyecto se inicia un proceso para crear el modelo de
programacin del tiempo que satisfaga las necesidades del proyecto y sus interesados.

Muchos de los trminos y conceptos discutidos en este apartado se explican con
mayor detalle en el captulo 3 de este estndar. Las actividades definidas, basadas en
la EDT del proyecto, necesitan ser identificadas y descritas excepcionalmente,
iniciando con un verbo, incluir al menos un nico objetivo especfico y aclarando
adjetivos cuando sea necesario. Las Actividades son secuenciadas mediante
relaciones lgicas. La cantidad, nivel de destreza y capacidades y habilidades de los
recursos requeridos para completar cada actividad deben ser considerados, adems
se consultar a quienes ejecutarn las actividades para determinar la duracin de
cada actividad. No se deben usar restricciones ni factores de adelanto/retraso de
tiempo en el modelo de programacin del tiempo para reemplazar la lgica del
cronograma. La creacin del modelo provee una lnea de base que permite la
comparacin del progreso contra el plan aprobado. Un vistazo general del proceso
Crear el Cronograma se ilustra en el diagrama de flujo y la tabla de mapeo de
componentes del proceso mostrados en las figuras 2-2(a) y 2-2(b).

2.2 MTODOS DE PROGRAMACIN DEL TIEMPO

El mtodo de programacin del tiempo provee el marco para la creacin del modelo
de programacin del tiempo. El mtodo ms comn de programacin del tiempo,
sustentado por la mayora de las herramientas de programacin del tiempo, es el
mtodo de diagrama de precedencia (MDP). Con el uso comn y persuasivo, se le
llama usualmente el Mtodo de la Ruta Crtica (CPM). Otro mtodo popular es la
Cadena Crtica, el cual es basado en el CPM. Dentro de estos mtodos existen varias
tcnicas como Planificacin Gradual (Rolling Wave), PERT, Monte Carlo, programacin
maestra integrada y gil. El primer paso en el proceso Crear el Cronograma es la
seleccin de un mtodo y una tcnica apropiados. Algunas organizaciones
estandarizan una herramienta especfica de software. En este caso, el mtodo de
programacin del tiempo ya est decidido y est inherente en la herramienta. Debido
a que es el mtodo ms usado, este estndar prctico se enfoca en el CPM.

2.2.1 MTODO DE LA RUTA CRTICA (CPM)

El mtodo de la ruta crtica (CPM) determina la duracin mnima total del proyecto y
la fecha estimada ms temprana posible para finalizar el proyecto, as como la posible
flexibilidad ( holgura total) en el modelo de programacin del tiempo. Para aplicar el
CPM, se desarrolla un cronograma modelo, el cual abarca las actividades del proyecto.
Se calculan las fechas ms tempranas de inicio y finalizacin para cada actividad
mediante un paso adelante desde una fecha especfica del proyecto. Las fechas ms
tardas de inicio y finalizacin se determinan para cada actividad mediante paso
atrs, empezando de la fecha ms temprana de finalizacin determinada durante el
paso adelante o desde una fecha de finalizacin especfica (restriccin).
Un principio bsico del CPM es que cada actividad debe estar finalizada antes que su
sucesora pueda iniciar. Sin aplicar varias mejoras el CPM puro permite nicamente
holguras cero y positivas. El CPM puro no se ajusta a varias de las caractersticas de
las aplicaciones modernas de programacin del tiempo, incluyendo recursos,
calendarios del proyecto y actividades, restricciones, definiciones variables o crticas,
recursos, duraciones ejecutadas, rezagos, dependencias externas, prioridades de las
actividades y la asignacin de fechas de inicio y finalizacin reales a las actividades.

En su uso comn el CPM se refeire al mtodo imperante utilizado en las herramientas
modernas de programacin del tiempo. En estas herramientas el mtodo vigente es
usualmente el mtodo de diagrama de precedencias (MDP) y este estndar sigue esa
convencin de uso comn.




2.2.2 MTODO DEL DIAGRAMA DE PRECEDENCIAS (MDP)

El concepto original del CPM era un modelo computarizado que utilizaba un estilo de
diagramacin actividad-flecha. El mtodo de diagrama de precedencia (MDP) fue
introducido unos aos luego como una metodologa no computarizada de
programacin del tiempo que ofreca una representacin grfica ms limpia y fcil de
seguir; bosquejaba las actividades comprendidas en un proyecto como cajas y nodos e
introduca relaciones lgicas mejoradas (en adicin a finalizacin-inicio) y el uso de
adelantos y atrasos. El resultado es un diagrama de precedencia, tambin conocido
como diagrama de red del proyecto. La metodologa MDP del CPM fue rpidamente
programada y las herramientas modernas de programacin del tiempo colocan las
actividades en nodos con flechas uniendo las actividades; los nodos de las actividades
pueden contener informacin sobre la duracin, costo recursos y restricciones. La
adicin de mltiples calendarios del proyecto y restricciones especficas del proyecto
complican ms los clculos del CPM y el anlisis de redes. Las aplicaciones
computarizadas de hoy hace ms fcil lidiar con estos factores durante el clculo del
modelo de programacin del tiempo. El resultado final es que para la mayora de
proyectos, el camino crtico ya no es un camino de cero holguras, como era presentado
en los primeros CPM. El resultado final es un diagrama de precedencia, tambin
conocido como diagramas de red del proyecto. El MDP coloca actividades en nudos
con flechas uniendo actividades; los nodos de las actividades pueden contener
informacin sobre duracin, costo, recursos y restricciones. El MDP requiere de
menos nodos que el ADM (Mtodo de Diagrama de Flechas) para describir la misma
informacin del proyecto. Si bien la adicin de mltiples calendarios y restricciones
complica ms los clculos hacia adelante y hacia atrs y el anlisis de redes de un
diagrama MDP, las aplicaciones computarizadas de hoy completan los clculos
adicionales sin problema. En la mayora de proyectos el camino crtico ya no es un
camino de cero holguras, como era antes en el CPM.
Los diagramas de precedencia ilustran las relaciones entre actividades de izquierda a
derecha (escalonados en el tiempo), permitiendo que las actividades del proyecto
fluyan desde un hito de inicio del proyecto al hito de finalizacin del proyecto. Las
relaciones entre actividades escalonadas en el tiempo se representan mediante
flechas direccionales. Se necesita satisfacer las relaciones lgicas.
Para establecer una ruta crtica significativa, es necesario desarrollar una red de
actividades lgica con duraciones empricas para ejecucin de una manera realstica y
prctica. Las salidas abiertas en un cronograma son aquellas actividades que no
tienen una actividad predecesora y/o una sucesora, de esta forma creando un vaco en
la lgica del cronograma del inicio al final del proyecto. Las nicas salidas abiertas
que se pueden esperar son el hito de inicio y el de final. El uso de restricciones,
incluyendo adelantos y atrasos, debe estar restringido a aquellas condiciones que no
pueden ser definidas adecuadamente y modeladas por la aplicacin de la lgica de
actividades.
En MDP, una actividad puede ser conectada ya sea desde su inicio o su fin. Esto
permite una presentacin lgica de inicio-a-fin sin necesidad de descomponer ms el
trabajo. Otra caracterstica de los diagramas MDP es el uso de componentes de atraso
y adelanto.
Un ejemplo de un diagrama de precedencia se muestra en la figura 2-3.


2.2.3 MTODO DE LA CADENA CRTICA (MCC)

La disponibilidad de recursos compete con la habilidad de ejecutar tareas en fechas
planificadas. Como tal, muchos programas de computacin permite que los recursos
sean nivelados (de manera que no tengan exceso de tareas); esto puede acortar la
duracin del proyecto y las fechas de inicio y finalizacin de las actividades. El modelo
resultante de programacin del tiempo, considerando la disponibilidad de recursos, se
denomina comnmente ruta crtica restringida en recursos y es el punto de inicio para
la programacin por cadena crtica. El mtodo de la cadena crtica se desarroll con
base en el CPM y considera los efectos de la asignacin de los recursos, nivelacin de
recursos e incertidumbre en la duracin de las actividades en el camino crtico
determinado por el CPM. Para hacer eso, el mtodo de la cadena crtica introduce el
concepto de buffer y gestin de buffer. Tres tipos de buffers son, buffers de
alimentacin, buffer de recursos y buffers del proyecto:
Buffers de Alimentacin: un buffer (en duracin) aadido al modelo de
programacin del tiempo en la unin de caminos no-crticos con el camino crtico del
CPM.
Buffers de Recursos: la transicin frecuente de fechas estimadas de finalizacin a
una actividad predecesora alertando los recursos de una actividad sucesora para
estar preparado para el trabajo de inicio en la fecha estimada de finalizacin de la
actividad predecesora.
Buffers del Proyecto: una duracin aadida al final de proyecto entre la ltima
actividad del proyecto y la fecha final de entrega o fecha de cumplimiento del
contrato.
Los buffers son determinados estadsticamente y se agregan los mrgenes de
seguridad asignados a cadenas de actividades individuales. Los buffers son creados
asignando tiempos agresivos de realizacin de las actividades para remover cualquier
margen de seguridad escondido y agregando los ahorros resultantes de tiempos
planeados en los buffers. En vez de propagar los mrgenes de seguridad a lo largo de
todas las actividades, el margen de seguridad es concentrado al final de la cadena y
usado solamente si se materializa el riesgo (cualquiera que sea, resultando en
incertidumbres en la duracin o los recursos). El efecto es similar a gestionar la
holgura total y la holgura libre en el mtodo CPM. Un ejemplo de una cadena crtica se
muestra en la figura 2-4.
El camino de recursos nivelados ms largo a travs del cronograma, incluyendo los
buffers, es el camino crtico, y es usualmente diferente al camino crtico del CPM. Los
factores definitorios en el mtodo de la cadena crtica son las actividades buffer, los
recursos que no sean multi-tarea, nivelacin de recursos y gestin de buffer.

El primer paso cuando se usa el mtodo de la cadena crtica para programacin del
tiempo es crear un plan de proyecto agresivo y nivelado en recursos (pero no
necesariamente detallado). La fecha de finalizacin del proyecto est definida como en
final de la cadena crtica, incluyendo los buffers para tomar en cuenta los riesgos del
proyecto y las demoras. Durante la ejecucin del proyecto, si las actividades
consumen una duracin mayor que la predicha por el mtodo de la cadena crtica, el
buffer del proyecto se va consumiendo gradualmente. De acuerdo al grado de
consumo del buffer (tambin llamado gestin del buffer), el equipo de proyecto puede
tomar acciones correctivas; desde no hay necesidad de reaccionar a planear la
respuesta a actualmente ejecutando la respuesta planeada para recobrar el buffer
del proyecto. En el tanto el total de los atrasos sea menor que el buffer, existe un
efecto limitado en el alcance del proyecto, la duracin y el presupuesto.
La cadena crtica se presenta diferente al CPM en cuatro aspectos principales:
El entendimiento que los riesgos significativos, inesperados, que son
imprevistos, se van a materializar durante al proyecto y van a necesitar
acciones proactivas.
El enfoque de la atencin administrativa la cadena crtica- va a permanecer
fija durante todo del proyecto.
La contencin de recursos es de tal magnitud en las estructuras organizativas
de hoy que la duracin de los proyectos es dependiente de la disponibilidad de
recursos a un grado no menor que de la secuencia lgica de las actividades.
En CPM, un margen significativo est contenido en todas las actividades, pero
cuando es expuesto y adicionado (en vez de ser distribuido y escondido en las
actividades individuales), su absorcin del riesgo va a ser mayor en orden de
magnitud.

2.3 TCNICAS DE PROGRAMACIN DEL TIEMPO

Una vez que se estableci un mtodo de programacin del tiempo, un grupo de
tcnicas pueden ser aplicadas a un mtodo. Algunas de las ms comunes tcnicas son:
Planificacin Gradual (rolling wave planning), programacin gil, PERT y simulacin
Monte Carlo.

2.3.1 PLANIFICACIN GRADUAL (ROLLING WAVE PLANNING).

Al utilizar la tcnica de planificacin gradual, se realiza una descomposicin detallada
de las actividades de alto nivel solo para aquellas actividades en el futuro cercano, por
ejemplo, los prximos 90 das. La tcnica de planificacin gradual supone que el
equipo del proyecto tiende a poseer informacin exacta y detallada concerniente a las
actividades de corto plazo y menos informacin sobre las actividades en el futuro o
ms all dentro del proyecto. Un principio importante para la Planificacin Gradual es
realizar la planificacin detallada e intervalos regulares. La planificacin detallada
para el siguiente intervalo necesita ser bien completada previo al inicio del siguiente
ciclo de ejecucin.
Para periodos ms all del ciclo de ejecucin detallado, las actividades se enlistan
como paquetes de planificacin con mucho menor detalle. Estas actividades de
planificacin pueden contener informacin de costo y recursos, la cual se vuelve fija
en la duracin y el costo base. Cuando llega la hora de la planificacin detallada, se
reemplazan los paquetes de planificacin con detalles adicionales. La figura 2-5 ilustra
un ejemplo de planificacin gradual.


2.3.2 TCNICA GIL

La gestin de proyectos gil es similar a la tcnica de Planificacin Gradual en el tanto
enfatiza la consecucin de resultados usables rpida e iterativamente. El equipo de
proyecto gil utiliza programacin CPM para cada ciclo de desarrollo, llamado sprint,
el cual normalmente tarda de dos a cuatro semanas. La gestin de proyectos gil se
enfoca en ciclos de desarrollo ms cortos y resultados tangibles en intervalos
frecuentes e incrementales; el enfoque est en el logro de beneficios intermedios en
vez de completar actividades. Los elementos ms importantes de una tcnica gil
incluyen mltiples iteraciones de las fases del proyecto en vez de moverse de una fase
a otra. Otro ingrediente clave del mtodo gil es la participacin de los interesados
clave, primariamente el usuario final o el cliente al final de cada iteracin para
aprobar los productos de trabajo intermedios.




2.3.3 TCNICA DE EVALUACIN Y REVISIN DEL PROGRAMA (PERT).

Aunque similar en principio al CPM y MDP, la tcnica de evaluacin y revisin del
programa (PERT) est enfocada en la duracin de las actividades. PERT permite la
duracin aleatoria de actividades y pondera la duracin estimada en actividades en el
rango de estimados de duracin provisto por los interesados. Se provee un mayor
desarrollo de tcnicas de estimacin en el Estndar Prctico de Estimacin del
Proyecto.
A partir del diagrama de precedencia, PERT permite que los estimados de duracin de
las actividades se determinen teniendo en cuenta el grado de incertidumbre contenido
en el proceso de estimacin de duracin. Tres clculos de duracin son necesarios
para cada actividad:
Duracin optimista (la mnima duracin de la actividad bajo las condiciones
ms favorables)
Duracin ms probable (la duracin de la actividad que ocurrir con ms
frecuencia)
Duracin pesimista (la duracin de la actividad bajo las condiciones menos
favorables)

Las duraciones determinadas por la ecuacin anterior son usadas en el diagrama
PERT como duraciones estimadas de actividades. Generalmente las duraciones se
establecen a un nivel estadstico especfico de significancia (por ejemplo, un nivel de
95% de confianza). El peso en la ecuacin fue una aproximacin manual de la
distribucin estadstica. Con clculos ms sofisticados, principalmente utilizando
computadores, una implementacin de simulaciones estadsticas o mltiples PERT
(SPERT) es posible, acercndose al mtodo y resultados del anlisis de Monte Carlo.

2.3.4 SIMULACIN MONTE CARLO

La simulacin Monte Carlo considera la incertidumbre en la duracin de la actividad,
costos, recursos y relaciones, etc., usando los riesgos del registro de riesgos para
manejar la incertidumbre en la duracin de las actividades o estimando aquellas
duraciones directamente como optimistas, ms probables y pesimistas para las
actividades. Una distribucin probabilstica puede ser asignada a cada actividad, la
cual considera el nivel de confianza que los interesados tienen en los estimados.
Cuando existe ms confianza en el estimado, una distribucin probabilstica con una
desviacin estndar menor es seleccionada, o viceversa.
Despus de asignar estimados y distribuciones de probabilidad, se corre la simulacin
Monte Carlo. La simulacin est conformada por mltiples iteraciones, cada una de las
cuales representa un posible resultado del proyecto. Para cada iteracin el software
de simulacin Monte Carlo selecciona duraciones (y costos resultantes, etc.) que sean
consistentes con las distribuciones de probabilidad y tipos de actividades
especificadas por el equipo del proyecto. Esto produce una versin del cronograma
modelo con atributos de ruta crtica, duracin y costo. Este proceso se repite
mltiples veces, resultando en una distribucin probabilstica para duracin, costo,
fechas de inicio y fechas de finalizacin para cada actividad seleccionada y al final para
el proyecto. La figura 2-6 muestra una distribucin probabilstica de ejemplo para una
actividad unitaria.

Un anlisis posterior puede determinar la frecuencia de actividades especficas que
caigan en la ruta crtica y la identidad de los riesgos ms significativos para el logro de
los resultados a un nivel deseado de certeza. Las actividades ms frecuentes en el
camino crtico y aquellas que tienen riesgos de alta prioridad pueden ser
monitoreadas de cerca para incrementar la probabilidad que el proyecto se complete
a tiempo. Se utiliza software especializado para la aplicacin de la simulacin Monte
Carlo.

2.4 LA HERRAMIENTA DE PROGRAMACIN DEL TIEMPO

La herramienta de programacin del tiempo es usualmente un software especfico que
contiene componentes de programacin del tiempo y las reglas para interrelacionar
dichos componentes. Los componentes de programacin del tiempo son fcilmente
visualizados corriendo un software de programacin del tiempo y observando los
componentes de la herramienta que estn disponibles para construir el modelo de
programacin del tiempo.
La herramienta de programacin del tiempo es la plataforma sobre la cual el modelo
de programacin del tiempo se ensambla y provee los medios para ajustar varios
parmetros y componentes tpicos en un proceso de modelacin. Por ejemplo, la
herramienta incluye la capacidad para:
Seleccionar el tipo de relacin (como final-a-inicio o final-a-final) entre las
actividades.
Aadir adelantos o atrasos entre actividades.
Aplicar recursos a las actividades y usar informacin de los recursos junto con
la disponibilidad de recursos para ajustar la programacin del tiempo de las
actividades.
Asignar prioridades a las actividades que utilizan los mismos recursos durante
el mismo periodo de tiempo.
Aadir restricciones a las actividades donde nicamente la lgica (por ejemplo,
relaciones de precedencia con otras actividades) no sea adecuada para cumplir
los requerimientos del proyecto, especialmente cuando se consideran
manejadores externos del cronograma y disponibilidad de recursos.
Capturar un modelo especfico de versin del cronograma como lnea de base.
Realizar anlisis situacionales (si-entonces) dentro del modelo del cronograma
para obtener diferentes fechas de finalizacin del proyecto.
Analizar el impacto potencial que los cambios en el cronograma modelo
tendran en los objetivos del proyecto.
Comparar la versin del cronograma modelo ms reciente contra un modelo
anterior o contra la lnea de base para identificar y cuantificar varianzas y
tendencias.

2.5 EL MODELO DE PROGRAMACIN DEL TIEMPO

La introduccin de datos especficos del proyecto, como las actividades, duraciones,
recursos, relaciones y restricciones en la herramienta de programacin del tiempo
crea un modelo de cronograma para un determinado proyecto.
El anlisis de cronogramas modelo compara cambios en el cronograma modelo
basados en actualizaciones del avance, costo y alcance con las expectativas del equipo
del proyecto del impacto de estos cambios. El equipo del proyecto utiliza el
cronograma modelo para predecir la fecha de finalizacin del proyecto en la forma de
versiones del cronograma. El cronograma modelo provee predicciones basadas en
tiempo, reaccionando a entradas y ajustes hechos a travs del ciclo de vida del
proyecto.

2.6 LAS VERSIONES DEL CRONOGRAMA MODELO Y PRESENTACIONES

La versin del cronograma modelo es usado para producir presentaciones para
reportar tems como camino crtico, perfiles de utilizacin de recursos, listas de
actividades, listas de asignacin de actividades, registros de cumplimiento, datos del
sistema de gestin del valor ganado, presupuesto versus tiempo y costo versus
tiempo. Las versiones del cronograma modelo son usadas para generar varias
presentaciones. Estas salidas de datos especficos del proyecto son la base del anlisis
del equipo del proyecto, incluyendo los interesados (vea figura 2-7).
Una presentacin, en su forma ms simple, es una tabla de actividades con sus fechas
asociadas. Las presentaciones son usadas para comunicarse con los interesados
cuando se espera que sucedan las actividades y eventos del proyecto. Las
presentaciones de recursos tambin pueden identificar el recurso, ya sea por una
persona especfica, rol o sistema/herramienta etc., que ser requerido para completar
las actividades.
El trmino cronograma es usualmente utilizado para describir tanto el cronograma
modelo como la salida de actividades con sus fechas asociadas. Para claridad y
consistencia con el PMBOK, este estndar prctico define los datos especficos del
proyecto dentro de una herramienta de programacin del tiempo como un
cronograma modelo y las salidas resultantes, basadas en los datos especficos del
proyecto, como presentaciones de versiones del cronograma modelo (vea las figuras
2-1 y 2-7).

Las presentaciones de versiones del cronograma modelo pueden ser representadas de
muchas maneras, incluyendo pero no limitado a simples listas, grficos de barras con
fechas, diagramas de red lgicos con fechas, patrones de uso de recursos y costos,
hitos, cronogramas maestros, listas de trabajo departamentales, listas del equipo de
trabajo y fechas de presentacin de entregables. Existen muchas otras presentaciones
posibles. Las presentaciones del cronograma modelo pueden tomar la forma de un
cronograma de inicio temprano, inicio tardo, cronograma de lnea de base,
cronograma limitado de recursos o cronograma objeto. Otros tipos de cronogramas
son productos derivados de estos cinco tipos de cronogramas bsicos. Estos
productos derivados incluyen cronogramas maestros, cronogramas de hitos y
cronogramas resumen. El uso de estos trminos puede variar de proyecto en proyecto
y de organizacin en organizacin.

CAPTULO 3. VISTA GENERAL DEL MODELO DE BUENAS
PRCTICAS DE PROGRAMACIN DEL TIEMPO

Este captulo est diseado para proveer una gua e informacin en las buenas
prcticas generalmente aceptadas asociadas con los procesos de planificacin,
desarrollo, mantenimiento, comunicacin y reporte de un modelo efectivo de
programacin del tiempo. Este captulo se divide en las siguientes secciones:
3.1 Gestin del modelo de Programacin del Tiempo
3.2 Creacin del modelo de Programacin del Tiempo
3.3 Mantenimiento del Modelo de Programacin del Tiempo
3.4 Anlisis del Modelo de Programacin del Tiempo
3.5 Comunicacin y Reporte
Cada seccin provee requerimientos comunes, terminologa y funcionalidad asociada.
Estas secciones ligan la discusin del proceso de programacin del tiempo descrito en
el captulo 2 a los componentes del cronograma definidos en el captulo 4. Este
captulo provee una visin general, con ejemplos, de cmo crear y mantener un
modelo efectivo de programacin del tiempo.

3.1 GESTIN DEL MODELO DE PROGRAMACIN DEL TIEMPO

La gestin del modelo de programacin del tiempo abarca los esfuerzos relativos a
programacin del tiempo del equipo de proyecto como parte del proceso Desarrollar
el Plan de Gestin del Proyecto, seccin 4.2 del PMBOK. El modelo de planificacin del
tiempo ayuda a asegurar que todos los Grupos de Proceso y reas de Conocimiento
estn propiamente integrados dentro del modelo completo de programacin del
tiempo. Un modelo de programacin del tiempo requiere planificacin y diseo en
mucho de la misma manera que cada entregable del proyecto es planificado y
diseado. El equipo de proyecto necesita considerar un nmero de factores para crear
un modelo de programacin del tiempo que puede ser una herramienta til para el
proyecto. Esta herramienta va a ser utilizada para monitorear el desempeo del
proyecto, comunicar informacin concerniente al trabajo y comparar el trabajo
planeado con el trabajo realizado. Estos conceptos van a ser desarrollados en apoyo al
Plan de Gestin de Desarrollo del Proyecto, de acuerdo al PMBOK.
La gestin de la modelo de programacin del tiempo se dirige a lo siguiente:
Procesos y procedimientos para la gestin de datos del modelo de
programacin del tiempo como formato de datos, versiones, accesibilidad,
almacenamiento y recuperacin de datos.
Polticas relacionadas con la metodologa que ser utilizada en el desarrollo y
mantenimiento del cronograma, tales como umbrales de desempeo,
contenido y frecuencia de presentaciones y reportes, implementacin e
integracin de la gestin del valor ganado (EVM), compatibilidad con otros
planes del proyecto, seguimiento de riesgos y descomposicin de tareas.
Cuando se determina la descomposicin de tareas, demasiado detalle produce
un modelo confuso y demasiado grande que es difcil y caro de gestionar; muy
poco detalle significa que existe informacin insuficiente para el control del
proyecto en curso.
Consideraciones de obligaciones contractuales y obligaciones financieras
potenciales (reclamos, mediacin, arbitraje, litigio, etc.).
Procesos y procedimientos para planificar, actualizar y mantener el
cronograma modelo durante el ciclo de vida del proyecto; determinacin de un
ciclo apropiado para recopilar el estatus del proyecto y actualizar el
cronograma modelo. El ciclo entre actualizaciones debe ser suficiente para que
la informacin de la ltima actualizacin sea publicada, analizada y que el
equipo del proyecto acte de acuerdo a los hechos antes de la siguiente
actualizacin. El ciclo de actualizacin debe ser de conformidad con el contrato
o los activos de proceso organizacionales.
Requerimientos de capacitacin para los miembros del equipo del proyecto
tales como entendimiento de las polticas de programacin del tiempo,
procedimientos y tecnologas de software, por ejemplo, reporte del progreso,
capturar los riesgos del proyecto y reflejar actividades de mitigacin en el
modelo de programacin del tiempo.

3.1.1 PLAN DE GESTIN DE LOS DATOS DEL CRONOGRAMA

Previo a aadir informacin al cronograma modelo, el equipo de proyecto se debe
enfocar en el correcto diseo del cronograma modelo. El equipo de proyecto necesita
definir algunas entradas bsicas al cronograma modelo y salidas esperadas para
asegurarse que se est colocando la mnima infraestructura necesaria para satisfacer
los requerimientos de los involucrados. Adems, el alcance, la estructura de desglose
del trabajo (EDT), definicin de recursos (cuando se requiera) y otros componentes
del cronograma debieron haber sido definidos de manera que el equipo de trabajo no
tenga que definir esos elementos durante el desarrollo del cronograma modelo. Como
mnimo, el equipo del proyecto debe considerar lo siguiente cuando se desarrolle el
plan de gestin de los datos del cronograma:
Definir una lista de usuarios del cronograma, los derechos de acceso y las
responsabilidades que cada uno tendr. Por ejemplo, algunos usuarios van a
proveer progreso, mientras que otros tendrn mayor acceso al cronograma y
van a ser responsables de funciones administrativas.
Determinar la frecuencia (diaria, semanal o mensual) de respaldo de la
informacin del cronograma. Los respaldos son parte importante de la gestin
de la configuracin del cronograma. Las frecuencias requeridas de respaldo se
establecen frecuentemente de acuerdo a las expectativas de los interesados.
Determinar cmo se van a recuperar las versiones anteriores del cronograma,
a qu intervalos y verificar que los procedimientos para recuperacin de datos
sean exactos. Un error comn es realizar los respaldos pero no establecer un
procedimiento de recuperacin.
Determinar los requisitos de retencin de datos del cronograma.
Identificar los riesgos asociados con el desarrollo del cronograma modelo
relacionados con la gestin de la informacin.
Determinar los requisitos de jerarqua de informacin para propsitos de
reportes (como se defini en el Plan de Comunicacin) y cmo estos requisitos
van a impactar el proceso de gestin de datos del cronograma y el modelo de
datos. Por ejemplo, los tipos de actividades mostrados al comit de direccin
son diferentes a los que se muestran al Director del Proyecto.

3.1.2 PLAN DE GESTIN DEL CRONOGRAMA MODELO

El plan de gestin del cronograma modelo es una coleccin de procesos, mtodos,
plantillas y herramientas para lograr los objetivos del cronograma del proyecto. Las
buenas prcticas establecen que todos los cronogramas modelos deben estar guiados
por una metodologa que provea una lista de chequeo de requisitos para el
cronograma modelo que asegure su calidad.
El Plan de Gestin del Cronograma Modelo permite a los miembros del equipo de
trabajo desempearse de manera correcta. Los proyectos sin un plan tienden a ser
ineficientes, resultan en altos costos, incremento del riesgo y duraciones mayores del
proyecto. El Plan de Gestin del Cronograma Modelo incluye lo siguiente:

.1 Seleccin del Mtodo de Programacin del Tiempo

El equipo de proyecto, con el programador del tiempo como facilitador, debe tener
acceso a la documentacin sobre los mtodos disponibles de programacin del tiempo
aprobados por la organizacin con el fin de acatar los requerimientos de la
organizacin. Basados en esta informacin, el programador del tiempo implementa el
mtodo de programacin del tiempo como fue determinado por el equipo del
proyecto.

.2 Seleccin de la Herramienta de Programacin del Tiempo

La seleccin de la herramienta de programacin del tiempo estar basada en el
mtodo de programacin del tiempo seleccionado y se ajustar a los requerimientos
del proyecto y la organizacin relacionados con la herramienta.

.3 Plan de Creacin del Modelo de Programacin del Tiempo

El Director del Proyecto, en conjunto con el equipo del proyecto y los interesados
clave, determinan el plan para la creacin del modelo de Programacin del Tiempo.
Las consideraciones clave incluyen: planificacin gradual y participacin de los
interesados en el proceso Desarrollar el Cronograma, de acuerdo al PMBOK.

.4 ID del Modelo de Programacin del Tiempo

Cada cronograma modelo necesita tener un nico mtodo de identificacin especfico
para el proyecto.

.5 Versin del Cronograma Modelo

Cada versin del cronograma modelo tiene un nico identificador de versin. La
localizacin de esta identificacin puede variar, dependiendo de los activos del
proceso y las herramientas usadas para controlarlo. Un nico identificador de la
versin del cronograma modelo es esencial para permitir el archivo correcto de los
documentos del proyecto en los procesos de auditora. El plan de gestin del
cronograma modelo proveer el formato para este componente de manera que no
ocurran nombres redundantes.

.6 Calendarios y perodos de trabajo

Un calendario del proyecto estndar es definido utilizando periodos de trabajo. Los
perodos de trabajo pueden tambin ser definidos para actividades especficas o
porciones de un proyecto, incluyendo recursos. Algunos elementos del calendario
incluyen:
Definir los das laborables de la semana
Definir el nmero de turnos a ser trabajados cada da
Definir el nmero de horas a ser trabajadas cada turno o da.
Definir cualquier periodo de horas extra planificadas.
Definir horas libres (por ejemplo, feriados, cierres temporales, cortes de
electricidad programados, tiempos restringidos, etc.).
Estos elementos juegan un papel importante en la determinacin del nmero y la
estructura de los calendarios requeridos para la programacin del tiempo. El uso de
mltiples calendarios introduce una complejidad significativa al clculo de holguras y
ruta crtica. Sin embargo, mientras la programacin se simplifica con el uso de un solo
calendario, un calendario podra ser inadecuado para gestionar el proyecto (por
ejemplo un equipo de proyecto internacional con feriados locales).
La prctica generalmente aceptada es usar un calendario estndar que sea adecuado y
razonable para realizar el trabajo, basado en los tiempos normales de trabajo del
proyecto. Este calendario del proyecto ser usado como el estndar para las
actividades del proyecto. Esta prctica permite al equipo de trabajo establecer y
programar diferentes periodos o calendarios de trabajo, si se requiere, para ciertas
actividades.

.7 Ciclo de Actualizacin del Proyecto

El ciclo de actualizacin es el intervalo normal en el que se reporta el estado del
proyecto. Se determina la frecuencia adecuada para realizar las actualizaciones y
reportar el estado versus el cronograma. Esto incluye determinar en qu momento del
ciclo se producir la actualizacin y la frecuencia con la que el estado ser informado.
El ciclo de actualizacin refleja cmo la gestin se propone utilizar los datos
generados a partir del modelo de programacin del tiempo, incluyendo la distribucin
de las reuniones de revisin, requisitos de informes de gestin y ciclos de pago que a
menudo estn vinculados a las actualizaciones. Seleccione un ciclo de actualizacin de
gestin con un nivel ptimo de informacin de control sin ser excesivamente
agobiante para la gente que hace los informes y anlisis. El ciclo de actualizacin
ptima variar con la industria y con la intencionalidad del proyecto, desde
actualizaciones cada hora de interrupcin planeada para proyectos de instalaciones
de produccin y fabricacin a actualizaciones semanales o mensuales para proyectos
grandes de construccin o desarrollo de software. El ciclo elegido de actualizacin
tiene relacin directa con la duracin de las actividades contenidas dentro del
cronograma.
Los profesionales con experiencia a menudo dividen el ciclo de actualizacin en dos
partes distintas: informes de progreso y mantenimiento. Esto sirve para reducir el
tiempo dedicado a la elaboracin de informes de progreso a un perodo de tiempo
mnimo.
La eleccin del ciclo de actualizacin depende de una serie de factores, tales como la
tasa de cambio en el proyecto, la duracin del proyecto, etc. Para proyectos
relativamente estables, de largo plazo, de bajo riesgo, un ciclo mensual o bimensual
puede ser apropiado. Para proyectos voltiles, proyectos de alto riesgo, las
actualizaciones pueden ser necesarias para cada cambio de turno o cada hora.
El equipo del proyecto debe considerar qu escala de tiempo debe utilizarse: minutos,
horas, das, semanas o meses, la respuesta depende de la frecuencia de los procesos de
control y el nivel de detalle necesario en las actividades. La mayora de las veces, la
escala de tiempo de las actividades se mantendr constante durante todo el
proyecto. No obstante, las evoluciones especficas del proyecto pueden requerir
diferentes escalas de tiempo efectivas para esa evolucin.



.8 Estructura de Codificacin de Hitos y Actividades

El entendimiento de los tipos de reportes necesarios para crear una presentacin a
partir del cronograma modelo (vea la figura 2-7) provee una gua para la estructura
de codificacin a ser construida en el cronograma modelo.
Una estructura de codificacin debe ser desarrollada de tal manera que se pueda
lograr la seleccin, ordenamiento y agrupacin de los datos del cronograma. Esta
codificacin proveer asistencia en el desarrollo y mantenimiento del cronograma
modelo, as como el logro de los requisitos para los reportes. Las estructuras de
codificacin bien diseadas tambin ayudan en el anlisis de los datos de desempeo
del proyecto al agrupar, seleccionar y ordenar con el fin de resaltar tendencias y
anomalas.
Se debe poner nfasis en utilizar una estructura de codificacin atinada y bien
conceptualizada que sea aparte del identificador de actividad. Las actividades pueden
ser codificadas con ms de un cdigo para cada actividad, cada cdigo con un valor
asignado, permitiendo las salidas personalizadas para diferentes propsitos. Por
ejemplo, los cdigos pueden ser usados para identificar fases del proyecto, sub-fases,
localidad del trabajo, eventos del proyecto, puertas, logros significativos, fuentes de
abastecimiento, fuente de diseo, la persona u organizacin responsable de realizar la
actividad, etc. Estos cdigos pueden ser usados solos o en mltiples combinaciones.
Para alcanzar la flexibilidad y funcionalidad mejorada, la mayora de software de
programacin del tiempo permite mltiples cdigos para cada actividad.
Un esquema estructurado de numeracin o identificacin de actividades debe formar
parte del diseo de la codificacin global. El uso de un sistema estructurado de
identificacin de actividades provee a los usuarios del cronograma una mejor
comprensin de cmo se adapta una actividad en particular al esquema global del
proyecto captando el significado del identificador de la actividad. Por ejemplo, el
esquema de identificacin podra incluso ligarse a la EDT del proyecto. Como un
mnimo, un identificador de una actividad necesita ser nico y seguir un esquema
apropiado al proyecto.

.9 Planificacin de Recursos

Si el cronograma modelo va a incluir recursos de cualquier tipo, el plan de gestin del
cronograma modelo identificar los elementos requeridos para la planificacin y
gestin de recursos. Los tems a considerar son disponibilidad de recursos,
calendarios de recursos y conjuntos de habilidades de los recursos. Aunque no se
requiere cargar los recursos al cronograma modelo, este estndar prctico lo
considera como una buena prctica y reconoce que los recursos deberan ser
considerados por el equipo del proyecto cuando se determinen las duraciones de las
actividades y su secuencia. Un cronograma con los recursos cargados claramente
indica las interdependencias y los impactos que la disponibilidad de recursos tendr
en la duracin y el costo del proyecto.

.10 Indicadores de Desempeo

Para que los interesados conozcan cmo se est desempeando el proyecto,
muchos proyectos definen indicadores claves de desempeo (KPIs), los cuales
permiten al equipo del proyecto medir el progreso y el desempeo a travs de
metas predefinidas (por ejemplo, retroalimentacin/calificacin del cliente,
calificacin del equipo de proyecto y EVM). La Gestin del Valor Ganado (EVM)
tiene la habilidad de combinar medidas de alcance, cronograma y costo en un
sistema integrado que provee indicadores basados en costos. La Gestin del Valor
Ganado (EVM) puede expandirse para incluir el concepto de tiempo ganado, el
cual tiene el objetivo de proveer indicadores basados en el tiempo para
complementar los indicadores basados en el costo para el desempeo el proyecto.
Para ms informacin sobre EVM y tiempo ganado, refirase al Estndar Prctico
de Gestin del Valor Ganado.

.11 Modelo de Cronograma Maestro

El cronograma modelo puede ser designado y construido como un Proyecto Maestro
que contiene sub-proyectos. Los sub-proyectos puede ser estructurados de acuerdo a
diversos equipos que abarcan el proyecto, tales como ejecucin por fases (ingeniera,
produccin, pruebas e integracin), equipos distribuidos globalmente o la estrategia
de contratacin (mltiples proyectos, mltiples directores de proyecto). Estos sub-
proyectos deben estar relacionados entre s en ciertos puntos de entrega/aceptacin o
interconexin, asegurando que exista una conexin entre los planes. El Plan de
Gestin del Cronograma Modelo definir los pasos para la creacin, gestin y control
del cronograma maestro, sub-proyectos e interdependencias entre proyectos.


3.2 CREACIN DEL CRONOGRAMA MODELO

Esta seccin ofrece una visin general de los elementos esenciales para desarrollar un
buen cronograma modelo. Las buenas prcticas se muestran para cada componente
contenido en la lista de componentes de este estndar prctico en el captulo 4. Una
revisin del captulo 4 es altamente recomendada par entender todos los aspectos
asociados con cada componente. Es crucial tomar en consideracin toda la
informacin, procedimientos y restricciones documentadas en la seccin gestin del
cronograma modelo.
El propsito del cronograma modelo es proveer un plan detallado y til que pueda ser
usado por el Director del Proyecto y el equipo el proyecto para asistirlos en la
finalizacin exitosa del proyecto. El cronograma modelo llega a ser una herramienta
desarrollada por el equipo del proyecto, la cual documenta la visin del equipo de
cmo se ejecutar el proyecto. El cronograma modelo incluyen cundo se supone que
iniciarn y finalizarn las actividades y es modificado apropiadamente para reflejar
los cambios en el progreso, alcance, etc., a medida que son aadidos al cronograma
modelo durante el ciclo de vida del proyecto. Un cronograma modelo bien
desarrollado es una herramienta dinmica que se utiliza para proveer una prediccin
razonable de cundo se espera completar el trabajo faltante del proyecto.
Simultneamente, permite al equipo de trabajo mirar el desempeo del proyecto a la
fecha y utilizar la informacin para hacer pronsticos acertados de la evolucin del
proyecto que falta por completar. Ms an, una vez que el proyecto se consuma, el
cronograma modelo forma la base para las actividades sobre lecciones aprendidas y
se convierte en la base para proyectos similares en el futuro.
El cronograma modelo describe el trabajo pendiente (qu?), los recursos requeridos
para hacerlo (quin? y qu?) y la secuencia ptima de actividades incluyendo inicios,
finales y relaciones (cundo?) de actividades. La forma de hacer el trabajo (cmo?)
es definida por otros documentos del plan de proyecto general. Una de las acciones
iniciales crticas es establecer un cronograma modelo realista y realizable. Algunos
puntos importantes a considerar durante la creacin del cronograma modelo son:
Determine que los requisitos del proyecto fueron entendidos y satisfechos. El
equipo del proyecto revisa y entiende los documentos del alcance del proyecto,
con especial nfasis en la EDT. Los documentos del alcance del proyecto
proveen el contexto, informacin y entendimiento necesario para desarrollar el
cronograma modelo. El propsito es asegurar que todos los aspectos de la
ejecucin del proyecto han sido definidos adecuadamente e incluidos en el
cronograma modelo. Las actividades en el cronograma modelo representan el
trabajo que produce los entregables o los paquetes de trabajo de la EDT;
consecuentemente, todos los paquetes de trabajo de la EDT deben ser
directamente localizables en una actividad o grupo de actividades de un
cronograma. Usualmente las actividades del cronograma puede ser
organizadas para reflejar la jerarqua de la EDT. Por el contrario, cada
actividad debe estar contenida en un nico elemento de la EDT.
Verifique la disponibilidad de recursos y las asignaciones. El equipo del proyecto
se beneficia grandemente de un cronograma cargado con recursos. La mano de
obra, materiales, equipo e infraestructura necesaria para el logro de las
actividades del proyecto puede ser planificada por adelantado y los problemas
anticipados pueden ser mitigados. Un cronograma modelo bsico producido
para un proyecto supone que existe disponibilidad suficiente de mano de obra
y equipo para lograr las actividades tal como se program. Este no es siempre
el caso debido a que en un proyecto grande y complejo, podra no ser obvio que
exista una deficiencia de recursos. En el caso de proyectos grandes y
complejos que involucran mltiples organizaciones y tienen una larga
duracin, podra ser necesario incluir los recursos en el cronograma modelo.
Vea el PMBOK para ms informacin sobre recursos. De la misma forma que
los cdigos de actividades pueden ser usados para clasificar y organizar
actividades, los cdigos de recursos (atributos) pueden ser asignados a los
recursos para clasificarlos de acuerdo a la organizacin, nivel de habilidad o
tipo, estructura de reporte, etc. Adems, los identificadores de recursos pueden
ser estructurados en forma esquemtica similar a los identificadores de las
actividades.


3.2.1 DESARROLLAR LA LNEA DE BASE DEL CRONOGRAMA MODELO

El desarrollo de un buen cronograma modelo se logra a travs de la aplicacin
consistente de atinadas y buenas prcticas. La experiencia ganada a travs del tiempo
asistir en la seleccin de respuestas apropiadas al diseo de requerimientos para un
cronograma modelo. Los pasos clave incluyen:



.1 Definir Hitos

Una vez que existe un entendimiento de toda la estructura de datos del proyecto
discutida previamente, empiece por describir los hitos del proyecto. Los hitos tendrn
una duracin cero, sin recursos asignados y se usan como puntos de referencia para
medir el avance y pueden tambin reflejar los puntos de inicio y final para varios
eventos del proyecto. Generalmente, un hito va a representar el inicio o la finalizacin
de una porcin o entregable del proyecto y tambin puede estar asociado con
restricciones externas, como la entrega de un permiso o un equipo requerido. Cada
proyecto debe tener un hito de inicio y un hito de final. El proyecto contendr una lista
de hitos inicialmente desarrollada a medida que se crea el cronograma. Los hitos los
pudieron haber tenido origen en el cliente, los miembros del equipo o los interesados.
A medida que se desarrolla el cronograma modelo, se van aadiendo tantos hitos
como se necesiten. Es un proceso iterativo. (Nota: las actividades pueden ser definidas
antes de los hitos).

.2 Diseo de las Actividades del Proyecto

Empiece a crear la lista de actividades que se necesitar realizar para completar el
proyecto, basadas en la EDT y elaboradas por el equipo que ser responsable de la
ejecucin del trabajo. Las caractersticas de una actividad bien diseada incluyen:
La actividad es un elemento (o bloque) de trabajo medible y discreto que es un
elemento tangible del alcance del proyecto.
Una nica persona es responsable por la ejecucin de la actividad. Esto no
imposibilita la idea que mltiples recursos puedan ser requeridos para lograr
la actividad, pero requiere que una nica entidad sea responsable de su
desempeo. Esa persona debe ser la misma que reportar el progreso de la
actividad.
Las actividades describen el trabajo a ser realizado. Como tal, la descripcin de
cada actividad inicia con un verbo y contiene un objeto nico y especfico. No
obstante, chorrear pared podra ser descriptiva de una tarea, la descripcin
de la actividad requiere ser ms especfica. Los adjetivos podran ser de ayuda
para clarificar ambigedades. Por ejemplo, chorrear la placa de fundacin de
la pared este de x a y o revisar la terminologa del captulo 3. Cada
descripcin de actividad debe ser nica y no debe dejar espacio a confusin,
esto es, podr ser identificada sin ambigedad y debe ser independiente del
grupo u organizacin que presenta el cronograma.
El trabajo representado por una actividad, una vez iniciado, debe ser capaz de
ser completado sin interrupcin (excepto por periodos de no-trabajo que
ocurran naturalmente en el calendario). Si el trabajo de una actividad es
suspendido o retrasado, es beneficioso para la actividad dividirlo en dos o ms
actividades en puntos naturales de quiebra.
Tpicamente, la duracin de una actividad debera ser menor a dos veces el ciclo de
actualizacin. Esto permite el reporte de inicio y finalizacin de una actividad dentro
de uno o dos ciclos de actualizacin, permitiendo a la administracin concentrarse en
desempeo y acciones correctivas, si se requieren. Son excepciones a esta regla
general las actividades continuas (por ejemplo, la construccin de un tnel de 2 millas
o la pavimentacin de varias millas de autopista), las actividades de adquisicin donde
un nico tem de trabajo (por ejemplo, fabricar y enviar un componente a un lugar
remoto) podra llevar significativamente ms tiempo que dos ciclos de actualizacin, o
una actividad a nivel de esfuerzo (LOE) como el soporte administrativo. En estos
casos, la duracin de la actividad simplemente debe reflejar el tiempo esperado para
la actividad. Se necesita tener cuidado con las actividades a nivel de esfuerzo (LOE) ya
que si se les da duraciones estticas iguales a la longitud del proyecto terminarn
siendo parte de la ruta crtica. Por su misma naturaleza de apoyo a actividades
puntuales del proyecto, las LOE no pueden definir la duracin del proyecto y no
pueden ser crticas. Es una buena prctica definir las actividades LOE de tal manera
que tomen su duracin de las actividades detalladas que ellas apoyan.
Cuando se complete, la lista de actividades describir el 100% del trabajo requerido
para completar el proyecto, aunque no todas las actividades necesarias necesitan ser
completamente detalladas si se utiliza la Planificacin Gradual.

.3 Secuenciar las Actividades

Secuenciar las actividades e hitos juntos de manera lgica es la base de cualquier
cronograma modelo. El mtodo de conexin es definido como una relacin. Cada
actividad e hito excepto la primera (sin predecesor) y la ltima (sin sucesor) deben
estar conectadas a por lo menos un predecesor y un sucesor. Con excepcin del hito
de inicio, se necesita que algo ocurra previo a cualquier actividad de inicio y
sucesivamente, esa actividad tiene que estar total o parcialmente completada para
que otra actividad pueda iniciar. Asegurar la conformidad con esta prctica va a
prevenir que el cronograma tenga finales abiertos, donde las actividades o hitos no
tengan predecesores o sucesores, con la excepcin del primer y ltimo hito.
Tpicamente, cada actividad predecesora debe terminar antes del inicio de su
actividad (o actividades) sucesora(s) (conocida como relacin final-a-inicio (FS).
Algunas veces es necesario traslapar actividades; una opcin podra ser utilizar las
relaciones inicio-a-inicio (SS), final-a-final (FF) o inicio-a-final (SF). La figura 3-1
provee ejemplos de los cuatro tipos de relaciones en PDM (las ms comunes en la
metodologa CPM). Cuando sea posible, la relacin FS debe ser usada. Si se requiere
utilizar otros tipos de relaciones, deben ser usadas con moderacin y con completo
entendimiento de cmo se implementaron las relaciones en el software que se est
utilizando. Idealmente, la secuencia de todas las actividades se definir de tal manera
que el inicio de cada actividad tiene una relacin lgica de un predecesor y el final de
cada actividad tiene una relacin lgica con un sucesor.

Tambin se pueden aadir demoras a algunas relaciones. Una demora impone un
retraso entre las actividades predecesora y sucesora. Por ejemplo, si una actividad
tiene una dependencia inicio-a-inicio (SS) con una demora de 15 das, atrasar el
inicio de la actividad sucesora hasta 5 das luego de que la actividad predecesora ha
empezado. El programador del cronograma es advertido de usar las demoras con
cuidado y entendiendo sus impactos. Las demoras tambin son usadas para
representar atrasos que sean fsicamente necesarios, que no representen trabajo y
que tengan duracin. Algunos programadores del cronograma se vern tentados a
usar demoras para representar un periodo de tiempo cuando el trabajo efectivamente
se est produciendo, tal como la revisin de un documento antes de que proceda la
siguiente fase. Se recomienda que estos tipos de trabajo se muestren como actividades
en el cronograma modelo en vez de usar una demora. Cuando se incluyen tales
actividades, se pueden codificar para mostrar que estas actividades son las cuales otra
parte, por ejemplo el cliente, es la responsable. Esta prctica permite un mejor control
del proyecto y permite hacer muy visible el impacto de una entidad especfica en el
proyecto.
El uso de ms de un calendario en un cronograma modelo podra impactar los
resultados de clculos de demoras en un cronograma modelo. Adems, es
extremadamente importante comprender cmo utilizan los calendarios mltiples los
diferentes paquetes de software.
Tambin es posible asignar restricciones a las actividades y a los hitos que requiere la
actividad o el hito para iniciar o finalizar en determinados puntos de tiempo. Estudie
los diversos tipos de restricciones que podran ser utilizadas y entienda el efecto y
matiz que tiene su uso sobre el cronograma antes de utilizarlas. La prctica
generalmente aceptada es que las restricciones y atrasos no deben ser usados para
reemplazar la adicin de actividades y relaciones. Sin embargo, a modo de ejemplo, el
uso de restricciones a menudo se admite como necesario para cumplir obligaciones
contractuales.
En general, cada actividad debe tener un predecesor fin-inicio o inicio-inicio y un
sucesor fin-inicio o fin-fin. Sin esos tipos de relaciones lgicas las actividades se
denominan colgadas y la incertidumbre en sus duraciones no ser necesariamente
transmitida de la manera adecuada al resto del cronograma modelo.

.4 Determine Recursos para cada Actividad

Estimar los Recursos de las Actividades es el proceso de determinar el tipo y cantidad
de material, personal, equipo o infraestructura requerida para ejecutar cada actividad.
Si un proyecto est restringido en trminos de recursos y la duracin del proyecto
puede ser impactada, los recursos deben ser incorporados al cronograma modelo.
Aunque algunas veces se ejecutan juntos, El proceso Estimar los Recursos de la
Actividad debe ser completado antes de Estimar las Duraciones de las Actividades
(vea el PMBOK para ms informacin). Las horas requeridas para un diseador con
experiencia para cumplir a cabalidad la actividad versus lo que demora un diseador
inexperto en realizar la misma actividad podra ser considerablemente diferente,
impactando as la duracin y calidad de los productos de la actividad y finalmente el
costo del proyecto. En algunos proyectos, especialmente aquellos con un alcance ms
pequeo, definir actividades, secuenciar actividades, estimar recursos, estimar
duracin de las actividades y desarrollar el cronograma modelo estn tan
ntimamente relacionadas que son vistas como un nico proceso. Los recursos pueden
definitivamente impactar el camino crtico si no son considerados por el equipo del
proyecto.

.5 Determinar la Duracin de Cada Actividad

La duracin es un estimado de qu tanto tiempo va a necesitar completar
satisfactoriamente el trabajo relacionado con la actividad. En muchos casos, el
nmero de recursos que se espera tener disponibles para culminar una actividad,
junto con la productividad de esos recursos, puede determinar la duracin de la
actividad. Un cambio en los recursos asignados a determinada actividad tendr un
efecto en la duracin, pero esto no es una simple relacin directa. Otros factores que
influyen en la duracin sin son el tipo o nivel de habilidad de los recursos disponibles
para emprender el trabajo, calendarios de recursos y la naturaleza intrnseca del
trabajo. Algunas actividades (por ejemplo una prueba de esfuerzo de 24 horas)
llevarn una cantidad de tiempo en completarse sin importar la asignacin de
recursos.
Debido a que es factible estimar la duracin para una actividad en cualquier momento,
las buenas prcticas recomiendan definir la actividad primero y luego ligarla de
manera lgica a la secuencia global del cronograma y luego concentrarse en los
recursos y la duracin de la actividad. En ese momento, la relacin entre la duracin
de la actividad y el trabajo en el cronograma ser mejor entendida; por lo tanto los
flujos de recursos, los tamaos del equipo de las actividades y el cmo se pueden
empezar a determinar. La relacin entre la duracin y el costo de una actividad se
har explcita en la base de estimaciones o supuestos tanto para el costo como para el
cronograma. Este documento debe mantenerse actualizado a medida que las
duraciones del cronograma cambian durante el mantenimiento del cronograma. Vea
la seccin 3.3 Mantenimiento del Cronograma Modelo y la seccin 3.4 Anlisis del
Cronograma Modelo para ms informacin.
Es importante entender el mtodo utilizado por el cronograma modelo con el fin de
planear las actividades relacionadas con estimacin de duraciones para cada actividad
del cronograma. El mtodo usado puede implicar un cronograma determinstico o
probabilstico. El modelo de cronograma determinstico es una red de actividades
conectadas con dependencias que describen el trabajo a ser realizado, duracin
esttica y la fecha planeada para completar el proyecto si todo va de acuerdo a lo
planeado. El modelo de cronograma probabilstico es una red con todos los elementos
de un modelo determinstico, pero la duracin de las actividades de las tareas son
variables aleatorias. Para ms informacin sobre estimar la duracin de una actividad,
por favor refirase al Estndar Prctico para la Estimacin del Proyecto. Para ms
informacin sobre buenas prcticas para anlisis de riesgos del proyecto usando
modelos de cronograma probabilsticos, vea el Estndar Prctico para la Gestin del
Riesgo.

.6 Analice la Salida del Cronograma

Una vez completado, el cronograma modelo contendr un grupo de actividades nicas
con duraciones variables, conectadas por relaciones lgicas definidas. Provee al
equipo de proyecto la informacin de lo necesario que requiere ser llevado a cabo y la
secuencia requerida para completar los entregables del proyecto. Sin embargo,
todava no indica cundo deben ser ejecutadas estas actividades. La herramienta de
cronograma es activada para obtener dicha informacin, para calcular las fechas y
otros valores dentro del cronograma modelo en concordancia con el mtodo de
programacin del tiempo elegido. Sin importar la velocidad de los programas de
cmputo, la funcin de programacin del tiempo siempre requiere tres distintos
procesos para anlisis del tiempo y un cuarto proceso, si se utiliza la nivelacin de
recursos (resource smoothing). Los distintos pasos son:
Se asigna una fecha de inicio al hito de inicio. Entonces, movindose a travs de
la red de actividad en actividad (de izquierda a derecha) y en la secuencia
definida por las relaciones lgicas, se asignan fechas de inicio y finalizacin a
cada actividad e hito, de acuerdo a las duraciones definidas. Esto se llama
paso hacia adelante. Las fechas de inicio y finalizacin para cada actividad
se llaman el inicio ms temprano y el fin ms temprano y cuando el anlisis
alcance el final de la red, establece el fin ms temprano posible para el proyecto
y la duracin ms corta basada en las duraciones estimadas para las
actividades y las relaciones lgicas como fueron definidas.
Luego, se asigna una fecha de finalizacin al hito de fin. Esta podra ser la
misma fecha que la que se calcul con el paso hacia adelante o una fecha
diferente aplicada como una restriccin. El proceso de anlisis entonces trabaja
hacia atrs a travs del diagrama de red de derecha a izquierda hasta llegar al
hito de inicio y otro grupo de fechas de inicio y finalizacin es asignado a cada
actividad. Esto se llama paso hacia atrs y establece el inicio ms tardo y el
final ms tardo asignado a cada actividad o hito.
Se calculan los valores de holgura comparando las fechas ms prximas y las
fechas ms tardas, como sigue:
o La holgura total es calculada substrayendo la fecha ms temprana de
inicio de la fecha ms tarda de inicio (o el inicio ms temprano del
inicio ms tardo). Una holgura total negativa no es factible sin cambiar
el plan.
o La holgura libre es calculada restando la fecha ms temprana de fin de
la actividad de la fecha ms temprana de inicio del ms temprano de sus
sucesores. La holgura libre nunca es un valor negativo.
Una vez que se calcularon los valores de holgura, se puede realizar la
nivelacin de recursos para minimizar sobre colocaciones de recursos o
reducir las fluctuaciones en la demanda de recursos. Si este proceso se realiza
automticamente, el programador del tiempo necesita determinar los procesos
y algoritmos que se estn utilizando. La mayora de los paquetes de
programacin del tiempo tienen opciones mltiples y configuraciones que
pueden tener un impacto significativo en el cronograma nivelado en recursos.
Sin importar que configuracin tiene el software, siempre debe haber un
equilibrio entre dejar que la nivelacin de recursos extienda la duracin total
del proyecto y permitir el uso de ms recursos que los que se permitieron
inicialmente. Los recursos nivelados en un rea pueden estar sobre asignados
en otras reas. Una vista completa de la asignacin de recursos a travs de
todas las actividades debe ser revisada antes de finalizar la nivelacin de
recursos. Algunos se vern tentados a hacer nivelacin de recursos
manualmente, ajustando la lgica o aadiendo restricciones para atrasar el
inicio de ciertas actividades; esto no es una buena prctica debido a que
interfiere con el clculo normal del cronograma.



.7 Aprobar el Cronograma

El equipo de proyecto debe estar activamente involucrado en la revisin de
resultados de este proceso inicial de programacin del tiempo. La revisin debe
considerar el inicio y el final de proyecto analizado, fechas de terminacin de hitos,
ruta crtica (el trayecto ms largo para el proyecto como lo definan las restricciones),
valores de holgura total y requerimientos de recursos (comparados con
disponibilidad de recursos) para determinar la aceptabilidad del cronograma. Cuando
se requieran ajustes, se realizan los cambios a la lgica del cronograma, asignacin de
recursos y/o duraciones y entonces se vuelve a analizar el cronograma. La
modificacin ms comn requerida tiene que ver con acciones para reducir la
duracin total del cronograma. Las tcnicas clave usadas para comprimir el
cronograma son la compresin (crashing) y la aceleracin (fast-tracking). La
compresin del cronograma (crashing) consiste bsicamente en aadir recursos a
actividades crticas para acortar sus duraciones mientras que la aceleracin (fast-
tracking) consiste en cambiar la lgica mediante el traslape de actividades crticas en
vez de trabajarlas en estricta secuencia. La compresin (crashing) nicamente
funciona para actividades que son llevadas a cabo con esfuerzo en las que aadir
recursos va a reducir la duracin de la actividad.
La compresin (crashing) tpicamente incrementa los costos del proyecto por un
determinado factor mientras que la aceleracin (fast-tracking) incrementa el riesgo de
volver a hacer el trabajo ya que las actividades comenzaron antes de que sus
predecesores iniciales hayan sido completados (vea tambin el captulo 6 de la gua
PMBOK). Estas iteraciones continan hasta que se desarrolle un cronograma
aceptable, uno que los interesados acuerden que sea realizable. El proceso formal para
la aprobacin de la lnea de base del cronograma ser definido en el Plan de Gestin
del Cronograma Modelo.

.8 Lnea de Base del Cronograma Modelo

Una vez acordada, la primera versin del cronograma que sea desarrollada
completamente para la captura o copia para referencia futura se llama la lnea de base
del cronograma modelo. Esta lnea de base se convierte en el punto de comparacin
contra el cual se va a medir el desempeo del proyecto. Es una prctica generalmente
aceptada que cada proyecto tiene una lnea de base del cronograma modelo en sitio
antes de la ejecucin del trabajo del proyecto. Una vez que la lnea base haya sido
aprobada a travs de procedimientos formales, los reportes se distribuirn en
concordancia con el plan de comunicaciones y los cambios a la lnea base son
monitoreados y controlados a travs de procesos integrados de control de cambios.

3.3 MANTENIMIENTO DEL CRONOGRAMA MODELO

La mayora de proyectos inevitablemente va a experimentar cambios. Para asegurar
una ejecucin exitosa, son necesarios un control de cambios efectivo y procedimientos
de mantenimiento disciplinados. La clave es determinar cmo el proyecto va a
aprobar y dar seguimiento a los cambios a medida que ocurran durante el ciclo de
vida del proyecto. El cambio puede ocurrir simplemente por un progreso del trabajo
ms rpido o ms lento de lo planeado, lo mismo que cuando los cambios en otros
elementos del proyecto ocurren (por ejemplo cambios en el alcance) y/o si el equipo
del proyecto decide modificar su estrategia con respecto al trabajo del proyecto.
El seguimiento del avance inicia despus de que se defini la lnea de base del modelo
del proyecto, el trabajo inicia y se implementa un monitoreo y control continuo. Estos
procesos son importantes para ayudar a identificar problemas tan pronto como sea
posible, minimizando su impacto en la terminacin exitosa del proyecto. Los
principales pasos para el seguimiento del avance son como sigue:
Guardar una lnea base de cronograma modelo que contenga las fechas contra
las cuales se comparar el avance. El cronograma modelo actual puede ser
copiado y aprobado como lnea de base o un cronograma modelo ms
adecuado puede ser aprobado como lnea de base.
El avance del cronograma es reportado para un dato de fecha especfica,
tambin conocida como fecha de estado, fecha de actualizacin, fecha actual, o
fecha presente. Este avance, como mnimo, debe incluir las fechas actuales de
inicio y de fin, duraciones faltantes y porcentajes completados.
Asignar los nuevos datos de fechas y recalcular todas las fechas de actividades
son los ltimos pasos para adelantar el cronograma modelo.
El proceso de estado/actualizacin se determina regularmente durante el proceso de
planificacin del proyecto. Los pasos requeridos para mantener el cronograma en
cada estado/actualizacin se describen en los apartados 3.3.1 a 3.3.7



3.3.1 OBTENER EL TRABAJO PRESENTE Y EL TRABAJO RESTANTE

Obtenga el estado actual del trabajo a intervalos de tiempo predeterminados para el
proyecto. La informacin recogida incluye las fechas de inicio reales para todas las
actividades que han comenzado y las fechas de fin reales de todas las actividades de
han sido completadas a la fecha. Cuando una actividad est en progreso, se determina
la cantidad de trabajo alcanzada y el tiempo necesario para completar el trabajo
restante. La obtencin del estado tambin incluye los cambios en las duraciones para
futuras actividades. Otra informacin recolectada ac puede incluir informacin sobre
uso de recursos y costos incurridos. Los datos son recabados a una fecha determinada.
Esta fecha es anloga al tiempo actual de la gestin del desempeo del valor ganado
(EVPM).

3.3.2 ACTUALIZAR Y MEDIR EL AVANCE DEL CRONOGRAMA MODELO DE ACUERDO AL
ESTADO ACTUAL

Introduzca informacin del estado en el cronograma modelo y reanalice el trabajo
faltante para determinar el estado del proyecto. Todo el trabajo incompleto va a ser
reprogramado a una fecha/hora igual o superior a la fecha consignada. Se debe tener
cuidado ya que muchas herramientas de software permiten las fechas actuales
aplicadas al trabajo futuro. Las prcticas de control de calidad deben poder identificar
el ingreso de datos vigentes ms all de la informacin sobre fechas y porcentaje
completado que se estn reportando y no sean vlidos en relacin con las fechas.

3.3.3 COMPARE Y RESUELVA CUALQUIER DESVIACIN

Compare el cronograma modelo recin actualizado con el cronograma modelo de la
lnea de base y gestione costo y variaciones en el tiempo. Los niveles mnimos de
variacin definidos en el plan de gestin del cronograma modelo pueden ser usados
para determinar cules actividades y condiciones requieren reportes y acciones
adicionales. Una variacin de fechas usada comnmente es la variacin final entre el
final ms temprano y el final de la lnea de base, la cual es frecuentemente expresada
en unidades como das laborales. Comparar el estado de una actividad contra ms de
un objetivo podra ser til, por ejemplo el cronograma actual versus:
El plan original la lnea de base- para ver la demora comparada con el plan
original.
El ltimo periodo actualizado para ver los cambios desde la ltima
actualizacin.

3.3.4 ACTUALICE EL CRONOGRAMA MODELO CON LOS CAMBIOS APROBADOS

Actualice el cronograma modelo con cualesquiera cambios aprobados que resulten del
proceso de control de cambios para asegurar que el cronograma modelo represente el
100% del alcance del trabajo del proyecto. Los procesos de actualizacin y ajuste
podran necesitar un nmero de iteraciones para mantener un cronograma modelo
que se mantenga realista y realizable.

3.3.5 ACTUALICE LA LNEA DE BASE DEL CRONOGRAMA MODELO

Actualice, a travs del proceso formal de control de cambios, la lnea de base del
cronograma modelo si han sido incorporados cambios autorizados en el alcance o si
otros cambios han sido incorporados que modifiquen significativamente la naturaleza
de la ejecucin del proyecto. Solamente las actividades que son nuevas o con cambios
aprobados y aquellas actividades que estn directa o indirectamente ligadas a ellas,
deben ser ajustadas en su lnea de base.

3.3.6 COMUNIQUE

Distribuya reportes (presentaciones del cronograma modelo, vea las figuras 2-1 y 2-7)
de acuerdo con el plan de gestin del cronograma modelo y el plan de gestin de
comunicaciones del proyecto una vez que el ciclo de actualizacin del cronograma ha
sido completado.



3.3.7 MANTENGA LOS REGISTROS

La gestin adecuada de registros es parte del control de la configuracin. Los registros
bien mantenidos que detallen la lgica inicial y puntos principales de decisin del
proyecto y los procesos de pensamiento que permitieron crear la lgica de flujo del
cronograma de lnea de base ayudan en defensa de las acciones tomadas y lecciones
aprendidas. Mantenga registros que expliquen todos los cambios en la duracin de
actividades o lgica durante la realizacin de alteraciones en el cronograma modelo.
Las notas de registro de las actividades a menudo se utilizan para este propsito.
Estos registros proveern informacin valiosa si fuera necesario reconstruir lo que
pas y por qu.
Muchas de las buenas prcticas y elementos descritos anteriormente tambin estn
incluidos dentro de los detalles de cada componente contenido dentro de los
componentes del cronograma modelo listados como se presenta en el captulo 4. Un
entendimiento completo de los diversos componentes se requiere para maximizar el
potencial para su correcta aplicacin y el desarrollo de un cronograma atinado.

3.4 ANLISIS DEL CRONOGRAMA MODELO

El anlisis del cronograma utiliza herramientas comunes y tcnicas a travs del ciclo
de vida del proyecto con el objetivo de identificar la desviacin de la lnea de base del
cronograma modelo. El anlisis del cronograma es responsabilidad del equipo del
proyecto y el objetivo principal del anlisis es la identificacin temprana de amenazas
y oportunidades a los objetivos del proyecto.
Estas son varias herramientas y tcnicas disponibles para realizar el anlisis del
cronograma modelo. Los procedimientos especficos y las polticas a utilizar para un
proyecto se describen en el Plan de Gestin del Cronograma del Proyecto. Los tems
ms comunes de revisin durante el anlisis del cronograma se describen en los
apartados 3.4.1 a 3.4.11.




3.4.1 RUTA CRTICA Y ACTIVIDADES CRTICAS

.1 Ruta Crtica

La ruta crtica es habitualmente, pero no siempre, la secuencia de las actividades del
cronograma que predice o define la duracin ms larga del proyecto. Generalmente, es
la ruta ms larga a travs del proyecto y por lo tanto determina la duracin del
proyecto. Sin embargo, una ruta crtica puede finalizar, por ejemplo, en un hito del
cronograma que est en el medio del cronograma modelo y que tiene una restriccin
de final-no-ms-all-de. (Recuerde que las restricciones son para utilizarse
selectivamente en los cronogramas modelo). Pero el(los) riesgo(s) y la(s)
restriccin(es) pueden alterar la ruta crtica, elevando la importancia de menos
actividades en apariencia y causando cambios inesperados a la duracin y al costo del
proyecto. Un proyecto puede tener mltiples rutas crticas. Un proyecto con mltiples
rutas crticas tiene un mayor nivel de riesgo debido a que la falla en el cumplimiento
de cualquiera de ellas resultar en la falla en completar todos los hitos del proyecto.

.2 Actividades Crticas

Es importante distinguir entre actividades de la ruta crtica y actividades crticas. Las
actividades de la ruta crtica son aquellas actividades contenidas en la(s) ruta(s)
crtica(s). Las actividades crticas son aquellas actividades vitales para el xito de un
proyecto, aun cuando no estn en el camino crtico previsto del CPM o en la cadena
crtica. Las actividades crticas generalmente tienen un alto riesgo en trminos de
alcance, cronograma y costo y pueden causar no solo un retraso en la fecha final del
proyecto, sino una mayor posibilidad de que el proyecto falle. Todas las actividades de
la ruta crtica tambin son consideradas actividades crticas. Los clculos de ruta
crtica consideran actividades y restricciones para determinar el camino ms largo del
proyecto. Las actividades crticas pueden estar fuera de la ruta crtica.

3.4.2 HOLGURA TOTAL Y HOLGURA LIBRE

La holgura libre representa la cantidad de tiempo en la que la fecha ms temprana de
fin de una actividad del CPM puede ser retrasada sin impactar la fecha ms temprana
de inicio de cualquier actividad sucesora del CPM. La holgura total representa la
cantidad de tiempo que el tiempo ms temprano de inicio o el tiempo ms temprano
de fin de una actividad del CPM pueden ser retrasados sin impactar la fecha ms
tarda de fin del proyecto completo o sin violar una fecha restringida del cronograma
modelo. Revise la holgura total y la holgura libre de cada actividad para determinar si
han cambiado desde la ltima actualizacin. Los cambios en la holgura total indican
una amenaza a la terminacin del proyecto o de hitos especficos; la holgura libre
indica cmo impacta la falta de avance en sus sucesores inmediatos. La holgura total y
la holgura libre pueden ser reducidas por dependencias externas y otras fechas
restrictivas fuertes listadas en el cronograma modelo. Estas dependencias externas
deben ser explicadas en los nodos de la actividad o ligadas a hitos externos.
El seguimiento y gestin de estos dos componentes vitales es crtico para completar el
proyecto a tiempo y para cumplir los hitos tal y como se planearon. Las disminuciones
de holgura total y holgura libre indican donde deben desarrollarse planes de
recuperacin.

3.4.3 ACTIVIDADES DE NIVEL DE ESFUERZO (LOE)

Las actividades de nivel de esfuerzo (LOE) estn para apoyar actividades del trabajo o
el esfuerzo total del proyecto. Ejemplos de esta actividad son la gestin del proyecto,
la contabilidad del presupuesto, relacin con el cliente o la rotacin de maquinaria de
durante el almacenamiento (mantenimiento preventivo), etc.
Debido a que una actividad de nivel de esfuerzo (LOE) no es por s misma un tem de
trabajo directamente asociado con la realizacin del producto final del proyecto,
servicio o resultado, sino que es una actividad que apoya tal trabajo, su duracin est
basada en la duracin de las actividades discretas de trabajo que est apoyando. Por
ejemplo, cuando se proveen fuerzas de seguridad para dotar de personal la entrada
del sitio de trabajo, ellas empezarn cuando inicie el trabajo y finalizarn cuando el
trabajo est terminado. Como resultado, una actividad LOE nunca podr estar en la
ruta crtica del cronograma modelo ya que nunca aade tiempo al proyecto. Ms bien,
la instalacin de maquinaria estara en el camino crtico y la actividad de
mantenimiento preventivo se volvera ms corta o ms larga solamente si lo hace el
tiempo-en-almacenaje de la maquinaria. Cuando se introducen actividades LOE en un
cronograma creado con el mtodo de la ruta crtica, las actividades LOE se programan
normalmente como inicio-inicio (SS) o fin-fin (FF) sucesoras a las actividades
conductoras. En un diagrama de redes, estas dos relaciones hacen parecer como si la
actividad LOE estuviera colgando del inicio o final de las distintas actividades. Como
resultado, la actividad LOE diagramada de esta manera es referida como una
actividad hamaca. Una actividad hamaca es una actividad de transicin, usando
relaciones inicio-inicio y fin-fin a las actividades que sostiene. La actividad LOE, a
diferencia de las actividades hamaca puede tener cualquier tipo de relacin, no estn
limitadas a relaciones inicio-inicio o fin-fin. Las actividades LOE pueden tener muchos
tipos de relaciones asociadas con ellas. La nivelacin de recursos podra no realizarse
y no aplicarse restricciones a las actividades LOE; ellas usan sus calendarios asignados
para concretar sus fechas.

3.4.4 DISTRIBUCIN PROBABILSTICA DE DURACIN DE ACTIVIDADES

Si las duraciones de las actividades implican un gran componente de incertidumbre,
una tcnica de estimacin comnmente usada es la estimacin de tres puntos. Estos
tres puntos corresponden a la duracin de la actividad definida como optimista, ms
probable y pesimista. Adicionalmente, el registro de riesgos puede tambin ser usado
para apoyar la estimacin de incertidumbre en la duracin de actividades. Para poder
cuantificar la incertidumbre sobre la duracin total del proyecto, empezando con la
estimacin de los tres puntos para cada actividad, el PERT (que usa una aproximacin
de la distribucin beta y la ecuacin en la seccin 2.2.3) puede ser utilizado. La
duracin optimista de una actividad y la duracin pesimista representan duraciones
probables, pero no el dominio completo de valores. Las estimaciones de duracin de
tres puntos deben ser hechas por quienes van a ejecutar las actividades o por alguien
con experiencia en la ejecucin de actividades similares. La aproximacin ms comn
para crear la distribucin probabilstica es estimar el valor ms probable tan exacto
como sea posible y entonces sesgar la distribucin hacia los valores mximo y mnimo.
El grado en el cual la distribucin es sesgada se sugiere por la forma de la curva que
ajusta las tres duraciones estimadas (como beta, uniforme o triangular). La
distribucin asociada con las tres estimaciones de tiempo (o estimaciones de costo)
debe ser seleccionada para que se ajusten bien a datos de soporte de actividades
similares.

3.4.5 RIESGO DEL CRONOGRAMA

El anlisis de riesgo del cronograma es utilizado para establecer y validar
contingencias del cronograma, identificar riesgos prioritarios y eventos impulsados
por el riesgo y continuamente monitorear los cambios en los riesgos asociados al
proyecto. El PERT no reconoce que las trayectorias paralelas de holgura pueden
contribuir al riesgo especialmente en puntos de convergencia. Es muy complejo
realizar un anlisis profundo de este sesgo sin realizar una simulacin como la de
Monte Carlo, la cual determinar la magnitud del sesgo. Entre ms largo y complejo
sea el proyecto, ms grande ser el impacto acumulado del riesgo del proyecto. La
circunstancias que dictan la frecuencia, rigor y uso del anlisis de riesgo del
cronograma estn documentadas en el plan de gestin del proyecto u otro documento
contractual. Para ms informacin en los conceptos de riesgo vea el Estndar Prctico
para la Gestin del Riesgo del Proyecto.

3.4.6 RESTRICCIN DE FECHAS

La restriccin de fechas restringe el flujo natural del proyecto, dejando de lado los
efectos del riesgo y limita la utilidad del anlisis de riesgo del cronograma. Las
restricciones de fechas deben evitarse cuando sea posible y usarlas nicamente
cuando sea compatible con el curso de desarrollo de un proyecto. Por ejemplo, un uso
de una restriccin de fecha puede ser para establecer una fecha no-mas-temprano-que
o no-ms-tarde-que a actividades para las cuales no existe un predecesor o sucesor
efectivo en el cronograma. Un ejemplo ilustrativo puede ser la entrega de una pieza
de equipaje por un proveedor donde no es prctico o deseable incluir las actividades
del proveedor en el cronograma modelo. Incluso en este ejemplo, debe tenerse
cuidado de no inyectar un corte en el camino crtico. Las restricciones pueden ser
flexibles (por ejemplo, tan pronto sea posible), moderadamente flexibles (por ejemplo
final no antes de) o inflexibles (por ejemplo, debe iniciar para). A las restricciones
moderadamente flexibles se les llama a veces restricciones suaves y a las
restricciones inflexibles se les llama restricciones duras. Debido a que las
restricciones limitan la flexibilidad del cronograma, deben ser usadas nicamente
cuando la lgica del cronograma no puede manejar correctamente la situacin.
Cuando sea necesaria una restriccin de fechas, se prefieren las restricciones flexibles
sobre las inflexibles.

3.4.7 ACTIVIDADES DE FINAL ABIERTO

Una actividad de final abierto es una actividad carente ya sea de predecesor o de
sucesor, o de ambos. Las actividades de final abierto pueden enturbiar las relaciones
lgicas entre las actividades del proyecto, crear una falsa apariencia de holgura en un
proyecto y reducir el impacto aparente del riesgo durante el anlisis del cronograma.
Las nicas actividades de final abierto en un proyecto deben ser los hitos de inicio y
final al inicio y al final del proyecto. A menos que est ligado a otro proyecto, el hito de
inicio de un proyecto y el hito de fin debern contender extremos abiertos.

3.4.8 LGICA DE FUERA DE SECUENCIA (OOS)

La lgica OOS aparece cuando un proyecto est en progreso. Una actividad puede ser
reportada como iniciada antes de que su predecesor sea reportado finalizado,
causando la lgica fuera de secuencia. Como ejemplo, si la actividad A tiene una
relacin fin-inicio (FS) con la actividad B, pero la actividad B ha sido actualizada con
una fecha de inicio antes de que la actividad A haya sido actualizada con una fecha de
inicio real, el resultado es lgica OOS. La lgica OOS debe ser corregida (por ejemplo,
mediante mayor descomposicin de la actividad A) o removida para preservar la
integridad del anlisis de riesgo. El anlisis del cronograma identificar propiamente
como resolver mejor los problemas lgicos de OOS; sin embargo, no se base
nicamente en la herramienta de programacin del tiempo para corregir el problema,
porque solamente el equipo del proyecto puede determinar mejor la solucin ms
lgica al OOS. En algunos casos, puede ser que la relacin definida que se cre durante
la etapa de planificacin no era correcta y debe ser corregida para este proyecto y
para futura referencia.

3.4.9 ADELANTOS Y DEMORAS

El riesgo puede consumir o extender demoras fijas con consecuencias inesperadas a la
duracin total del proyecto. Los adelantos y demoras pueden introducir riesgo al
cronograma y deben ser modelados como distintas actividades con su propia
incertidumbre de duracin cuando sea posible. Los adelantos pueden introducir
riesgo al costo especialmente en la gestin de inventario Justo-A-Tiempo (JIT); esto, a
su vez, puede tener un efecto de cascada en el cronograma modelo si el proyecto est
siendo administrado con un espacio limitado de inventario. Se requiere expresar los
adelantos/demoras como distintas actividades si el software de simulacin Monte
Carlo no permite asignacin de incertidumbre de duracin a un adelanto/demora.
Adicionalmente, el implementar un adelanto/demora a una actividad completa
permite asignarle atributos adicionales, como nombre, duracin restante, etc. La falta
de visibilidad del adelanto/demora y la distorsin del clculo de la ruta crtica
contribuyen al riesgo del cronograma. Existe un riesgo especfico asociado con
cualquier atraso y demora aplicado a las actividades donde se estn utilizando
distintos calendarios (de actividades o de recursos). Por lo tanto, es importante tener
un conocimiento claro de las consecuencias que los adelantos y demoras pueden tener
en el cronograma modelo. Muchas herramientas de software permiten definir
adelantos y demoras ya sea como una duracin fija o como un porcentaje de la
duracin de la actividad; se necesita buen juicio para utilizar el mtodo correcto que
represente la naturaleza de la actividad y del adelanto o la demora.

3.4.10 RELACIN INICIO-A-FIN

Las relaciones inicio-a-fin (SF) en ocasiones son deliberadamente usadas en
planificacin determinstica porque ellas involucran la circunstancia inusual de una
actividad sucesora sucediendo antes de su predecesor lgico. Revise cualquier
relacin inicio-a-fin (SF) para asegurar que no es el resultado de errores en el
cronograma y modifquela si fuera necesario. El siguiente ejemplo ilustrativo de una
relacin SF provee una mejor comprensin de esta excepcional relacin:
Ejemplo Suponga que el proyecto requiere la entrega de una pieza de un
equipo para dar soporte a actividades de construccin. Podra no ser prctico
proveer lgica a las actividades de fabricacin del equipo y entrega, aun as el
equipo quiere que las actividades de construccin manejen las fechas de la
entrega. Debido a que el predecesor siempre maneja el sucesor, la relacin SF
provee la solucin. Entonces la fabricacin del equipo puede concluir despus
del inicio de la actividad que requiere el equipo que se va a instalar.

3.4.11 VNCULOS DE/HACIA ACTIVIDADES DE RESUMEN

Generalmente no se recomienda usar vnculos a actividades de resumen porque la
lgica puede ser difcil de seguir y la prctica podra no estar respaldada por todas las
herramientas de programacin del tiempo. El uso de vnculos a las actividades de
resumen puede producir errores de lgica y crear lgica circular dentro del
cronograma modelo.


3.5 COMUNICACIN Y REPORTE

Las comunicaciones claras crean credibilidad con los interesados. El Director del
Proyecto junto con el equipo del proyecto crean un plan de gestin de las
comunicaciones (ver la Gua PMBOK) en etapas tempranas del ciclo de vida del
proyecto para cumplir con las expectativas identificadas de los interesados clave.
El cronograma modelo es un elemento estratgico e importante dentro de las
herramientas del Director del Proyecto para guiar un proyecto exitosamente a su
fecha de finalizacin programada. Un cronograma modelo es una lnea de tiempo o
calendario que lista actividades con fechas esperadas de inicio y de fin. Un
cronograma modelo tambin puede ser superpuesto con diferentes detalles para
posibilitar que los Directores de Proyecto direcciones y gestionen los recursos ms
fcilmente, controlen las evoluciones del proyecto da a da, se comuniquen ms
frecuentemente y efectivamente con los interesados e identifiquen y monitoreen
dependencias y restricciones entre tareas para minimizar el impacto al proyecto por
demoras prevenibles.
La versin del cronograma modelo puede producir mltiples formatos de reporte,
dependiendo del propsito del cronograma modelo, la etapa de desarrollo del
proyecto y el usuario principal del cronograma modelo. Los clientes podran requerir
varios niveles de presentaciones de las versiones del cronograma modelo. Para ms
informacin vea el componente nivel del cronograma modelo en el captulo 4.




CAPTULO 4. COMPONENTES DEL CRONOGRAMA

La siguiente seccin provee un catlogo detallado de los componentes potenciales de
una herramienta de calendarizacin. Cada entrada incluye ocho posibles tipos de
informacin relacionada con cada componente e indica si el componente se considera
que sea requerido, condicional u opcional por este estndar prctico. Los
componentes requeridos estn divididos en cuatro grupos: Componentes Clave
Requeridos (CRC, mostrados como R en las tablas), Componentes Requeridos de
Recursos (RRC), Componentes Requeridos de Gestin del Valor Ganado, EVM (ERC) y
Componentes Requeridos de Riesgo (KRC). Los requerimientos del proyecto
determinan qu componentes requeridos necesitan estar presentes en el cronograma
modelo antes de que se pueda realizar una valoracin de madurez. La valoracin de
madurez y el ndice de conformidad se explican con detalle en el captulo 5. Este
captulo est dividido en las siguientes secciones:
4.1 Cmo Usar La Lista de Componentes: esta seccin define el tipo de informacin
que puede ser mostrada para cada componente.
4.2 Lista de Componentes por Categora: esta seccin describe una descomposicin
de los componentes de una categora especfica. Esta informacin va a facilitar la
localizacin de un componente especfico. Cada componente est identificado como
requerido, condicional u opcional.
4.3 Lista Detallada de Componentes: esta seccin lista cada componente del
cronograma y sus tipos de informacin asociados en orden alfabtico.

4.1 CMO USAR LA LISTA DE COMPONENTES

A continuacin se muestra la disposicin de una entrada tpica de componente. Las
subsecciones de 4.1 definen el contenido para cada elemento de informacin dentro
de cada componente.
Nombre del Componente / Requerido, Uso Condicional u Opcional / Manual o
Calculado
Formato de Datos:
Comportamiento:
Buenas Prcticas:
Nota Condicional / Componente Asociado:
Definicin:

4.1.1 NOMBRE DEL COMPONENTE

Este elemento de informacin contiene el nombre del componente dentro de la
herramienta del cronograma, el cual puede diferir dentro de una herramienta
seleccionada. Los otros atributos deben ser los mismos para que la familiaridad con el
estndar permita su uso correcto.

4.1.2 USO REQUERIDO, CONDICIONAL U OPCIONAL

Este elemento de informacin indica si el uso de un componente es: requerido, para
cualquier cronograma modelo; condicionalmente requerido, basado en el estado o
accin de otro componente o un proceso; u opcional.

4.1.3 MANUAL O CALCULADO

Este elemento de informacin describe cmo se configura la informacin dentro del
componente como parte de la herramienta de cronograma. El formato de datos puede
variar dependiendo de la herramienta.

4.1.4 FORMATO DE LA INFORMACIN

Este elemento de informacin describe cmo es configurada la informacin dentro del
componente como parte de la herramienta de cronograma. El formato de informacin
puede variar de una herramienta de cronograma a otra.


4.1.5 COMPORTAMIENTO

En la lista de componentes, este elemento de informacin describe cmo reacciona el
componente y/o permite la reaccin dentro de la herramienta de cronograma. Es
importante notar que todas las descripciones de comportamiento comienzan con un
verbo indicando la accin. El comportamiento actual de un componente puede variar
entre herramientas de cronograma o configuraciones dentro de la misma
herramienta.

4.1.6 BUENAS PRCTICAS

En esta lista, buenas prcticas significa que existe acuerdo general que la correcta
aplicacin de habilidades, herramientas y tcnicas cuando se aplican en conjuncin
con el componente, pueden mejorar las posibilidades de xito sobre un amplio rango
de proyectos diferentes. Buena prctica no significa que el conocimiento descrito deba
siempre ser aplicado uniformemente en todos los proyectos. El equipo del proyecto es
responsable de determinar qu es lo apropiado para un proyecto dado.

4.1.7 NOTA CONDICIONAL / COMPONENTE ASOCIADO

Este elemento de informacin indica si esta accin del componente es dependiente del
estado o accin de otro componente.

4.1.8 DEFINICIN

Este elemento de informacin describe el uso general y funcin del componente
dentro de la herramienta de calendarizacin. La definicin provista es la misma que la
provista en el Glosario, donde aplique.



4.2 LISTA DE COMPONENTES POR CATEGORA

Esta seccin contiene una lista de componentes organizada por categoras. La
columna Uso identifica si un componente es requerido medular (R), componente
requerido de recurso (RRC), componente requerido de gestin del Valor Agregado
(ERC), componente requerido de riesgos (KRC), opcional (O) o no clasificado (NS).
Todos los componentes requeridos deben estar presentes para lograr una puntuacin
en el proceso de valoracin de la madurez descrito con gran detalle en el captulo 5.


























4.3 LISTA DE COMPONENTES DETALLADA

Esta seccin identifica individualmente los componentes y los ocho tipos de
informacin definida para cada componente. Est organizada alfabticamente.


























































































CAPTULO 5. NDICE DE CONFORMIDAD

Este captulo est diseado para proveer una visin general del proceso de ndice de
Conformidad. Este captulo est dividido en las siguientes secciones:
5.1 Visin general de conformidad
5.1.1 Categoras de componentes
5.1.2 Utilizacin de componentes
5.1.3 Valoracin de conformidad
5.2 Proceso de Valoracin de Conformidad
Cada seccin provee dilogo adicional en el contenido y terminologa de este estndar
prctico.

5.1 VISTAZO GENERAL DE CONFORMIDAD

El ndice de Conformidad provee un medio para evaluar qu tan bien un modelo de
cronograma especfico incorpora los lineamientos, definiciones, funcionamientos y
buenas prcticas para los componentes que se definieron en este estndar prctico de
calendarizacin (captulo 4). A pesar de que algunos Directores de Proyectos suelen
elegir no incluir algunos de estos componentes bsicos requeridos (CRC), al hacer eso,
el cronograma modelo resultante no est en conformidad con este estndar prctico y
podra no ser admisible. La premisa bsica es que a medida que crece el ndice de
Conformidad, tambin lo hace la aplicacin correcta de los componentes del
cronograma modelo y la posibilidad de que el cronograma modelo desarrollado
represente un plan atinado. El ndice tambin fue construido para reflejar donde
estn las debilidades del cronograma modelo desarrollado y las reas que ms
necesitan mejora. Se definen conceptos de calendarizacin, funcionamientos,
atributos y buenas prcticas para todos los componentes del cronograma modelo. La
conformidad del cronograma modelo es estimada evaluando la existencia de la
correcta utilizacin de varios componentes definidos en este estndar prctico de
acuerdo a las buenas prcticas.


5.1.1 CATEGORAS DE COMPONENTES

La lista de componentes en el captulo 4 identifica aquellos componentes que son:
requeridos en un cronograma modelo;
opcionales que pueden estar presentes pero no son requeridos;
sin puntuacin (NS) que son componentes opcionales que pueden estar
presentes en un cronograma modelo pero que no puntan en el ndice de
Conformidad.
Los componentes medulares requeridos pueden ser definidos en cuatro diferentes
grupos, como se lista abajo:
los componentes medulares son requeridos sin importar la complejidad del
proyecto y son conocidos como los componentes medulares requeridos (CRC);
los componentes requeridos de recursos (RRC) son requeridos si los
documentos del proyecto requieren la carga de recursos;
los componentes de la gestin del valor ganado (ERC) son requeridos si los
documentos del proyecto requieren Gestin del Valor Ganado (EVM) a ser
utilizada en el proyecto;
los componentes requeridos de riesgo (KRC) son requeridos si los
documentos del proyecto requieren conceptos sobre riesgo a ser considerados
durante el desarrollo y mantenimiento del cronograma.

5.1.2 UTILIZACIN DE COMPONENTES DEL CRONOGRAMA

El uso de componentes del cronograma en un cronograma modelo dado es
frecuentemente dado por el tamao del proyecto, la complejidad del proyecto o la
experiencia del programador del tiempo o equipo del proyecto. Los componentes
medulares (CRC) siempre son requeridos en cualquier cronograma, sin importar los
requerimientos definidos del proyecto con el fin de estar en conformidad con este
estndar prctico. Los dems tipos de componentes requeridos son aplicados para un
proyecto especfico, dependiendo de los requisitos de ese proyecto. Esos requisitos
son definidos por varios documentos del proyecto y estn contenidos normalmente
dentro de los activos de la organizacin, el lenguaje del contrato del proyecto o el plan
de manejo del cronograma modelo del proyecto, pero tambin puede ser cualquier
otro documento escrito.

Los componentes RRC, ERC y KRC estn basados condicionalmente en los requisitos
del proyecto. Por ejemplo, si el proyecto requiere que los recursos se carguen en el
proyecto y no existen otros requisitos para EVM o gestin del riesgo, entonces los
requisitos sern CRC + RRC. De igual manera, cada rea requerida ser aadida a los
CRC cuando sean requeridos por el proyecto. Si se requieren recursos, riesgo y EVM,
entonces los componentes requeridos sern CRC + RRC + ERC +KRC. A medida que
crece la complejidad del proyecto, tambin lo hace el nmero de componentes
requeridos.
Los componentes requeridos necesitan ser completamente utilizados con el fin de
lograr un nivel mnimo aceptable de conformidad. Si los documentos del proyecto no
proveen requisitos para el cronograma, entonces solo se necesitan los componentes
CRC y los RRC, ETC y KRC sern opcionales para el proyecto. La calificacin para el
ndice de Conformidad se realiza de acuerdo al apndice D, el cual divide los
componentes en tres categoras bsicas: componentes esenciales requeridos (CRC),
componentes condicionales requeridos (RRC, ERC, KRC) y componentes opcionales.
El proceso del ndice de Conformidad provee un medio para ajustar el valor del ndice
cuando se utilizan componentes opcionales. La existencia de un componente por s
mismo no es suficiente para aadir a la puntuacin. El uso de componentes opcionales
puede sumar al ndice solo si esos componentes estn en completo acuerdo con las
recomendaciones de buenas prcticas definidas en la lista de componentes del
captulo 4. Los componentes NS pueden ser presentados en un cronograma modelo,
pero no se cuentan en el ndice de conformidad de la lista de componentes del captulo
4.

5.1.3 EVALUACIN DE LA CONFORMIDAD

El proceso de evaluacin est compuesto por dos partes: una para la aplicacin de los
componentes requeridos y una evaluacin para la aplicacin de componentes
opcionales. Estas dos partes se agregan juntas para obtener un valor total del ndice.
Los resultados de esas dos evaluaciones se suman juntas para obtener un valor del
ndice total. El proceso de evaluacin se explica con ms detalle en la seccin 5.2. El
concepto crtico es que los componentes requeridos tienen que estar presentes antes
de que se registre el ndice de Conformidad; los componentes requeridos especficos
pueden cambiar segn los requerimientos del proyecto. Los CRC deben estar siempre
presentes, sin importar la complejidad del alcance del proyecto.
Una vez que el cronograma modelo ha sido evaluado para la incorporacin de los
componentes requeridos apropiados, se pueden lograr mayores grados de
conformidad a travs de la correcta utilizacin de componentes opcionales del
cronograma que estn disponibles. Los componentes opcionales pueden ser tomados
en cuenta si ellos se adhieren propia y completamente a las definiciones, propiedades
y buenas prcticas definidas en el captulo 4. Los componentes opcionales deben ser
usados nicamente para apoyar las necesidades de un proyecto especfico, nunca para
incrementar el valor del ndice nicamente. Como regla general, el uso de
componentes opcionales se esperara encontrar en organizaciones ms sofisticadas o
modelos de cronograma ms complejos. Los modelos de cronograma que no utilizan
completamente todos los componentes requeridos y sus conceptos son considerados
de naturaleza para el desarrollo. Los cronogramas modelos para el desarrollo podran
tambin ser evaluados con un valor del ndice de conformidad pero etiquetado como
no cumple estndares mnimos de conformidad.
La evaluacin de conformidad del cronograma modelo est diseada para apoyar una
evaluacin manual. Cuando un componente est presente en el cronograma modelo y
se utiliza propiamente, se gana un punto. La razn del nmero total de puntos
(requeridos ms opcionales) ganados en relacin al nmero total de puntos que
pudieron ser obtenidos representa el valor de conformidad y es expresado como un
porcentaje de 0 a 100. La excepcin a la regla involucra los componentes
requeridos. Como se dijo anteriormente, si los componentes requeridos, como
se definieron mediante los requisitos del proyecto, no son utilizados
completamente (100% empleados), entonces el cronograma modelo no cumple
conformidad mnima con este estndar prctico. Si se alcanza el nivel mnimo,
entonces el valor de la razn es representada en una escala continua o mvil, siendo
35 el ms bajo y 100 el ms alto (ve la tabla 5-1). El valor ms bajo representa la
relacin que resultara de nicamente los requisitos requeridos (CCR), todos los
cuales son necesarios en todo cronograma modelo.
Requerido Condicional Opcional
Total
Disponible
CRC RRC ERC KRC Opcional
36 11 9 7 40 103
Tabla 5-1 Nmero de componentes por categora
Si el evaluador determina que los estndares de conformidad mnima todava no se
han alcanzado, el evaluador puede terminar el proceso de evaluacin o continuar la
evaluacin con propsitos de necesidades de desarrollo y para ayudar a la
organizacin a identificar reas especficas que requieren mejoras. En este caso, sin
importar el nmero de puntos ganados, el valor de la evaluacin del cronograma
modelo no ser registrado ya que no cumple los estndares mnimos de conformidad.

5.2 PROCESO DE EVALUACIN DE LA CONFORMIDAD

El apndice D contiene una lista de componentes del cronograma organizados en
componentes medulares requeridos (CRC), componentes condicionales requeridos
(RRC, ERC, KRC) y componentes opcionales. La tabla 5-1 indica el nmero mximo de
componentes por categora as como el nmero mximo de componentes calificables.
Los componentes NS no se incluyen en esta tabla ya que el nmero de componentes
disponible no es igual al nmero de componentes definido en el captulo 4. Al utilizar
la lista del apndice D, el evaluador determinar si cada componente requerido est
presente en el cronograma modelo que se est analizando. El programador del tiempo
debe entender totalmente las buenas prcticas asociadas con los diversos
componentes requeridos y opcionales.
Para empezar con el proceso de evaluacin, el evaluador deber primero encontrar la
respuesta a las siguientes preguntas:
Existe una exigencia para la carga de recursos?
Existe una exigencia para utilizar EVM?
Existe una exigencia para utilizar gestin de riesgo del cronograma?
Si la respuesta a cualquiera de esas preguntas es s, entonces los componentes
requeridos del cronograma para ese grupo sern requeridos adems de os
CRC. Los CRC, entonces, estarn presentes en cualquier cronograma modelo.
Ejemplos de cmo los requisitos condicionales pueden afectar el nivel son:
o Si se requiere la carga de recursos, se necesita el RRC y el nivel mnimo
de componentes es CRC + RRC.
o Si se requiere EVM, se requiere ERC y el nivel mnimo del componentes
requeridos es CRC + ERC.
o Si se requiere valoracin del riesgo, se necesita el KRC y el nivel mnimo
de componentes requeridos es CRC + KRC.
o Si se requiere la carga de recursos y EVM, el nivel mnimo de
componentes requeridos es CRC + RRC + ERC.
o Si se requiere, la carga de recursos, manejo de riesgos y EVM, el nivel
mnimo de componentes requeridos es CRC + KRC + RRC + ERC.
Dependiendo de los requisitos del proyecto, el valor que puede ser alcanzado por la
total conformidad con los componentes requeridos puede variar entre CRC y CRC ms
la suma de los componentes adicionales requeridos por RRC / ERC / KRC. Este valor
abarca la primera parte del proceso de evaluacin llamada valor de los componentes
requeridos.
La parte restante del puntaje de la evaluacin es alcanzada por todos los componentes
opcionales disponibles. Por ejemplo, si los componentes KRC no se requirieran,
entonces todos los componentes del riesgo se consideraran opcionales. Una vez que
los componentes requeridos con contabilizados, todos los componentes restantes son
representados como componentes opcionales. El evaluador va a revisar los
componentes adicionales restantes y, si estn presentes y se utilizaron
adecuadamente, va a otorgar los puntos como se indic.
Cada componente opcional tiene un valor de uno. El evaluador determina una
calificacin bruta sumando todos los puntos obtenidos de los componentes
requeridos y los componentes opcionales. Si todos los puntos correspondientes al
valor de componentes requeridos no son asignados, entonces la calificacin final
bruta no puede ser registrada, no obstante la calificacin bruta puede ser compartida
con el proyecto para que comprendan las reas que deben mejorar. Finalmente la
calificacin bruta es dividida por el puntaje mximo posible para obtener el ndice de
Conformidad. El valor resultante es expresado como un porcentaje y representa el
ndice de Conformidad para el cronograma modelo.
El objetivo bsico de evaluar la conformidad del cronograma modelo con este
estndar prctico y su madurez asociada ha sido cumplido a cabalidad y el evaluador
ha determinado en qu punto de la escala de calificacin ha cado el cronograma
modelo. El programador del tiempo puede determinar acciones especficas para
moverse ms all en la escala de calificacin. Un valor mayor del ndice de
Conformidad no implica automticamente un mejor cronograma modelo, no obstante
eso podra indicar una mayor posibilidad de lograr los objetivos del proyecto.
El apndice E contiene una hoja de evaluacin en blanco y algunos ejemplos.