PRACTICE STANDARD FOR SCHEDULING (SEGUNDA EDICIÓN) – PMI 2011 Este estándar fue desarrollado como un complemento del PMBOK en el Área del Conocimiento de Gestión del Tiempo del Proyecto. Describe los métodos relacionados con programación del tiempo que se reconocen generalmente como buenas prácticas para la mayoría de los proyectos, la mayoría del tiempo. “Buena Práctica” significa que existe un acuerdo general que la aplicación correcta de estas habilidades, herramientas y técnicas puede mejorar las posibilidades de éxito en un amplio rango de proyectos. “Buena Práctica” 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 más apropiado para un proyecto en particular. Este estándar práctico clarificó la distinción entre el cronograma del proyecto y el modelo de programación del tiempo. Primero se selecciona un método de programación del tiempo seguido de la selección de una herramienta de programación del tiempo. Luego, se ingresa información específica del proyecto a la herramienta para producir el modelo de programación del tiempo. A partir de aquí, se generan varias versiones del modelo de programación del tiempo para uso como plataformas de casos eventuales, objetivos y para aprobación formal como línea de base. Luego se producen varias presentaciones para una amplia variedad de usos.
CAPÍTULO 1. INTRODUCCIÓN Este capítulo está diseñado para proveer una visión general del contenido de este estándar. Este capítulo está dividido en las siguientes secciones: 1.1 Programación del Tiempo del Proyecto 1.2 ¿Por qué programar el tiempo? 1.3 Visión General 1.4 Propósito 1.5 Aplicabilidad
Cada sección provee información adicional del contenido y terminología usada en este estándar.
1.1 PROGRAMACIÓN DEL TIEMPO DEL PROYECTO La programación del proyecto es la aplicación de habilidades, técnicas e intuición adquirida a través del conocimiento y experiencia para desarrollar modelos efectivos de programación del tiempo. El modelo de programación del tiempo integra y organiza localmente varios componentes del proyecto, como actividades, recursos y relaciones lógicas, para mejorar la posibilidad de que el proyecto se complete satisfactoriamente dentro de la duración de base. Definición de términos: Modelo de Programación del Tiempo: es una representación dinámica del plan para la ejecución de las actividades del proyecto desarrollado por los interesados del proyecto, aplicando un método de programación del tiempo seleccionado a una herramienta de programación del tiempo usando información específica del proyecto. El modelo de programación del tiempo puede ser procesado por una herramienta de programación para producir varias versiones de modelos de programación del tiempo. Versión del Modelo de Programación del Tiempo: es una copia del modelo de programación del tiempo, que has sido procesada por una herramienta de programación del tiempo y ha reaccionado a entradas y ajustes hechos a los datos de un proyecto específico dentro de la herramienta de programación del tiempo (ciclo de actualización completo), que es guardada como registro y referencia, como una versión correspondiente a una fecha, modelos de programación específicos y el modelo de programación de base. Las versiones producen varias presentaciones de la programación del tiempo como rutas críticas, perfiles de recursos, asignación de actividades, registro de logros, etc., y pueden proveer pronósticos basados en tiempo del ciclo de vida del proyecto. Cuando se utilizan juntas, las versiones apoyan el análisis, por ejemplo de varianza. Presentación: es una salida de la versión del modelo de programación del tiempo, utilizada para comunicar datos específicos del proyecto para reporte, análisis y toma de decisiones.
1.2 ¿POR QUÉ PROGRAMAR EL TIEMPO? Los proyectos generalmente son cometidos complejos, sin embargo un modelo detallado de programación del tiempo puede resultar en una descomposición del proyecto en fases o grupos más manejables. El desempeño 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 ejecución de un proyecto usualmente no prosigue exactamente como fue inicialmente planificado y según la línea de base. En un ambiente de proyecto típico, debido a una planificación inadecuada o cambios significativos al proyecto, se vuelve necesario refinar el modelo de programación del tiempo. Esta evolución iterativa es requerida para predecir, reconocer y lograr esos factores en desarrollo y situaciones problemáticas que van a afectar potencialmente el desempeño de un proyecto. La clave para el éxito del proyecto es aplicar el conocimiento y la experiencia en crear un plan de gestión del proyecto y luego dedicarse a ejecutar el proyecto de acuerdo al plan. La programación del tiempo es uno de los requisitos básicos de la planificación y análisis en la gestión de proyectos. La programación del tiempo provee un plan detallado que representa cómo y cuándo se producirán los productos, servicios y resultados del proyecto definidos en el alcance del proyecto y puede servir como un instrumento para la comunicación, gestión de expectativas de los interesados y una base para el reporte del desempeño. La naturaleza dinámica de la ejecución 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 programación del tiempo apoya al proyecto, permitiendo:
Distribución de actividades requeridas en el tiempo Movilización de recursos de una manera más eficiente Coordinación de eventos dentro del proyecto y con otros proyectos Detección temprana de riesgos y problemas Implementación de acciones para completar los objetivos del proyecto tal y como se planearon. Permite el análisis de escenarios Planificación de recursos Pronósticos de estimación a finalización
1.3 VISIÓN GENERAL Este estándar para la programación del tiempo describe los componentes del modelo de programación del tiempo (capítulo 4) y las buenas prácticas generalmente reconocidas son aplicables a la mayoría de proyectos, la mayoría del tiempo; existe consenso sobre su valor y utilidad. “Buena Práctica” significa que existe acuerdo general que la aplicación de estas habilidades, herramientas y técnicas puede mejorar la probabilidad de éxito dentro de un amplio rango de proyectos. “Buena Práctica” 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 prácticos en un modelo de programación 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 selección del método de programación del tiempo y la herramienta de programación del tiempo que apoyará el método de programación del tiempo deseado, seguido de la incorporación de datos específicos del proyecto a la herramienta y luego crear un único modelo de programación del tiempo. El resultado es una versión del modelo de programación del tiempo usada para generar varias presentaciones y reportes. La figura 1-1 muestra un mejor entendimiento de las interrelaciones de los conceptos de creación y terminología del modelo de programación del tiempo. Este proceso resulta en un modelo de programación del tiempo para la ejecución, monitoreo y control del proyecto, que va a responder predeciblemente al avance y a los cambios. El modelo de programación del tiempo es actualizado regularmente para reflejar el avance y los cambios en el alcance, duraciones, hitos, recursos asignados, eficiencias, metodología de trabajo o lógica de programación. Este Estándar Práctico para Programación del Tiempo también provee un proceso de valoración que puede ser usado para determinar qué tan bien el modelo de programación del tiempo se alinea a este estándar. Un índice de conformidad (vea el capítulo 5 de este estándar práctico) se desarrolló para determinar cuáles componentes son usados y cómo son usados dentro del modelo de programación del tiempo. Para obtener una evaluación aceptable del ajuste, un modelo de programación del tiempo, como mínimo, debe contener todos los componentes requeridos que se describen el en Capítulo 4 y en el Apéndice D. La selección de la herramienta de software apropiada para la programación del tiempo provee acceso a los componentes requeridos necesarios para desarrollar el modelo de programación del tiempo. El uso de este estándar junto con la experiencia, la habilidad y la madurez organizacional va a guiar la aplicación de los componentes.
La inclusión de un componente en este estándar práctico no tiene necesariamente relación con la complejidad o el tamaño de los problemas del proyecto. Este estándar práctico supone que todos los modelos de programación del tiempo necesitan tener los componentes requeridos, comportamientos básicos y buenas prácticas; el tamaño y la complejidad del proyecto solo dan lugar a cambios en la escala y repetición de los componentes requeridos. La Guía de Conocimiento para la Gestión del Proyecto (PMBOK) provee los procesos para alcanzar los factores que tienen que ver con el tamaño y la complejidad del proyecto. En adición, la definición de “generalmente reconocido” también supone que no existen diferencias significativas para el uso de los componentes requeridos en las prácticas de programación del tiempo de diversas industrias.
1.4 PROPÓSITO El propósito de Estándar Práctico para la Programación del Tiempo es proveer lineamientos de uso efectivo en la gestión del tiempo de un proyecto, proveyendo conocimiento en la creación de modelos de programación del tiempo. Este estándar práctico amplía la información contenida en el Capítulo 6 (sección de Gestión del Tiempo) de la Guía PMBOK. Más aún, 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 estándar práctico. Al hacer eso, este estándar práctico establece un núcleo de componentes esenciales para ser utilizados en el establecimiento de un modelo de programación del tiempo que alcance un grado mínimo aceptable de conformidad con este estándar práctico y un método para que el modelo de programación del tiempo alcance conformidad con este estándar. Los componentes requeridos para cada modelo de programación del tiempo deben ser descritos en el modelo de programación del tiempo del proyecto del plan de gestión (vea la sección 3.1). El propósito final de este estándar práctico es crear modelos de programación del tiempo que sean de valor creciente para los proyectos que ellos representan. No es el propósito de este estándar práctico proveer una guía integral de cómo desarrollar un modelo de programación del tiempo. Para una instrucción en cómo desarrollar un modelo de programación del tiempo, refiérase a cursos y libros de texto sobre el particular.
1.5 APLICABILIDAD Este estándar práctico se dirige a directores de proyectos que tengan conocimientos básicos en programación del tiempo de los proyectos. Para los propósitos de este estándar práctico, estos individuos se conocerán como programadores.
Se supone que el lector tiene un conocimiento básico de Gestión de Proyectos, de las Áreas del Conocimiento como las define la Guía PMBOK, que el proyecto tiene una Estructura de Desglose del Trabajo (EDT / WBS) que es conforme con el Estándar Práctico para Estructuras de Desglose del Trabajo y que se ha planificado apropiadamente. A medida que el desarrollo del cronograma avance, algunos estándares prácticos relacionados como el Estándar Práctico para la Gestión del Valor Ganado podrían ser aplicables.
Más aún, una organización que abrace los principios y buenas prácticas trazadas en este estándar y los aplique globalmente a través de la organización, asegurará que todos los modelos de programación del tiempo desarrollados para los proyectos de la organización sean hechos de una manera consistente para toda la organización.
CAPÍTULO 2. PRINCIPIOS Y CONCEPTOS MODELO DE PROGRAMACIÓN DEL TIEMPO
DEL
Este capítulo está diseñado para proveer guía e información en los principios y conceptos asociados con la creación del modelo de programación del tiempo y su uso. Este capítulo está dividido en las siguientes secciones: 2.1 Visión General 2.2. Métodos de programación del tiempo 2.3 Técnicas de Programación del tiempo
2.4 La herramienta de programación del tiempo 2.5 El modelo de programación del tiempo 2.6 Las versiones del modelo de programación del tiempo y las Presentaciones. Cada sección provee requisitos adicionales, terminología y funcionalidad relacionada con estos tópicos. Estas secciones ligan los procesos descritos en este capítulo a las buenas prácticas descritas en el capítulo 3 y los componentes de programación del tiempo del capítulo 4.
2.1 VISIÓN GENERAL Los principios y conceptos del modelo de programación del tiempo están descritos en la figura 2-1. El plan de manejo del modelo de programación del tiempo identifica el método de programación del tiempo y la herramienta de programación del tiempo utilizada para crear dicho modelo. El proceso Crear Cronograma incorpora todos los procesos definidos que tienen que ver con el esfuerzo de programación del tiempo del proyecto (Inicio, Planificación, Ejecución, Monitoreo y Control y Cierre). Dentro de este proceso de modelación, 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 (según el PMBOK). El modelo de programación del tiempo puede generar diversas versiones del cronograma, las cuales producen presentaciones (ver figura 2-1). Las versiones del cronograma pueden incluir, la línea de base aprobada, objetivos seleccionados y modelos condicionados (“si-entonces”). El proceso Crear Cronograma tiene como resultado un modelo de programación del tiempo aprobado utilizado en los Grupos de Proceso de Ejecución y Monitoreo y Control (PMBOK), el cual reacciona predeciblemente y lógicamente al progreso y a los cambios del proyecto. Una vez creado y aprobado (cuando se establece la línea base), el modelo de programación del tiempo se actualiza, de acuerdo a las necesidades de desempeño del proyecto y en apoyo a los intervalos regulares de reportes del proyecto, para reflejar progreso y cambios. Durante la planificación del proyecto se inicia un proceso para crear el modelo de programación del tiempo que satisfaga las necesidades del proyecto y sus interesados.
Muchos de los términos y conceptos discutidos en este apartado se explican con mayor detalle en el capítulo 3 de este estándar. 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 específico y aclarando adjetivos cuando sea necesario. Las Actividades son secuenciadas mediante relaciones lógicas. La cantidad, nivel de destreza y capacidades y habilidades de los recursos requeridos para completar cada actividad deben ser considerados, además se consultará a quienes ejecutarán las actividades para determinar la duración de cada actividad. No se deben usar restricciones ni factores de adelanto/retraso de tiempo en el modelo de programación del tiempo para reemplazar la lógica del cronograma. La creación del modelo provee una línea de base que permite la comparación 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 MÉTODOS DE PROGRAMACIÓN DEL TIEMPO El método de programación del tiempo provee el marco para la creación del modelo de programación del tiempo. El método más común de programación del tiempo, sustentado por la mayoría de las herramientas de programación del tiempo, es el método de diagrama de precedencia (MDP). Con el uso común y persuasivo, se le llama usualmente el Método de la Ruta Crítica (CPM). Otro método popular es la Cadena Crítica, el cual es basado en el CPM. Dentro de estos métodos existen varias técnicas como Planificación Gradual (Rolling Wave), PERT, Monte Carlo, programación maestra integrada y ágil. El primer paso en el proceso Crear el Cronograma es la selección de un método y una técnica apropiados. Algunas organizaciones estandarizan una herramienta específica de software. En este caso, el método de programación del tiempo ya está decidido y está inherente en la herramienta. Debido a que es el método más usado, este estándar práctico se enfoca en el CPM.
2.2.1 MÉTODO DE LA RUTA CRÍTICA (CPM) El método de la ruta crítica (CPM) determina la duración mínima total del proyecto y la fecha estimada más temprana posible para finalizar el proyecto, así como la posible flexibilidad ( holgura total) en el modelo de programación del tiempo. Para aplicar el CPM, se desarrolla un cronograma modelo, el cual abarca las actividades del proyecto. Se calculan las fechas más tempranas de inicio y finalización para cada actividad mediante un “paso adelante” desde una fecha específica del proyecto. Las fechas más tardías de inicio y finalización se determinan para cada actividad mediante “paso
atrás”, empezando de la fecha más temprana de finalización determinada durante el “paso adelante” o desde una fecha de finalización específica (restricción). Un principio básico 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 características de las aplicaciones modernas de programación del tiempo, incluyendo recursos, calendarios del proyecto y actividades, restricciones, definiciones variables o críticas, recursos, duraciones ejecutadas, rezagos, dependencias externas, prioridades de las actividades y la asignación de fechas de inicio y finalización reales a las actividades.
En su uso común el CPM se refeire al método imperante utilizado en las herramientas modernas de programación del tiempo. En estas herramientas el método vigente es usualmente el método de diagrama de precedencias (MDP) y este estándar sigue esa convención de uso común.
2.2.2 MÉTODO DEL DIAGRAMA DE PRECEDENCIAS (MDP) El concepto original del CPM era un modelo computarizado que utilizaba un estilo de diagramación “actividad-flecha”. El método de diagrama de precedencia (MDP) fue introducido unos años luego como una “metodología no computarizada de programación del tiempo” que ofrecía una representación gráfica más limpia y fácil de seguir; bosquejaba las actividades comprendidas en un proyecto como cajas y nodos e introducía relaciones lógicas mejoradas (en adición a finalización-inicio) y el uso de adelantos y atrasos. El resultado es un diagrama de precedencia, también conocido como diagrama de red del proyecto. La metodología MDP del CPM fue rápidamente programada y las herramientas modernas de programación del tiempo colocan las actividades en nodos con flechas uniendo las actividades; los nodos de las actividades pueden contener información sobre la duración, costo recursos y restricciones. La adición de múltiples calendarios del proyecto y restricciones específicas del proyecto complican más los cálculos del CPM y el análisis de redes. Las aplicaciones computarizadas de hoy hace más fácil lidiar con estos factores durante el cálculo del modelo de programación del tiempo. El resultado final es que para la mayoría de proyectos, el camino crítico ya no es un camino de cero holguras, como era presentado en los primeros CPM. El resultado final es un diagrama de precedencia, también conocido como diagramas de red del proyecto. El MDP coloca actividades en nudos con flechas uniendo actividades; los nodos de las actividades pueden contener información sobre duración, costo, recursos y restricciones. El MDP requiere de menos nodos que el ADM (Método de Diagrama de Flechas) para describir la misma información del proyecto. Si bien la adición de múltiples calendarios y restricciones complica más los cálculos hacia adelante y hacia atrás y el análisis de redes de un diagrama MDP, las aplicaciones computarizadas de hoy completan los cálculos adicionales sin problema. En la mayoría de proyectos el camino crítico 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 finalización del proyecto. Las relaciones entre actividades escalonadas en el tiempo se representan mediante flechas direccionales. Se necesita satisfacer las relaciones lógicas. Para establecer una ruta crítica significativa, es necesario desarrollar una red de actividades lógica con duraciones empíricas para ejecución de una manera realística y práctica. Las salidas abiertas en un cronograma son aquellas actividades que no tienen una actividad predecesora y/o una sucesora, de esta forma creando un vacío en la lógica 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 aplicación de la lógica de actividades. En MDP, una actividad puede ser conectada ya sea desde su inicio o su fin. Esto permite una presentación lógica de inicio-a-fin sin necesidad de descomponer más el trabajo. Otra característica 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 MÉTODO DE LA CADENA CRÍTICA (MCC) La disponibilidad de recursos compete con la habilidad de ejecutar tareas en fechas planificadas. Como tal, muchos programas de computación permite que los recursos sean nivelados (de manera que no tengan exceso de tareas); esto puede acortar la
duración del proyecto y las fechas de inicio y finalización de las actividades. El modelo resultante de programación del tiempo, considerando la disponibilidad de recursos, se denomina comúnmente ruta crítica restringida en recursos y es el punto de inicio para la programación por cadena crítica. El método de la cadena crítica se desarrolló con base en el CPM y considera los efectos de la asignación de los recursos, nivelación de recursos e incertidumbre en la duración de las actividades en el camino crítico determinado por el CPM. Para hacer eso, el método de la cadena crítica introduce el concepto de buffer y gestión de buffer. Tres tipos de buffers son, buffers de alimentación, buffer de recursos y buffers del proyecto: Buffers de Alimentación: un buffer (en duración) añadido al modelo de programación del tiempo en la unión de caminos no-críticos con el camino crítico del CPM. Buffers de Recursos: la transición frecuente de fechas estimadas de finalización a una actividad predecesora alertando los recursos de una actividad sucesora para estar preparado para el trabajo de inicio en la fecha estimada de finalización de la actividad predecesora. Buffers del Proyecto: una duración añadida 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 estadísticamente y se agregan los márgenes de seguridad asignados a cadenas de actividades individuales. Los buffers son creados asignando tiempos agresivos de realización 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 márgenes 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 duración o los recursos). El efecto es similar a gestionar la holgura total y la holgura libre en el método CPM. Un ejemplo de una cadena crítica se muestra en la figura 2-4. El camino de recursos nivelados más largo a través del cronograma, incluyendo los buffers, es el camino crítico, y es usualmente diferente al camino crítico del CPM. Los factores definitorios en el método de la cadena crítica son las actividades buffer, los recursos que no sean multi-tarea, nivelación de recursos y gestión de buffer.
El primer paso cuando se usa el método de la cadena crítica para programación del tiempo es crear un plan de proyecto agresivo y nivelado en recursos (pero no necesariamente detallado). La fecha de finalización del proyecto está definida como en final de la cadena crítica, incluyendo los buffers para tomar en cuenta los riesgos del proyecto y las demoras. Durante la ejecución del proyecto, si las actividades consumen una duración mayor que la predicha por el método de la cadena crítica, el buffer del proyecto se va consumiendo gradualmente. De acuerdo al grado de consumo del buffer (también llamado gestión 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 duración y el presupuesto. La cadena crítica 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 atención administrativa –la cadena crítica- va a permanecer fija durante todo del proyecto. La contención de recursos es de tal magnitud en las estructuras organizativas de hoy que la duración de los proyectos es dependiente de la disponibilidad de recursos a un grado no menor que de la secuencia lógica 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 absorción del riesgo va a ser mayor en orden de magnitud.
2.3 TÉCNICAS DE PROGRAMACIÓN DEL TIEMPO Una vez que se estableció un método de programación del tiempo, un grupo de técnicas pueden ser aplicadas a un método. Algunas de las más comunes técnicas son: Planificación Gradual (rolling wave planning), programación ágil, PERT y simulación Monte Carlo.
2.3.1 PLANIFICACIÓN GRADUAL (ROLLING WAVE PLANNING). Al utilizar la técnica de planificación gradual, se realiza una descomposición detallada de las actividades de alto nivel solo para aquellas actividades en el futuro cercano, por ejemplo, los próximos 90 días. La técnica de planificación gradual supone que el equipo del proyecto tiende a poseer información exacta y detallada concerniente a las actividades de corto plazo y menos información sobre las actividades en el futuro o más allá dentro del proyecto. Un principio importante para la Planificación Gradual es realizar la planificación detallada e intervalos regulares. La planificación detallada para el siguiente intervalo necesita ser bien completada previo al inicio del siguiente ciclo de ejecución. Para periodos más allá del ciclo de ejecución detallado, las actividades se enlistan como “paquetes de planificación” con mucho menor detalle. Estas actividades de planificación pueden contener información de costo y recursos, la cual se vuelve fija en la duración y el costo base. Cuando llega la hora de la planificación detallada, se reemplazan los paquetes de planificación con detalles adicionales. La figura 2-5 ilustra un ejemplo de planificación gradual.
2.3.2 TÉCNICA ÁGIL La gestión de proyectos ágil es similar a la técnica de Planificación Gradual en el tanto enfatiza la consecución de resultados usables rápida e iterativamente. El equipo de proyecto Ágil utiliza programación CPM para cada ciclo de desarrollo, llamado sprint, el cual normalmente tarda de dos a cuatro semanas. La gestión de proyectos Ágil se enfoca en ciclos de desarrollo más 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 más importantes de una técnica Ágil incluyen múltiples iteraciones de las fases del proyecto en vez de moverse de una fase a otra. Otro ingrediente clave del método Ágil es la participación de los interesados clave, primariamente el usuario final o el cliente al final de cada iteración para aprobar los productos de trabajo intermedios.
2.3.3 TÉCNICA DE EVALUACIÓN Y REVISIÓN DEL PROGRAMA (PERT). Aunque similar en principio al CPM y MDP, la técnica de evaluación y revisión del programa (PERT) está enfocada en la duración de las actividades. PERT permite la duración aleatoria de actividades y pondera la duración estimada en actividades en el rango de estimados de duración provisto por los interesados. Se provee un mayor desarrollo de técnicas de estimación en el Estándar Práctico de Estimación del Proyecto. A partir del diagrama de precedencia, PERT permite que los estimados de duración de las actividades se determinen teniendo en cuenta el grado de incertidumbre contenido en el proceso de estimación de duración. Tres cálculos de duración son necesarios para cada actividad:
Duración optimista (la mínima duración de la actividad bajo las condiciones más favorables) Duración más probable (la duración de la actividad que ocurrirá con más frecuencia) Duración pesimista (la duración de la actividad bajo las condiciones menos favorables)
Las duraciones determinadas por la ecuación anterior son usadas en el diagrama PERT como duraciones estimadas de actividades. Generalmente las duraciones se establecen a un nivel estadístico específico de significancia (por ejemplo, un nivel de 95% de confianza). El peso en la ecuación fue una aproximación manual de la distribución estadística. Con cálculos más sofisticados, principalmente utilizando computadores, una implementación de simulaciones estadísticas o múltiples PERT (SPERT) es posible, acercándose al método y resultados del análisis de Monte Carlo.
2.3.4 SIMULACIÓN MONTE CARLO La simulación Monte Carlo considera la incertidumbre en la duración de la actividad, costos, recursos y relaciones, etc., usando los riesgos del registro de riesgos para manejar la incertidumbre en la duración de las actividades o estimando aquellas duraciones directamente como optimistas, más probables y pesimistas para las
actividades. Una distribución probabilística puede ser asignada a cada actividad, la cual considera el nivel de confianza que los interesados tienen en los estimados. Cuando existe más confianza en el estimado, una distribución probabilística con una desviación estándar menor es seleccionada, o viceversa. Después de asignar estimados y distribuciones de probabilidad, se corre la simulación Monte Carlo. La simulación está conformada por múltiples iteraciones, cada una de las cuales representa un posible resultado del proyecto. Para cada iteración el software de simulación 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 versión del cronograma modelo con atributos de ruta crítica, duración y costo. Este proceso se repite múltiples veces, resultando en una distribución probabilística para duración, costo, fechas de inicio y fechas de finalización para cada actividad seleccionada y al final para el proyecto. La figura 2-6 muestra una distribución probabilística de ejemplo para una actividad unitaria.
Un análisis posterior puede determinar la frecuencia de actividades específicas que caigan en la ruta crítica y la identidad de los riesgos más significativos para el logro de los resultados a un nivel deseado de certeza. Las actividades más frecuentes en el camino crítico 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 aplicación de la simulación Monte Carlo.
2.4 LA HERRAMIENTA DE PROGRAMACIÓN DEL TIEMPO La herramienta de programación del tiempo es usualmente un software específico que contiene componentes de programación del tiempo y las reglas para interrelacionar dichos componentes. Los componentes de programación del tiempo son fácilmente visualizados corriendo un software de programación del tiempo y observando los componentes de la herramienta que están disponibles para construir el modelo de programación del tiempo. La herramienta de programación del tiempo es la plataforma sobre la cual el modelo de programación del tiempo se ensambla y provee los medios para ajustar varios parámetros y componentes típicos en un proceso de modelación. Por ejemplo, la herramienta incluye la capacidad para:
Seleccionar el tipo de relación (como final-a-inicio o final-a-final) entre las actividades. Añadir adelantos o atrasos entre actividades. Aplicar recursos a las actividades y usar información de los recursos junto con la disponibilidad de recursos para ajustar la programación del tiempo de las actividades. Asignar prioridades a las actividades que utilizan los mismos recursos durante el mismo periodo de tiempo. Añadir restricciones a las actividades donde únicamente la lógica (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 específico de versión del cronograma como línea de base. Realizar análisis situacionales (si-entonces) dentro del modelo del cronograma para obtener diferentes fechas de finalización del proyecto. Analizar el impacto potencial que los cambios en el cronograma modelo tendrían en los objetivos del proyecto. Comparar la versión del cronograma modelo más reciente contra un modelo anterior o contra la línea de base para identificar y cuantificar varianzas y tendencias.
2.5 EL MODELO DE PROGRAMACIÓN DEL TIEMPO La introducción de datos específicos del proyecto, como las actividades, duraciones, recursos, relaciones y restricciones en la herramienta de programación del tiempo crea un modelo de cronograma para un determinado proyecto. El análisis 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 finalización del proyecto en la forma de versiones del cronograma. El cronograma modelo provee predicciones basadas en tiempo, reaccionando a entradas y ajustes hechos a través del ciclo de vida del proyecto.
2.6 LAS VERSIONES DEL CRONOGRAMA MODELO Y PRESENTACIONES La versión del cronograma modelo es usado para producir presentaciones para reportar ítems como camino crítico, perfiles de utilización de recursos, listas de actividades, listas de asignación de actividades, registros de cumplimiento, datos del sistema de gestión 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 específicos del proyecto son la base del análisis del equipo del proyecto, incluyendo los interesados (vea figura 2-7). Una presentación, en su forma más 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 también pueden identificar el recurso, ya sea por una persona específica, rol o sistema/herramienta etc., que será requerido para completar las actividades. El término “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 estándar práctico define los datos específicos del proyecto dentro de una herramienta de programación del tiempo como un cronograma modelo y las salidas resultantes, basadas en los datos específicos 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, gráficos de barras con fechas, diagramas de red lógicos con fechas, patrones de uso de recursos y costos, hitos, cronogramas maestros, listas de trabajo departamentales, listas del equipo de trabajo y fechas de presentación de entregables. Existen muchas otras presentaciones posibles. Las presentaciones del cronograma modelo pueden tomar la forma de un cronograma de inicio temprano, inicio tardío, cronograma de línea de base, cronograma limitado de recursos o cronograma objeto. Otros tipos de cronogramas son productos derivados de estos cinco tipos de cronogramas básicos. Estos productos derivados incluyen cronogramas maestros, cronogramas de hitos y cronogramas resumen. El uso de estos términos puede variar de proyecto en proyecto y de organización en organización.
CAPÍTULO 3. VISTA GENERAL DEL MODELO DE BUENAS PRÁCTICAS DE PROGRAMACIÓN DEL TIEMPO Este capítulo está diseñado para proveer una guía e información en las buenas prácticas generalmente aceptadas asociadas con los procesos de planificación, desarrollo, mantenimiento, comunicación y reporte de un modelo efectivo de programación del tiempo. Este capítulo se divide en las siguientes secciones: 3.1 Gestión del modelo de Programación del Tiempo 3.2 Creación del modelo de Programación del Tiempo 3.3 Mantenimiento del Modelo de Programación del Tiempo 3.4 Análisis del Modelo de Programación del Tiempo 3.5 Comunicación y Reporte Cada sección provee requerimientos comunes, terminología y funcionalidad asociada. Estas secciones ligan la discusión del proceso de programación del tiempo descrito en el capítulo 2 a los componentes del cronograma definidos en el capítulo 4. Este capítulo provee una visión general, con ejemplos, de cómo crear y mantener un modelo efectivo de programación del tiempo.
3.1 GESTIÓN DEL MODELO DE PROGRAMACIÓN DEL TIEMPO La gestión del modelo de programación del tiempo abarca los esfuerzos relativos a programación del tiempo del equipo de proyecto como parte del proceso Desarrollar el Plan de Gestión del Proyecto, sección 4.2 del PMBOK. El modelo de planificación del tiempo ayuda a asegurar que todos los Grupos de Proceso y Áreas de Conocimiento estén propiamente integrados dentro del modelo completo de programación del tiempo. Un modelo de programación del tiempo requiere planificación y diseño en mucho de la misma manera que cada entregable del proyecto es planificado y diseñado. El equipo de proyecto necesita considerar un número de factores para crear un modelo de programación del tiempo que puede ser una herramienta útil para el proyecto. Esta herramienta va a ser utilizada para monitorear el desempeño del proyecto, comunicar información concerniente al trabajo y comparar el trabajo
planeado con el trabajo realizado. Estos conceptos van a ser desarrollados en apoyo al Plan de Gestión de Desarrollo del Proyecto, de acuerdo al PMBOK. La gestión de la modelo de programación del tiempo se dirige a lo siguiente:
Procesos y procedimientos para la gestión de datos del modelo de programación del tiempo como formato de datos, versiones, accesibilidad, almacenamiento y recuperación de datos. Políticas relacionadas con la metodología que será utilizada en el desarrollo y mantenimiento del cronograma, tales como umbrales de desempeño, contenido y frecuencia de presentaciones y reportes, implementación e integración de la gestión del valor ganado (EVM), compatibilidad con otros planes del proyecto, seguimiento de riesgos y descomposición de tareas. Cuando se determina la descomposición de tareas, demasiado detalle produce un modelo confuso y demasiado grande que es difícil y caro de gestionar; muy poco detalle significa que existe información insuficiente para el control del proyecto en curso. Consideraciones de obligaciones contractuales y obligaciones financieras potenciales (reclamos, mediación, arbitraje, litigio, etc.). Procesos y procedimientos para planificar, actualizar y mantener el cronograma modelo durante el ciclo de vida del proyecto; determinación 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 información de la última actualización sea publicada, analizada y que el equipo del proyecto actúe de acuerdo a los hechos antes de la siguiente actualización. El ciclo de actualización debe ser de conformidad con el contrato o los activos de proceso organizacionales. Requerimientos de capacitación para los miembros del equipo del proyecto tales como entendimiento de las políticas de programación del tiempo, procedimientos y tecnologías de software, por ejemplo, reporte del progreso, capturar los riesgos del proyecto y reflejar actividades de mitigación en el modelo de programación del tiempo.
3.1.1 PLAN DE GESTIÓN DE LOS DATOS DEL CRONOGRAMA Previo a añadir información al cronograma modelo, el equipo de proyecto se debe enfocar en el correcto diseño del cronograma modelo. El equipo de proyecto necesita definir algunas entradas básicas al cronograma modelo y salidas esperadas para
asegurarse que se está colocando la mínima infraestructura necesaria para satisfacer los requerimientos de los involucrados. Además, el alcance, la estructura de desglose del trabajo (EDT), definición 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 mínimo, el equipo del proyecto debe considerar lo siguiente cuando se desarrolle el plan de gestión 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 tendrán mayor acceso al cronograma y van a ser responsables de funciones administrativas. Determinar la frecuencia (diaria, semanal o mensual) de respaldo de la información del cronograma. Los respaldos son parte importante de la gestión de la configuración del cronograma. Las frecuencias requeridas de respaldo se establecen frecuentemente de acuerdo a las expectativas de los interesados. Determinar cómo se van a recuperar las versiones anteriores del cronograma, a qué intervalos y verificar que los procedimientos para recuperación de datos sean exactos. Un error común es realizar los respaldos pero no establecer un procedimiento de recuperación. Determinar los requisitos de retención de datos del cronograma. Identificar los riesgos asociados con el desarrollo del cronograma modelo relacionados con la gestión de la información. Determinar los requisitos de jerarquía de información para propósitos de reportes (como se definió en el Plan de Comunicación) y cómo estos requisitos van a impactar el proceso de gestión de datos del cronograma y el modelo de datos. Por ejemplo, los tipos de actividades mostrados al comité de dirección son diferentes a los que se muestran al Director del Proyecto.
3.1.2 PLAN DE GESTIÓN DEL CRONOGRAMA MODELO El plan de gestión del cronograma modelo es una colección de procesos, métodos, plantillas y herramientas para lograr los objetivos del cronograma del proyecto. Las buenas prácticas establecen que todos los cronogramas modelos deben estar guiados por una metodología que provea una lista de chequeo de requisitos para el cronograma modelo que asegure su calidad.
El Plan de Gestión del Cronograma Modelo permite a los miembros del equipo de trabajo desempeñarse 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 Gestión del Cronograma Modelo incluye lo siguiente:
.1 Selección del Método de Programación del Tiempo El equipo de proyecto, con el programador del tiempo como facilitador, debe tener acceso a la documentación sobre los métodos disponibles de programación del tiempo aprobados por la organización con el fin de acatar los requerimientos de la organización. Basados en esta información, el programador del tiempo implementa el método de programación del tiempo como fue determinado por el equipo del proyecto.
.2 Selección de la Herramienta de Programación del Tiempo La selección de la herramienta de programación del tiempo estará basada en el método de programación del tiempo seleccionado y se ajustará a los requerimientos del proyecto y la organización relacionados con la herramienta.
.3 Plan de Creación del Modelo de Programación del Tiempo El Director del Proyecto, en conjunto con el equipo del proyecto y los interesados clave, determinan el plan para la creación del modelo de Programación del Tiempo. Las consideraciones clave incluyen: planificación gradual y participación de los interesados en el proceso Desarrollar el Cronograma, de acuerdo al PMBOK.
.4 ID del Modelo de Programación del Tiempo Cada cronograma modelo necesita tener un único método de identificación específico para el proyecto.
.5 Versión del Cronograma Modelo Cada versión del cronograma modelo tiene un único identificador de versión. La localización de esta identificación puede variar, dependiendo de los activos del proceso y las herramientas usadas para controlarlo. Un único identificador de la versión del cronograma modelo es esencial para permitir el archivo correcto de los documentos del proyecto en los procesos de auditoría. El plan de gestión del cronograma modelo proveerá el formato para este componente de manera que no ocurran nombres redundantes.
.6 Calendarios y períodos de trabajo Un calendario del proyecto estándar es definido utilizando periodos de trabajo. Los períodos de trabajo pueden también ser definidos para actividades específicas o porciones de un proyecto, incluyendo recursos. Algunos elementos del calendario incluyen:
Definir los días laborables de la semana Definir el número de turnos a ser trabajados cada día Definir el número de horas a ser trabajadas cada turno o día. 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 determinación del número y la estructura de los calendarios requeridos para la programación del tiempo. El uso de múltiples calendarios introduce una complejidad significativa al cálculo de holguras y ruta crítica. Sin embargo, mientras la programación se simplifica con el uso de un solo calendario, un calendario podría ser inadecuado para gestionar el proyecto (por ejemplo un equipo de proyecto internacional con feriados locales). La práctica generalmente aceptada es usar un calendario estándar 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 estándar para las actividades del proyecto. Esta práctica permite al equipo de trabajo establecer y programar diferentes periodos o calendarios de trabajo, si se requiere, para ciertas actividades.
.7 Ciclo de Actualización del Proyecto El ciclo de actualización 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 actualización y la frecuencia con la que el estado será informado. El ciclo de actualización refleja cómo la gestión se propone utilizar los datos generados a partir del modelo de programación del tiempo, incluyendo la distribución de las reuniones de revisión, requisitos de informes de gestión y ciclos de pago que a menudo están vinculados a las actualizaciones. Seleccione un ciclo de actualización de gestión con un nivel óptimo de información de control sin ser excesivamente agobiante para la gente que hace los informes y análisis. El ciclo de actualización óptima variará con la industria y con la intencionalidad del proyecto, desde actualizaciones cada hora de interrupción planeada para proyectos de instalaciones de producción y fabricación a actualizaciones semanales o mensuales para proyectos grandes de construcción o desarrollo de software. El ciclo elegido de actualización tiene relación directa con la duración de las actividades contenidas dentro del cronograma. Los profesionales con experiencia a menudo dividen el ciclo de actualización en dos partes distintas: informes de progreso y mantenimiento. Esto sirve para reducir el tiempo dedicado a la elaboración de informes de progreso a un período de tiempo mínimo. La elección del ciclo de actualización depende de una serie de factores, tales como la tasa de cambio en el proyecto, la duración del proyecto, etc. Para proyectos relativamente estables, de largo plazo, de bajo riesgo, un ciclo mensual o bimensual puede ser apropiado. Para proyectos volátiles, 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, días, semanas o meses, la respuesta depende de la frecuencia de los procesos de control y el nivel de detalle necesario en las actividades. La mayoría de las veces, la escala de tiempo de las actividades se mantendrá constante durante todo el proyecto. No obstante, las evoluciones específicas del proyecto pueden requerir diferentes escalas de tiempo efectivas para esa evolución.
.8 Estructura de Codificación de Hitos y Actividades El entendimiento de los tipos de reportes necesarios para crear una presentación a partir del cronograma modelo (vea la figura 2-7) provee una guía para la estructura de codificación a ser construida en el cronograma modelo. Una estructura de codificación debe ser desarrollada de tal manera que se pueda lograr la selección, ordenamiento y agrupación de los datos del cronograma. Esta codificación proveerá asistencia en el desarrollo y mantenimiento del cronograma modelo, así como el logro de los requisitos para los reportes. Las estructuras de codificación bien diseñadas también ayudan en el análisis de los datos de desempeño del proyecto al agrupar, seleccionar y ordenar con el fin de resaltar tendencias y anomalías. Se debe poner énfasis en utilizar una estructura de codificación atinada y bien conceptualizada que sea aparte del identificador de actividad. Las actividades pueden ser codificadas con más de un código para cada actividad, cada código con un valor asignado, permitiendo las salidas personalizadas para diferentes propósitos. Por ejemplo, los códigos pueden ser usados para identificar fases del proyecto, sub-fases, localidad del trabajo, eventos del proyecto, puertas, logros significativos, fuentes de abastecimiento, fuente de diseño, la persona u organización responsable de realizar la actividad, etc. Estos códigos pueden ser usados solos o en múltiples combinaciones. Para alcanzar la flexibilidad y funcionalidad mejorada, la mayoría de software de programación del tiempo permite múltiples códigos para cada actividad. Un esquema estructurado de numeración o identificación de actividades debe formar parte del diseño de la codificación global. El uso de un sistema estructurado de identificación de actividades provee a los usuarios del cronograma una mejor comprensión de cómo se adapta una actividad en particular al esquema global del proyecto captando el significado del identificador de la actividad. Por ejemplo, el esquema de identificación podría incluso ligarse a la EDT del proyecto. Como un mínimo, un identificador de una actividad necesita ser único y seguir un esquema apropiado al proyecto.
.9 Planificación de Recursos Si el cronograma modelo va a incluir recursos de cualquier tipo, el plan de gestión del cronograma modelo identificará los elementos requeridos para la planificación y gestión 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 estándar práctico lo considera como una buena práctica y reconoce que los recursos deberían 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 duración y el costo del proyecto.
.10 Indicadores de Desempeño Para que los interesados conozcan cómo se está desempeñando el proyecto, muchos proyectos definen indicadores claves de desempeño (KPIs), los cuales permiten al equipo del proyecto medir el progreso y el desempeño a través de metas predefinidas (por ejemplo, retroalimentación/calificación del cliente, calificación del equipo de proyecto y EVM). La Gestión 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 Gestión 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 desempeño el proyecto. Para más información sobre EVM y tiempo ganado, refiérase al Estándar Práctico de Gestión 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 ejecución por fases (ingeniería, producción, pruebas e integración), equipos distribuidos globalmente o la estrategia de contratación (múltiples proyectos, múltiples directores de proyecto). Estos subproyectos deben estar relacionados entre sí en ciertos puntos de entrega/aceptación o interconexión, asegurando que exista una conexión entre los planes. El Plan de Gestión del Cronograma Modelo definirá los pasos para la creación, gestión y control del cronograma maestro, sub-proyectos e interdependencias entre proyectos.
3.2 CREACIÓN DEL CRONOGRAMA MODELO Esta sección ofrece una visión general de los elementos esenciales para desarrollar un buen cronograma modelo. Las buenas prácticas se muestran para cada componente contenido en la lista de componentes de este estándar práctico en el capítulo 4. Una revisión del capítulo 4 es altamente recomendada par entender todos los aspectos asociados con cada componente. Es crucial tomar en consideración toda la información, procedimientos y restricciones documentadas en la sección gestión del cronograma modelo. El propósito 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 finalización exitosa del proyecto. El cronograma modelo llega a ser una herramienta desarrollada por el equipo del proyecto, la cual documenta la visión del equipo de cómo se ejecutará el proyecto. El cronograma modelo incluyen cuándo se supone que iniciarán y finalizarán las actividades y es modificado apropiadamente para reflejar los cambios en el progreso, alcance, etc., a medida que son añadidos al cronograma modelo durante el ciclo de vida del proyecto. Un cronograma modelo bien desarrollado es una herramienta dinámica que se utiliza para proveer una predicción razonable de cuándo se espera completar el trabajo faltante del proyecto. Simultáneamente, permite al equipo de trabajo mirar el desempeño del proyecto a la fecha y utilizar la información para hacer pronósticos acertados de la evolución del proyecto que falta por completar. Más aún, 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 (¿quién? y ¿qué?) y la secuencia óptima de actividades incluyendo inicios, finales y relaciones (¿cuándo?) de actividades. La forma de hacer el trabajo (¿cómo?) es definida por otros documentos del plan de proyecto general. Una de las acciones iniciales críticas es establecer un cronograma modelo realista y realizable. Algunos puntos importantes a considerar durante la creación 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, información y entendimiento necesario para desarrollar el cronograma modelo. El propósito es asegurar que todos los aspectos de la ejecución 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 jerarquía 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 básico 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, podría no ser obvio que exista una deficiencia de recursos. En el caso de proyectos grandes y complejos que involucran múltiples organizaciones y tienen una larga duración, podría ser necesario incluir los recursos en el cronograma modelo. Vea el PMBOK para más información sobre recursos. De la misma forma que los códigos de actividades pueden ser usados para clasificar y organizar actividades, los códigos de recursos (atributos) pueden ser asignados a los recursos para clasificarlos de acuerdo a la organización, nivel de habilidad o tipo, estructura de reporte, etc. Además, los identificadores de recursos pueden ser estructurados en forma esquemática similar a los identificadores de las actividades.
3.2.1 DESARROLLAR LA LÍNEA DE BASE DEL CRONOGRAMA MODELO El desarrollo de un buen cronograma modelo se logra a través de la aplicación consistente de atinadas y buenas prácticas. La experiencia ganada a través del tiempo asistirá en la selección de respuestas apropiadas al diseño 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 tendrán una duración cero, sin recursos asignados y se usan como puntos de referencia para medir el avance y pueden también reflejar los puntos de inicio y final para varios eventos del proyecto. Generalmente, un hito va a representar el inicio o la finalización de una porción o entregable del proyecto y también 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 añadiendo tantos hitos como se necesiten. Es un proceso iterativo. (Nota: las actividades pueden ser definidas antes de los hitos).
.2 Diseño 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 ejecución del trabajo. Las características de una actividad bien diseñada incluyen:
La actividad es un elemento (o bloque) de trabajo medible y discreto que es un elemento tangible del alcance del proyecto. Una única persona es responsable por la ejecución de la actividad. Esto no imposibilita la idea que múltiples recursos puedan ser requeridos para lograr la actividad, pero requiere que una única entidad sea responsable de su desempeño. Esa persona debe ser la misma que reportará el progreso de la actividad. Las actividades describen el trabajo a ser realizado. Como tal, la descripción de cada actividad inicia con un verbo y contiene un objeto único y específico. No obstante, “chorrear pared” podría ser descriptiva de una tarea, la descripción de la actividad requiere ser más específica. Los adjetivos podrían ser de ayuda para clarificar ambigüedades. Por ejemplo, “chorrear la placa de fundación de la pared este de x a y” o “revisar la terminología del capítulo 3”. Cada descripción de actividad debe ser única y no debe dejar espacio a confusión, esto es, podrá ser identificada sin ambigüedad y debe ser independiente del grupo u organización que presenta el cronograma.
El trabajo representado por una actividad, una vez iniciado, debe ser capaz de ser completado sin interrupción (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 más actividades en puntos naturales de quiebra.
Típicamente, la duración de una actividad debería ser menor a dos veces el ciclo de actualización. Esto permite el reporte de inicio y finalización de una actividad dentro de uno o dos ciclos de actualización, permitiendo a la administración concentrarse en desempeño y acciones correctivas, si se requieren. Son excepciones a esta regla general las actividades continuas (por ejemplo, la construcción de un túnel de 2 millas o la pavimentación de varias millas de autopista), las actividades de adquisición donde un único ítem de trabajo (por ejemplo, fabricar y enviar un componente a un lugar remoto) podría llevar significativamente más tiempo que dos ciclos de actualización, o una actividad a nivel de esfuerzo (LOE) como el soporte administrativo. En estos casos, la duración 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 estáticas iguales a la longitud del proyecto terminarán siendo parte de la ruta crítica. Por su misma naturaleza de apoyo a actividades puntuales del proyecto, las LOE no pueden definir la duración del proyecto y no pueden ser críticas. Es una buena práctica definir las actividades LOE de tal manera que tomen su duración 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 Planificación Gradual.
.3 Secuenciar las Actividades Secuenciar las actividades e hitos juntos de manera lógica es la base de cualquier cronograma modelo. El método de conexión es definido como una relación. 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 excepción 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 práctica va a prevenir que el cronograma tenga finales abiertos, donde las actividades o hitos no tengan predecesores o sucesores, con la excepción del primer y último hito.
Típicamente, cada actividad predecesora debe terminar antes del inicio de su actividad (o actividades) sucesora(s) (conocida como relación final-a-inicio (FS). Algunas veces es necesario traslapar actividades; una opción podría 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 más comunes en la metodología CPM). Cuando sea posible, la relación FS debe ser usada. Si se requiere utilizar otros tipos de relaciones, deben ser usadas con moderación y con completo entendimiento de cómo 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 relación lógica de un predecesor y el final de cada actividad tiene una relación lógica con un sucesor.
También se pueden añadir 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 días, atrasará el inicio de la actividad sucesora hasta 5 días 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 también son usadas para representar atrasos que sean físicamente necesarios, que no representen trabajo y que tengan duración. Algunos programadores del cronograma se verán tentados a usar demoras para representar un periodo de tiempo cuando el trabajo efectivamente se está produciendo, tal como la revisión 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 práctica permite un mejor control del proyecto y permite hacer muy visible el impacto de una entidad específica en el proyecto. El uso de más de un calendario en un cronograma modelo podría impactar los resultados de cálculos de demoras en un cronograma modelo. Además, es extremadamente importante comprender cómo utilizan los calendarios múltiples los diferentes paquetes de software. También 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 podrían ser utilizadas y entienda el efecto y matiz que tiene su uso sobre el cronograma antes de utilizarlas. La práctica generalmente aceptada es que las restricciones y atrasos no deben ser usados para reemplazar la adición 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 lógicas 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 términos de recursos y la duración 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 más información). Las horas requeridas para un diseñador con experiencia para cumplir a cabalidad la actividad versus lo que demora un diseñador inexperto en realizar la misma actividad podría ser considerablemente diferente, impactando así la duración y calidad de los productos de la actividad y finalmente el costo del proyecto. En algunos proyectos, especialmente aquellos con un alcance más pequeño, definir actividades, secuenciar actividades, estimar recursos, estimar duración de las actividades y desarrollar el cronograma modelo están tan íntimamente relacionadas que son vistas como un único proceso. Los recursos pueden definitivamente impactar el camino crítico si no son considerados por el equipo del proyecto.
.5 Determinar la Duración de Cada Actividad La duración es un estimado de qué tanto tiempo va a necesitar completar satisfactoriamente el trabajo relacionado con la actividad. En muchos casos, el número de recursos que se espera tener disponibles para culminar una actividad, junto con la productividad de esos recursos, puede determinar la duración de la actividad. Un cambio en los recursos asignados a determinada actividad tendrá un efecto en la duración, pero esto no es una simple relación directa. Otros factores que influyen en la duración sin son el tipo o nivel de habilidad de los recursos disponibles para emprender el trabajo, calendarios de recursos y la naturaleza intrínseca del trabajo. Algunas actividades (por ejemplo una prueba de esfuerzo de 24 horas) llevarán una cantidad de tiempo en completarse sin importar la asignación de recursos. Debido a que es factible estimar la duración para una actividad en cualquier momento, las buenas prácticas recomiendan definir la actividad primero y luego ligarla de manera lógica a la secuencia global del cronograma y luego concentrarse en los recursos y la duración de la actividad. En ese momento, la relación entre la duración de la actividad y el trabajo en el cronograma será mejor entendida; por lo tanto los flujos de recursos, los tamaños del equipo de las actividades y el cómo se pueden empezar a determinar. La relación entre la duración y el costo de una actividad se hará explícita 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 sección 3.3 Mantenimiento del Cronograma Modelo y la sección 3.4 Análisis del Cronograma Modelo para más información. Es importante entender el método utilizado por el cronograma modelo con el fin de planear las actividades relacionadas con estimación de duraciones para cada actividad del cronograma. El método usado puede implicar un cronograma determinístico o probabilístico. El modelo de cronograma determinístico es una red de actividades conectadas con dependencias que describen el trabajo a ser realizado, duración estática y la fecha planeada para completar el proyecto si todo va de acuerdo a lo planeado. El modelo de cronograma probabilístico es una red con todos los elementos de un modelo determinístico, pero la duración de las actividades de las tareas son variables aleatorias. Para más información sobre estimar la duración de una actividad, por favor refiérase al Estándar Práctico para la Estimación del Proyecto. Para más información sobre buenas prácticas para análisis de riesgos del proyecto usando modelos de cronograma probabilísticos, vea el Estándar Práctico para la Gestión 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 lógicas definidas. Provee al equipo de proyecto la información de lo necesario que requiere ser llevado a cabo y la secuencia requerida para completar los entregables del proyecto. Sin embargo, todavía no indica cuándo deben ser ejecutadas estas actividades. La herramienta de cronograma es activada para obtener dicha información, para calcular las fechas y otros valores dentro del cronograma modelo en concordancia con el método de programación del tiempo elegido. Sin importar la velocidad de los programas de cómputo, la función de programación del tiempo siempre requiere tres distintos procesos para análisis del tiempo y un cuarto proceso, si se utiliza la nivelación de recursos (resource smoothing). Los distintos pasos son:
Se asigna una fecha de inicio al hito de inicio. Entonces, moviéndose a través de la red de actividad en actividad (de izquierda a derecha) y en la secuencia definida por las relaciones lógicas, se asignan fechas de inicio y finalización a cada actividad e hito, de acuerdo a las duraciones definidas. Esto se llama “paso hacia adelante”. Las fechas de inicio y finalización para cada actividad se llaman el inicio más temprano y el fin más temprano y cuando el análisis alcance el final de la red, establece el fin más temprano posible para el proyecto
y la duración más corta basada en las duraciones estimadas para las actividades y las relaciones lógicas como fueron definidas. Luego, se asigna una fecha de finalización al hito de fin. Esta podría ser la misma fecha que la que se calculó con el “paso hacia adelante” o una fecha diferente aplicada como una restricción. El proceso de análisis entonces trabaja hacia atrás a través del diagrama de red de derecha a izquierda hasta llegar al hito de inicio y otro grupo de fechas de inicio y finalización es asignado a cada actividad. Esto se llama “paso hacia atrás” y establece el inicio más tardío y el final más tardío asignado a cada actividad o hito. Se calculan los valores de holgura comparando las fechas más próximas y las fechas más tardías, como sigue: o La holgura total es calculada substrayendo la fecha más temprana de inicio de la fecha más tardía de inicio (o el inicio más temprano del inicio más tardío). Una holgura total negativa no es factible sin cambiar el plan. o La holgura libre es calculada restando la fecha más temprana de fin de la actividad de la fecha más temprana de inicio del más 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 nivelación de recursos para minimizar sobre colocaciones de recursos o reducir las fluctuaciones en la demanda de recursos. Si este proceso se realiza automáticamente, el programador del tiempo necesita determinar los procesos y algoritmos que se están utilizando. La mayoría de los paquetes de programación del tiempo tienen opciones múltiples y configuraciones que pueden tener un impacto significativo en el cronograma nivelado en recursos. Sin importar que configuración tiene el software, siempre debe haber un equilibrio entre dejar que la nivelación de recursos extienda la duración total del proyecto y permitir el uso de más 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 asignación de recursos a través de todas las actividades debe ser revisada antes de finalizar la nivelación de recursos. Algunos se verán tentados a hacer nivelación de recursos manualmente, ajustando la lógica o añadiendo restricciones para atrasar el inicio de ciertas actividades; esto no es una buena práctica debido a que interfiere con el cálculo normal del cronograma.
.7 Aprobar el Cronograma El equipo de proyecto debe estar activamente involucrado en la revisión de resultados de este proceso inicial de programación del tiempo. La revisión debe considerar el inicio y el final de proyecto analizado, fechas de terminación de hitos, ruta crítica (el trayecto más 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 lógica del cronograma, asignación de recursos y/o duraciones y entonces se vuelve a analizar el cronograma. La modificación más común requerida tiene que ver con acciones para reducir la duración total del cronograma. Las técnicas clave usadas para comprimir el cronograma son la compresión (crashing) y la aceleración (fast-tracking). La compresión del cronograma (crashing) consiste básicamente en añadir recursos a actividades críticas para acortar sus duraciones mientras que la aceleración (fasttracking) consiste en cambiar la lógica mediante el traslape de actividades críticas en vez de trabajarlas en estricta secuencia. La compresión (crashing) únicamente funciona para actividades que son llevadas a cabo con esfuerzo en las que añadir recursos va a reducir la duración de la actividad. La compresión (crashing) típicamente incrementa los costos del proyecto por un determinado factor mientras que la aceleración (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 también el capítulo 6 de la guía PMBOK). Estas iteraciones continúan hasta que se desarrolle un cronograma aceptable, uno que los interesados acuerden que sea realizable. El proceso formal para la aprobación de la línea de base del cronograma será definido en el Plan de Gestión del Cronograma Modelo.
.8 Línea de Base del Cronograma Modelo Una vez acordada, la primera versión del cronograma que sea desarrollada completamente para la captura o copia para referencia futura se llama la línea de base del cronograma modelo. Esta línea de base se convierte en el punto de comparación contra el cual se va a medir el desempeño del proyecto. Es una práctica generalmente aceptada que cada proyecto tiene una línea de base del cronograma modelo en sitio antes de la ejecución del trabajo del proyecto. Una vez que la línea base haya sido aprobada a través de procedimientos formales, los reportes se distribuirán en
concordancia con el plan de comunicaciones y los cambios a la línea base son monitoreados y controlados a través de procesos integrados de control de cambios.
3.3 MANTENIMIENTO DEL CRONOGRAMA MODELO La mayoría de proyectos inevitablemente va a experimentar cambios. Para asegurar una ejecución exitosa, son necesarios un control de cambios efectivo y procedimientos de mantenimiento disciplinados. La clave es determinar cómo 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 más rápido o más 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 después de que se definió la línea 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 terminación exitosa del proyecto. Los principales pasos para el seguimiento del avance son como sigue:
Guardar una línea 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 línea de base o un cronograma modelo más adecuado puede ser aprobado como línea de base. El avance del cronograma es reportado para un dato de fecha específica, también conocida como fecha de estado, fecha de actualización, fecha actual, o fecha presente. Este avance, como mínimo, 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/actualización se determina regularmente durante el proceso de planificación del proyecto. Los pasos requeridos para mantener el cronograma en cada estado/actualización 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 información 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 obtención del estado también incluye los cambios en las duraciones para futuras actividades. Otra información recolectada acá puede incluir información sobre uso de recursos y costos incurridos. Los datos son recabados a una fecha determinada. Esta fecha es análoga al “tiempo actual” de la gestión del desempeño del valor ganado (EVPM).
3.3.2 ACTUALIZAR Y MEDIR EL AVANCE DEL CRONOGRAMA MODELO DE ACUERDO AL ESTADO ACTUAL Introduzca información 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 prácticas de control de calidad deben poder identificar el ingreso de datos vigentes más allá de la información sobre fechas y porcentaje completado que se estén reportando y no sean válidos en relación con las fechas.
3.3.3 COMPARE Y RESUELVA CUALQUIER DESVIACIÓN Compare el cronograma modelo recién actualizado con el cronograma modelo de la línea de base y gestione costo y variaciones en el tiempo. Los niveles mínimos de variación definidos en el plan de gestión del cronograma modelo pueden ser usados para determinar cuáles actividades y condiciones requieren reportes y acciones adicionales. Una variación de fechas usada comúnmente es la variación final entre el final más temprano y el final de la línea de base, la cual es frecuentemente expresada en unidades como días laborales. Comparar el estado de una actividad contra más de un objetivo podría ser útil, por ejemplo el cronograma actual versus:
El plan original –la línea de base- para ver la demora comparada con el plan original. El último periodo actualizado para ver los cambios desde la última actualización.
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 actualización y ajuste podrían necesitar un número de iteraciones para mantener un cronograma modelo que se mantenga realista y realizable.
3.3.5 ACTUALICE LA LÍNEA DE BASE DEL CRONOGRAMA MODELO Actualice, a través del proceso formal de control de cambios, la línea 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 ejecución del proyecto. Solamente las actividades que son nuevas o con cambios aprobados y aquellas actividades que están directa o indirectamente ligadas a ellas, deben ser ajustadas en su línea 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 gestión del cronograma modelo y el plan de gestión de comunicaciones del proyecto una vez que el ciclo de actualización del cronograma ha sido completado.
3.3.7 MANTENGA LOS R EGISTROS La gestión adecuada de registros es parte del control de la configuración. Los registros bien mantenidos que detallen la lógica inicial y puntos principales de decisión del proyecto y los procesos de pensamiento que permitieron crear la lógica de flujo del cronograma de línea de base ayudan en defensa de las acciones tomadas y lecciones aprendidas. Mantenga registros que expliquen todos los cambios en la duración de actividades o lógica durante la realización de alteraciones en el cronograma modelo. Las notas de registro de las actividades a menudo se utilizan para este propósito. Estos registros proveerán información valiosa si fuera necesario reconstruir lo que pasó y por qué. Muchas de las buenas prácticas y elementos descritos anteriormente también están incluidos dentro de los detalles de cada componente contenido dentro de los componentes del cronograma modelo listados como se presenta en el capítulo 4. Un entendimiento completo de los diversos componentes se requiere para maximizar el potencial para su correcta aplicación y el desarrollo de un cronograma atinado.
3.4 ANÁLISIS DEL CRONOGRAMA MODELO El análisis del cronograma utiliza herramientas comunes y técnicas a través del ciclo de vida del proyecto con el objetivo de identificar la desviación de la línea de base del cronograma modelo. El análisis del cronograma es responsabilidad del equipo del proyecto y el objetivo principal del análisis es la identificación temprana de amenazas y oportunidades a los objetivos del proyecto. Estas son varias herramientas y técnicas disponibles para realizar el análisis del cronograma modelo. Los procedimientos específicos y las políticas a utilizar para un proyecto se describen en el Plan de Gestión del Cronograma del Proyecto. Los ítems más comunes de revisión durante el análisis del cronograma se describen en los apartados 3.4.1 a 3.4.11.
3.4.1 RUTA CRÍTICA Y A CTIVIDADES CRÍTICAS .1 Ruta Crítica La ruta crítica es habitualmente, pero no siempre, la secuencia de las actividades del cronograma que predice o define la duración más larga del proyecto. Generalmente, es la ruta más larga a través del proyecto y por lo tanto determina la duración del proyecto. Sin embargo, una ruta crítica puede finalizar, por ejemplo, en un hito del cronograma que está en el medio del cronograma modelo y que tiene una restricción de final-no-más-allá-de. (Recuerde que las restricciones son para utilizarse selectivamente en los cronogramas modelo). Pero el(los) riesgo(s) y la(s) restricción(es) pueden alterar la ruta crítica, elevando la importancia de menos actividades en apariencia y causando cambios inesperados a la duración y al costo del proyecto. Un proyecto puede tener múltiples rutas críticas. Un proyecto con múltiples rutas críticas tiene un mayor nivel de riesgo 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 Críticas Es importante distinguir entre actividades de la ruta crítica y actividades críticas. Las actividades de la ruta crítica son aquellas actividades contenidas en la(s) ruta(s) crítica(s). Las actividades críticas son aquellas actividades vitales para el éxito de un proyecto, aun cuando no estén en el camino crítico previsto del CPM o en la cadena crítica. Las actividades críticas generalmente tienen un alto riesgo en términos 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 crítica también son consideradas actividades críticas. Los cálculos de ruta crítica consideran actividades y restricciones para determinar el camino más largo del proyecto. Las actividades críticas pueden estar fuera de la ruta crítica.
3.4.2 HOLGURA TOTAL Y HOLGURA LIBRE La holgura libre representa la cantidad de tiempo en la que la fecha más temprana de fin de una actividad del CPM puede ser retrasada sin impactar la fecha más temprana de inicio de cualquier actividad sucesora del CPM. La holgura total representa la
cantidad de tiempo que el tiempo más temprano de inicio o el tiempo más temprano de fin de una actividad del CPM pueden ser retrasados sin impactar la fecha más tardía 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 actualización. Los cambios en la holgura total indican una amenaza a la terminación del proyecto o de hitos específicos; la holgura libre indica cómo 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 gestión de estos dos componentes vitales es crítico 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 recuperación.
3.4.3 ACTIVIDADES DE NIVEL DE ESFUERZO (LOE) Las actividades de nivel de esfuerzo (LOE) están para apoyar actividades del trabajo o el esfuerzo total del proyecto. Ejemplos de esta actividad son la gestión del proyecto, la contabilidad del presupuesto, relación con el cliente o la rotación 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 realización del producto final del proyecto, servicio o resultado, sino que es una actividad que apoya tal trabajo, su duración está basada en la duración 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 empezarán cuando inicie el trabajo y finalizarán cuando el trabajo esté terminado. Como resultado, una actividad LOE nunca podrá estar en la ruta crítica del cronograma modelo ya que nunca añade tiempo al proyecto. Más bien, la instalación de maquinaria estaría en el camino crítico y la actividad de mantenimiento preventivo se volvería más corta o más larga solamente si lo hace el tiempo-en-almacenaje de la maquinaria. Cuando se introducen actividades LOE en un cronograma creado con el método de la ruta crítica, 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 transición, 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 relación, no están limitadas a relaciones inicio-inicio o fin-fin. Las actividades LOE pueden tener muchos tipos de relaciones asociadas con ellas. La nivelación de recursos podría no realizarse y no aplicarse restricciones a las actividades LOE; ellas usan sus calendarios asignados para concretar sus fechas.
3.4.4 DISTRIBUCIÓN PROBABILÍSTICA DE DURACIÓN DE ACTIVIDADES Si las duraciones de las actividades implican un gran componente de incertidumbre, una técnica de estimación comúnmente usada es la estimación de tres puntos. Estos tres puntos corresponden a la duración de la actividad definida como optimista, más probable y pesimista. Adicionalmente, el registro de riesgos puede también ser usado para apoyar la estimación de incertidumbre en la duración de actividades. Para poder cuantificar la incertidumbre sobre la duración total del proyecto, empezando con la estimación de los tres puntos para cada actividad, el PERT (que usa una aproximación de la distribución beta y la ecuación en la sección 2.2.3) puede ser utilizado. La duración optimista de una actividad y la duración pesimista representan duraciones probables, pero no el dominio completo de valores. Las estimaciones de duración de tres puntos deben ser hechas por quienes van a ejecutar las actividades o por alguien con experiencia en la ejecución de actividades similares. La aproximación más común para crear la distribución probabilística es estimar el valor más probable tan exacto como sea posible y entonces sesgar la distribución hacia los valores máximo y mínimo. El grado en el cual la distribución es sesgada se sugiere por la forma de la curva que ajusta las tres duraciones estimadas (como beta, uniforme o triangular). La distribución 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 análisis 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 análisis profundo de este sesgo sin realizar una simulación como la de Monte Carlo, la cual determinará la magnitud del sesgo. Entre más largo y complejo sea el proyecto, más grande será el impacto acumulado del riesgo del proyecto. La circunstancias que dictan la frecuencia, rigor y uso del análisis de riesgo del cronograma están documentadas en el plan de gestión del proyecto u otro documento contractual. Para más información en los conceptos de riesgo vea el Estándar Práctico para la Gestión del Riesgo del Proyecto.
3.4.6 RESTRICCIÓN DE FECHAS La restricción de fechas restringe el flujo natural del proyecto, dejando de lado los efectos del riesgo y limita la utilidad del análisis 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 restricción de fecha puede ser para establecer una fecha no-mas-temprano-que o no-más-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 práctico 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 crítico. 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 lógica del cronograma no puede manejar correctamente la situación. Cuando sea necesaria una restricción 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 lógicas entre las actividades del proyecto, crear una falsa apariencia de holgura en un proyecto y reducir el impacto aparente del riesgo durante el análisis 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 deberán contender extremos abiertos.
3.4.8 LÓGICA DE FUERA DE SECUENCIA (OOS) La lógica 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 lógica fuera de secuencia. Como ejemplo, si la actividad A tiene una relación 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 lógica OOS. La lógica OOS debe ser corregida (por ejemplo, mediante mayor descomposición de la actividad A) o removida para preservar la integridad del análisis de riesgo. El análisis del cronograma identificará propiamente como resolver mejor los problemas lógicos de OOS; sin embargo, no se base únicamente en la herramienta de programación del tiempo para corregir el problema, porque solamente el equipo del proyecto puede determinar mejor la solución más lógica al OOS. En algunos casos, puede ser que la relación definida que se creó durante la etapa de planificación 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 duración total del proyecto. Los adelantos y demoras pueden introducir riesgo al cronograma y deben ser modelados como distintas actividades con su propia incertidumbre de duración cuando sea posible. Los adelantos pueden introducir riesgo al costo especialmente en la gestión 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 simulación Monte Carlo no permite asignación de incertidumbre de duración a un adelanto/demora. Adicionalmente, el implementar un adelanto/demora a una actividad completa permite asignarle atributos adicionales, como nombre, duración restante, etc. La falta de visibilidad del adelanto/demora y la distorsión del cálculo de la ruta crítica contribuyen al riesgo del cronograma. Existe un riesgo específico asociado con
cualquier atraso y demora aplicado a las actividades donde se estén 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 duración fija o como un porcentaje de la duración de la actividad; se necesita buen juicio para utilizar el método correcto que represente la naturaleza de la actividad y del adelanto o la demora.
3.4.10 RELACIÓN INICIO-A-FIN Las relaciones inicio-a-fin (SF) en ocasiones son deliberadamente usadas en planificación determinística porque ellas involucran la circunstancia inusual de una actividad sucesora sucediendo antes de su predecesor lógico. Revise cualquier relación inicio-a-fin (SF) para asegurar que no es el resultado de errores en el cronograma y modifíquela si fuera necesario. El siguiente ejemplo ilustrativo de una relación SF provee una mejor comprensión de esta excepcional relación: Ejemplo – Suponga que el proyecto requiere la entrega de una pieza de un equipo para dar soporte a actividades de construcción. Podría no ser práctico proveer lógica a las actividades de fabricación del equipo y entrega, aun así el equipo quiere que las actividades de construcción manejen las fechas de la entrega. Debido a que el predecesor siempre maneja el sucesor, la relación SF provee la solución. Entonces la fabricación del equipo puede concluir después del inicio de la actividad que requiere el equipo que se va a instalar.
3.4.11 VÍNCULOS DE/HACIA ACTIVIDADES DE RESUMEN Generalmente no se recomienda usar vínculos a actividades de resumen porque la lógica puede ser difícil de seguir y la práctica podría no estar respaldada por todas las herramientas de programación del tiempo. El uso de vínculos a las actividades de resumen puede producir errores de lógica y crear lógica circular dentro del cronograma modelo.
3.5 COMUNICACIÓN Y REPORTE Las comunicaciones claras crean credibilidad con los interesados. El Director del Proyecto junto con el equipo del proyecto crean un plan de gestión de las comunicaciones (ver la Guía 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 estratégico e importante dentro de las herramientas del Director del Proyecto para guiar un proyecto exitosamente a su fecha de finalización programada. Un cronograma modelo es una línea de tiempo o calendario que lista actividades con fechas esperadas de inicio y de fin. Un cronograma modelo también puede ser superpuesto con diferentes detalles para posibilitar que los Directores de Proyecto direcciones y gestionen los recursos más fácilmente, controlen las evoluciones del proyecto día a día, se comuniquen más 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 versión del cronograma modelo puede producir múltiples formatos de reporte, dependiendo del propósito del cronograma modelo, la etapa de desarrollo del proyecto y el usuario principal del cronograma modelo. Los clientes podrían requerir varios niveles de presentaciones de las versiones del cronograma modelo. Para más información vea el componente nivel del cronograma modelo en el capítulo 4.
CAPÍTULO 4. COMPONENTES DEL CRONOGRAMA La siguiente sección provee un catálogo detallado de los componentes potenciales de una herramienta de calendarización. Cada entrada incluye ocho posibles tipos de información relacionada con cada componente e indica si el componente se considera que sea requerido, condicional u opcional por este estándar práctico. Los componentes requeridos están divididos en cuatro grupos: Componentes Clave Requeridos (CRC, mostrados como “R” en las tablas), Componentes Requeridos de Recursos (RRC), Componentes Requeridos de Gestión 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 valoración de madurez. La valoración de madurez y el índice de conformidad se explican con detalle en el capítulo 5. Este capítulo está dividido en las siguientes secciones: 4.1 Cómo Usar La Lista de Componentes: esta sección define el tipo de información que puede ser mostrada para cada componente. 4.2 Lista de Componentes por Categoría: esta sección describe una descomposición de los componentes de una categoría específica. Esta información va a facilitar la localización de un componente específico. Cada componente está identificado como requerido, condicional u opcional. 4.3 Lista Detallada de Componentes: esta sección lista cada componente del cronograma y sus tipos de información asociados en orden alfabético.
4.1 CÓMO USAR LA LISTA DE COMPONENTES A continuación se muestra la disposición de una entrada típica de componente. Las subsecciones de 4.1 definen el contenido para cada elemento de información dentro de cada componente. Nombre del Componente / Requerido, Uso Condicional u Opcional / Manual o Calculado Formato de Datos: Comportamiento:
Buenas Prácticas: Nota Condicional / Componente Asociado: Definición:
4.1.1 NOMBRE DEL COMPONENTE Este elemento de información 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 estándar permita su uso correcto.
4.1.2 USO REQUERIDO, CONDICIONAL U OPCIONAL Este elemento de información indica si el uso de un componente es: requerido, para cualquier cronograma modelo; condicionalmente requerido, basado en el estado o acción de otro componente o un proceso; u opcional.
4.1.3 MANUAL O CALCULADO Este elemento de información describe cómo se configura la información 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 INFORMACIÓN Este elemento de información describe cómo es configurada la información dentro del componente como parte de la herramienta de cronograma. El formato de información puede variar de una herramienta de cronograma a otra.
4.1.5 COMPORTAMIENTO En la lista de componentes, este elemento de información describe cómo reacciona el componente y/o permite la reacción dentro de la herramienta de cronograma. Es importante notar que todas las descripciones de comportamiento comienzan con un verbo indicando la acción. El comportamiento actual de un componente puede variar entre herramientas de cronograma o configuraciones dentro de la misma herramienta.
4.1.6 BUENAS PRÁCTICAS En esta lista, “buenas prácticas” significa que existe acuerdo general que la correcta aplicación de habilidades, herramientas y técnicas cuando se aplican en conjunción con el componente, pueden mejorar las posibilidades de éxito sobre un amplio rango de proyectos diferentes. Buena práctica 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 información indica si esta acción del componente es dependiente del estado o acción de otro componente.
4.1.8 DEFINICIÓN Este elemento de información describe el uso general y función del componente dentro de la herramienta de calendarización. La definición provista es la misma que la provista en el Glosario, donde aplique.
4.2 LISTA DE COMPONENTES POR CATEGORÍA Esta sección contiene una lista de componentes organizada por categorías. La columna “Uso” identifica si un componente es requerido medular (R), componente requerido de recurso (RRC), componente requerido de gestión 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 puntuación en el proceso de valoración de la madurez descrito con gran detalle en el capítulo 5.
4.3 LISTA DE COMPONENTES DETALLADA Esta sección identifica individualmente los componentes y los ocho tipos de información definida para cada componente. Está organizada alfabéticamente.
CAPÍTULO 5. ÍNDICE DE CONFORMIDAD Este capítulo está diseñado para proveer una visión general del proceso de Índice de Conformidad. Este capítulo está dividido en las siguientes secciones: 5.1 Visión general de conformidad 5.1.1 Categorías de componentes 5.1.2 Utilización de componentes 5.1.3 Valoración de conformidad 5.2 Proceso de Valoración de Conformidad Cada sección provee diálogo adicional en el contenido y terminología de este estándar práctico.
5.1 VISTAZO GENERAL DE CONFORMIDAD El Índice de Conformidad provee un medio para evaluar qué tan bien un modelo de cronograma específico incorpora los lineamientos, definiciones, funcionamientos y buenas prácticas para los componentes que se definieron en este estándar práctico de calendarización (capítulo 4). A pesar de que algunos Directores de Proyectos suelen elegir no incluir algunos de estos componentes básicos requeridos (CRC), al hacer eso, el cronograma modelo resultante no está en conformidad con este estándar práctico y podría no ser admisible. La premisa básica es que a medida que crece el Índice de Conformidad, también lo hace la aplicación correcta de los componentes del cronograma modelo y la posibilidad de que el cronograma modelo desarrollado represente un plan atinado. El índice también fue construido para reflejar donde están las debilidades del cronograma modelo desarrollado y las áreas que más necesitan mejora. Se definen conceptos de calendarización, funcionamientos, atributos y buenas prácticas para todos los componentes del cronograma modelo. La conformidad del cronograma modelo es estimada evaluando la existencia de la correcta utilización de varios componentes definidos en este estándar práctico de acuerdo a las buenas prácticas.
5.1.1 CATEGORÍAS DE COMPONENTES La lista de componentes en el capítulo 4 identifica aquellos componentes que son:
“requeridos” en un cronograma modelo; “opcionales” que pueden estar presentes pero no son requeridos; “sin puntuación (NS)” que son componentes opcionales que pueden estar presentes en un cronograma modelo pero que no puntúan 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 gestión del valor ganado (ERC) son requeridos si los documentos del proyecto requieren Gestión 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 UTILIZACIÓN DE COMPONENTES DEL CRONOGRAMA El uso de componentes del cronograma en un cronograma modelo dado es frecuentemente dado por el tamaño 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 estándar práctico. Los demás tipos de componentes requeridos son aplicados para un proyecto específico, dependiendo de los requisitos de ese proyecto. Esos requisitos son definidos por varios documentos del proyecto y están contenidos normalmente dentro de los activos de la organización, el lenguaje del contrato del proyecto o el plan de manejo del cronograma modelo del proyecto, pero también puede ser cualquier otro documento escrito.
Los componentes RRC, ERC y KRC están 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 gestión del riesgo, entonces los requisitos serán CRC + RRC. De igual manera, cada área requerida será añadida a los CRC cuando sean requeridos por el proyecto. Si se requieren recursos, riesgo y EVM, entonces los componentes requeridos serán CRC + RRC + ERC +KRC. A medida que crece la complejidad del proyecto, también lo hace el número de componentes requeridos. Los componentes requeridos necesitan ser completamente utilizados con el fin de lograr un nivel mínimo 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 serán opcionales para el proyecto. La calificación para el Índice de Conformidad se realiza de acuerdo al apéndice D, el cual divide los componentes en tres categorías básicas: 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 añadir a la puntuación. El uso de componentes opcionales puede sumar al índice solo si esos componentes están en completo acuerdo con las recomendaciones de buenas prácticas definidas en la lista de componentes del capítulo 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 capítulo 4.
5.1.3 EVALUACIÓN DE LA CONFORMIDAD El proceso de evaluación está compuesto por dos partes: una para la aplicación de los componentes requeridos y una evaluación para la aplicación 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 evaluación se explica con más detalle en la sección 5.2. El concepto crítico es que los componentes requeridos tienen que estar presentes antes de que se registre el Índice de Conformidad; los componentes requeridos específicos pueden cambiar según 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 incorporación de los componentes requeridos apropiados, se pueden lograr mayores grados de conformidad a través de la correcta utilización de componentes opcionales del cronograma que estén disponibles. Los componentes opcionales pueden ser tomados en cuenta si ellos se adhieren propia y completamente a las definiciones, propiedades y buenas prácticas definidas en el capítulo 4. Los componentes opcionales deben ser usados únicamente para apoyar las necesidades de un proyecto específico, nunca para incrementar el valor del índice únicamente. Como regla general, el uso de componentes opcionales se esperaría encontrar en organizaciones más sofisticadas o modelos de cronograma más complejos. Los modelos de cronograma que no utilizan completamente todos los componentes requeridos y sus conceptos son considerados de naturaleza para el desarrollo. Los cronogramas modelos para el desarrollo podrían también ser evaluados con un valor del índice de conformidad pero etiquetado como “no cumple estándares mínimos de conformidad”. La evaluación de conformidad del cronograma modelo está diseñada para apoyar una evaluación manual. Cuando un componente está presente en el cronograma modelo y se utiliza propiamente, se gana un punto. La razón del número total de puntos (requeridos más opcionales) ganados en relación al número total de puntos que pudieron ser obtenidos representa el valor de conformidad y es expresado como un porcentaje de 0 a 100. La excepción 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 mínima con este estándar práctico. Si se alcanza el nivel mínimo, entonces el valor de la razón es representada en una escala continua o móvil, siendo 35 el más bajo y 100 el más alto (ve la tabla 5-1). El valor más bajo representa la relación que resultaría de únicamente los requisitos requeridos (CCR), todos los cuales son necesarios en todo cronograma modelo. Requerido
Condicional
CRC RRC ERC KRC 36 11 9 7 Tabla 5-1 Número de componentes por categoría
Opcional Opcional 40
Total Disponible 103
Si el evaluador determina que los estándares de conformidad mínima todavía no se han alcanzado, el evaluador puede terminar el proceso de evaluación o continuar la evaluación con propósitos de necesidades de desarrollo y para ayudar a la organización a identificar áreas específicas que requieren mejoras. En este caso, sin
importar el número de puntos ganados, el valor de la evaluación del cronograma modelo no será registrado ya que no cumple los estándares mínimos de conformidad.
5.2 PROCESO DE EVALUACIÓN DE LA CONFORMIDAD El apéndice 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 número máximo de componentes por categoría así como el número máximo de componentes calificables. Los componentes NS no se incluyen en esta tabla ya que el número de componentes disponible no es igual al número de componentes definido en el capítulo 4. Al utilizar la lista del apéndice 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 prácticas asociadas con los diversos componentes requeridos y opcionales. Para empezar con el proceso de evaluación, 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 gestión de riesgo del cronograma? Si la respuesta a cualquiera de esas preguntas es sí, entonces los componentes requeridos del cronograma para ese grupo serán requeridos además de os CRC. Los CRC, entonces, estarán presentes en cualquier cronograma modelo. Ejemplos de cómo los requisitos condicionales pueden afectar el nivel son: o Si se requiere la carga de recursos, se necesita el RRC y el nivel mínimo de componentes es CRC + RRC. o Si se requiere EVM, se requiere ERC y el nivel mínimo del componentes requeridos es CRC + ERC. o Si se requiere valoración del riesgo, se necesita el KRC y el nivel mínimo de componentes requeridos es CRC + KRC. o Si se requiere la carga de recursos y EVM, el nivel mínimo de componentes requeridos es CRC + RRC + ERC. o Si se requiere, la carga de recursos, manejo de riesgos y EVM, el nivel mínimo de componentes requeridos es CRC + KRC + RRC + ERC.
Dependiendo de los requisitos del proyecto, el valor que puede ser alcanzado por la total conformidad con los componentes requeridos puede variar entre CRC y CRC más
la suma de los componentes adicionales requeridos por RRC / ERC / KRC. Este valor abarca la primera parte del proceso de evaluación llamada “valor de los componentes requeridos”. La parte restante del puntaje de la evaluación es alcanzada por todos los componentes “opcionales” disponibles. Por ejemplo, si los componentes KRC no se requirieran, entonces todos los componentes del riesgo se considerarían 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 están 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 calificación 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 calificación final bruta no puede ser registrada, no obstante la calificación bruta puede ser compartida con el proyecto para que comprendan las áreas que deben mejorar. Finalmente la calificación bruta es dividida por el puntaje máximo 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 básico de evaluar la conformidad del cronograma modelo con este estándar práctico y su madurez asociada ha sido cumplido a cabalidad y el evaluador ha determinado en qué punto de la escala de calificación ha caído el cronograma modelo. El programador del tiempo puede determinar acciones específicas para moverse más allá en la escala de calificación. Un valor mayor del Índice de Conformidad no implica automáticamente un mejor cronograma modelo, no obstante eso podría indicar una mayor posibilidad de lograr los objetivos del proyecto. El apéndice E contiene una hoja de evaluación en blanco y algunos ejemplos.
