GESTION DEL TIEMPO

¿Qué es la Gestión del tiempo del proyecto?

El tiempo es el elemento principal en toda planificación, que por definición consiste ante todo en situar en el tiempo las tareas a realizar, también se considera un recurso escaso, pero no solo el tiempo laboral, sino también el que dedicamos a nosotros mismos. El uso del tiempo es algo que sobrepasa los límites organizacionales y se expande hasta nuestra vida privada. El tiempo que se dedica a la familia y los hijos, en fin a la vida privada, es tan valioso como el tiempo que dedicamos a nuestras organizaciones.

La Gestión del Tiempo del Proyecto incluye los procesos necesarios para lograr la conclusión del proyecto a tiempo; no es la habilidad de exprimirle más horas al día. Tampoco es triplicarse a uno mismo para poder hacer mas cosas. De hecho, no tiene nada que ver con hacer mas cosas; se trata de concretar lo que es más importante.

Aunque la sociedad necesita de nuestro trabajo para crecer y desarrollarse, también necesita de personas centradas, satisfechas y motivadas. La satisfacción en la vida laboral, en ningún momento va a suplantar la satisfacción en la vida personal, pues son dos aristas de nuestro proyecto de vida que no se pueden superponer.

¿Cuales son sus objetivos?

El objetivo fundamental de la Gestión del tiempo del Proyecto "es concluir el proyecto a tiempo, logrando el alcance del proyecto, en tiempo, costes y calidad requerida por el cliente, sin rebasar los riesgos inherentes del proyecto".

Para poder llevar esto acabo debemos realizar entre otras las siguientes acciones:

* Definir claramente el objetivo del proyecto (Poner los pies en la tierra; la naturaleza del proyecto debe ser real, sustentable).
* Determinar que tareas se requieren para llevarlo a cabo.
* Determinar el calendario de trabajo (debe tener un programa de actividades o plan de trabajo).
* Fijar las duraciones de las distintas actividades, así como hitos importantes.
* Planificar la realización de las tareas.
* Asignar recursos a dichas tareas.
* Estudiar las relaciones entre tareas y resolver conflictos entre recursos.
* Establecer los costes de las tareas.
* Seguir la obra en curso y compararla con el plan.
* Seguir los costes y compararlos con el presupuesto.
* Prever, analizar y llevar acabo las acciones correctoras debidas.
* Dotarnos de la estructura adecuada al proyecto y al equipo (DET).
* Hacer participe al equipo en la programación y en la resolución de los problemas.
* Buena calidad de los informes sobre el estado y el avance del proyecto.

Procesos de la Gestión del tiempo del proyecto

La gestión del tiempo del proyecto asegura que el proyecto se lleve a cabo en los plazos previstos. Para ello hay que definir la secuencia de actividades a realizar, así como su duración y coordinación. Incluye los procesos requeridos para asegurar una terminación a tiempo del proyecto.

* Definición de las actividades: Consiste en identificar las actividades específicas que deberán ser ejecutadas para producir las entregas principales del proyecto.

Entradas:

- Desglose Estructurado de Trabajo (DET): Es un agrupamiento orientado a la entrega de los elementos del proyecto que organiza y define el alcance total del proyecto: Trabajo que no este incluido dentro del DET está fuera de alcance del proyecto. La estructura de desglose de trabajo es la entrada primaria para la definición de actividades.

- Declaración del alcance: Provee una base documentada para la toma futura de decisiones y para confirmar o desarrollar la comprensión en común del alcance del proyecto entre los distintos partidos interesados. A medida que el proyecto progresa, esta declaración del alcance puede ser revisada o refinada para reflejar los cambios al alcance del proyecto.

Durante la definición de actividades, la justificación del proyecto y los objetivos de este, deben ser considerados explícitamente:
· Justificación del proyecto: es la necesidad del negocio para la cual el proyecto fue desarrollado. La justificación de proyectos provee la base para evaluar cambios futuros.
· Objetivos del proyecto: son el criterio cuantificable que se debe cumplir para que el proyecto sea considerado exitoso. Los objetivos del proyecto deben incluir al menos costo, cronograma y medidas de calidad.

- Información histórica: La información histórica sobre (cuales actividades fueron realmente requeridas en proyectos similares previos) debe ser considerada en la definición de las actividades de proyecto.

- Restricciones: Las restricciones son factores que van a limitar las opciones del equipo de administración de proyectos; por ejemplo, un presupuesto predefinido es una restricción que muy probablemente limitará las opciones del equipo del proyecto. Cuando un proyecto es ejecutado bajo un contrato, las provisiones contractuales generalmente serán restricciones a esta.

- Suposiciones: Son factores que, para los procesos de planeación, serán consideradas como verdaderas, reales, o ciertas. Por ejemplo, si la fecha en que una persona clave estará disponible es incierta, el equipo puede asumir una fecha de comienzo específica. Las suposiciones generalmente involucran algún grado de riesgo y serán normalmente una salida del proceso de identificación de riesgos.

Herramientas y Técnicas:

- Descomposición: Dentro del contexto de los procesos de definición de actividades, la descomposición involucra subdividir los paquetes de trabajo de proyecto, en componentes más pequeños y más manejables, para proporcionar mejor control administrativo. La principal diferencia entre la descomposición aquí, y la definición del alcance es que las resultantes finales aquí, son descritas como actividades en lugar de entregas. El DET, y la lista de actividades, son usualmente desarrolladas secuencialmente, con el DET, siendo la base para el desarrollo de la lista final de actividades. En algunas áreas de aplicación, el DET, y la lista de actividades son desarrollados concurrentemente.

- Patrones: Una lista de actividades o un fragmento de una lista de actividades de un proyecto previo, es frecuentemente usado como patrón o forma, para un nuevo proyecto. Las actividades en estas formas pueden también contener una lista de recursos ya habilitados que ahorran horas de trabajo, así como identificación de riesgos, entregas y otra información descriptiva.

Salidas:

- Lista de actividades: La lista de actividades debe incluir todas las actividades que serán ejecutadas en el proyecto. Deberá ser organizada como una extensión del DET para ayudar a asegurar que está completo y que no incluye actividades que no son requeridas como parte del alcance del proyecto. Así como con el DET; la lista de actividades debe incluir descripciones de cada actividad para asegurar que los miembros del equipo del proyecto entenderán como se deberá de ejecutar el trabajo.

- Detalle de soporte: El detalle de soporte para la lista de actividades deberá ser documentado y organizado de manera que facilite su uso por otros procesos de la administración del proyecto. El detalle de soporte deberá siempre incluir documentación de todas las suposiciones y restricciones identificadas. La cantidad de detalle adicional varía de acuerdo con el área de aplicación.

- Actualizaciones a la estructura de desglose de trabajo: Al usar el DET para identificar que actividades son necesarias, el equipo del proyecto puede identificar entregas faltantes o puede determinar que la descripción de la entrega puede necesitar clarificación o corrección. Tales actualizaciones deben ser reflejadas en el DET y documentos relacionados tales como estimativos de costos. Estas actualizaciones se llaman muchas veces refinamientos y son muy probables cuando el proyecto involucra tecnología nueva o tecnología que no ha sido ensayada.

* Secuencia de las actividades:

Consiste en identificar y documentar las dependencias entre actividades. Las actividades deben ser secuenciadas con exactitud, para que constituyan el soporte de un programa realista y alcanzable.

Entrada:
- Lista de Actividades: La lista de actividades debe incluir todas las actividades que serán ejecutadas en el proyecto. Deberá ser organizada como una extensión del DET para ayudar a asegurar que está completo y que no incluye actividades que no son requeridas como parte del alcance del proyecto. Así como con el DET; la lista de actividades debe incluir descripciones de cada actividad para asegurar que los miembros del equipo del proyecto entenderán como se deberá de ejecutar el trabajo.

- Descripción del producto: Los documentos de descripción del producto describen las características del producto o servicio que fue elegido para crearse. La descripción del producto generalmente tendrá menos detalles en sus fases tempranas y más detalle en las fases subsiguientes a medida que las características del producto son elaboradas progresivamente. También documentará la relación entre el producto o servicio creado y la necesidad del negocio u otro estimulo que dio pie para la creación del proyecto. Mientras que la forma y la sustancia de la descripción del producto variarán, siempre será lo suficientemente detallada de manera que sirva de soporte para la planeación del proyecto. Las características del producto a menudo afectan la secuencia de las actividades (p. Ej. El plano de una planta a ser construida, las interfases de un subsistema en un proyecto de cómputo). Mientras estos efectos sean visibles en la lista de actividades, la descripción del producto generalmente deberá ser revisada para asegurar su exactitud.

- Dependencias mandatorias: son aquellas que son inherentes a la naturaleza del trabajo que se ejecuta. Muchas veces involucran limitaciones físicas (en un proyecto de construcción es imposible erigir la superestructura hasta que se haya construido las fundaciones; en un proyecto electrónico, un prototipo deberá ser construido antes de probarlo). Las dependencias mandatorias también se llaman lógica dura.

- Dependencias discrecionales: Son aquellas que son definidas por el equipo de administración de proyectos. Estas deben ser usadas con mucho cuidado (y completamente documentadas), ya que estas pueden limitar opciones futuras de programa. Las dependencias discrecionales pueden también ser llamadas lógica preferida, lógica preferencial, o lógica blanda.

- Dependencias externas: son aquellas que involucran una relación entre las actividades de proyecto con otras que no lo son. Por ejemplo, la actividad de prueba en un proyecto de programas de cómputo, puede depender de la entrega de equipos de una fuente externa, pruebas de impacto ambiental de ruido deben ser hechas antes de hacer las preparaciones en el terreno para iniciar una construcción.

- Restricciones: Las restricciones son factores que van a limitar las opciones del equipo de administración de proyectos; por ejemplo, un presupuesto predefinido es una restricción que muy probablemente limitará las opciones del equipo del proyecto. Cuando un proyecto es ejecutado bajo un contrato, las provisiones contractuales generalmente serán restricciones a esta.

- Suposiciones: Son factores que, para los procesos de planeación, serán consideradas como verdaderas, reales, o ciertas. Por ejemplo, si la fecha en que una persona clave estará disponible es incierta, el equipo puede asumir una fecha de comienzo específica. Las suposiciones generalmente involucran algún grado de riesgo y serán normalmente una salida del proceso de identificación de riesgos.


Herramientas y Técnicas:

- Método de diagrama de precedencia (PDM). Este es un método de construir una red de diagrama de proyecto usando nodos para representar las actividades y conectándolos con flechas que muestran las dependencias. Esta técnica también se llama actividad - sobre - nodo (activity - on - node, AON) y es el método usado por la mayoría de paquetes de software de administración de proyectos. PDM puede ser ejecutado de manera manual o en el computador.

Este incluye cuatro tipos de dependencias o de relaciones de precedencia:

Finalización- a - comienzo - la actividad "de" debe terminar antes de que la actividad "a" pueda comenzar.
Finalización – a- finalización - la actividad "de" debe terminar antes de que la actividad "a" pueda finalizar.
Comienzo- a- comienzo- la actividad "de" debe comenzar antes de que pueda comenzar la actividad "a".
Comienzo- a- finalización- la actividad "de" debe comenzar antes de que la actividad "a" pueda finalizar.

En PDM, la relación finalización – a - comienzo es el tipo de relación lógica más comúnmente usada. Las relaciones comienzo – a - final son raramente usadas, y típicamente solamente por ingenieros programadores profesionales. Usar relaciones comienzo a comienzo, finalización – a - finalización o comienzo a finalización con software de administración de proyectos, puede producir resultados inesperados ya que este tipo de relaciones no han sido implementadas de manera consistente.

- Método de diagramación con flechas (ADM): Este es un método para construir diagramas de red usando flechas para representar las actividades y conectándolas con nodos para mostrar las dependencias. Esta técnica también se llama actividad— sobre — flecha (activity - on – arrow, AOA) y, aunque de menos uso que el PDM, es todavía la técnica preferida en algunas áreas de aplicación. ADM utiliza únicamente dependencias finalización—a—comienzo y puede requerir el uso de actividades ficticias para poder definir todas las relaciones lógicas de manera correcta. Puede ser ejecutado de manera manual o sistematizada.

- Método de diagramación condicional. Las técnicas de diagramación tales como: GERT (técnica de evaluación y repaso gráfica (Graphical Evaluation and Review Techique)) y modelos de Sistemas Dinámicos permiten el uso de actividades no secuenciales tales como loops (por ej., un ensayo que se debe repetir más de una vez) o ramales condicionales (por ej., una actualización de diseño que solo se necesita si la inspección detecta errores). Las técnicas de PDM y ADM no permiten el uso de loops o de ramales condicionales o probabilísticas.

- Patrones de red. Redes estandarizadas pueden ser usadas para acelerar la preparación de diagramas de red de proyectos. Estas pueden incluir un proyecto entero o solamente una porción de este. Porciones de una red, son llamados subredes, o fragmentos de red, estas son especialmente útiles, cuando un proyecto incluye varios componentes idénticos o muy parecidos, tales como pisos en un edificio muy alto, pruebas clínicas en un proyecto de investigación farmacéutica, módulos de programa en un proyecto de programas de computo o la fase de arranque de un programa de desarrollo.

Salidas:

- Diagrama de red del proyecto: es una figura esquemática de las actividades del proyecto y sus relaciones lógicas (dependencias). Un diagrama de red de proyecto puede ser producido manualmente o por computador. Puede incluir los detalles completos de un proyecto o puede tener una o más actividades totalizadoras (hamacas). El diagrama deberá estar acompañado de una descripción que resuma y describa la lógica usada para las secuencias de las actividades. Cualquier secuencia fuera de lo usual deberá estar plenamente descrita. El diagrama de red de proyecto muchas veces se llama incorrectamente diagrama PERT (técnica de evaluación y repaso de programa (Program Evaluation and Review Technique)). Un diagrama Pert es un tipo de diagrama de red proyectos que se usa muy poco hoy en día.

- Actualización a la lista de actividades: De la misma manera en que el proceso de definición de actividades puede generar actualizaciones al DET, la preparación de la red de diagrama de proyecto puede revelar instancias en las que una actividad deberá ser dividida o de otra manera redefinida de manera que se pueda diagramar la relación de lógica correcta.

* Estimación de la duración de las actividades: Consiste en estimar el tipo y las cantidades de recursos necesarios para realizar cada actividad.

Entradas:

- Lista de Actividades: La lista de actividades debe incluir todas las actividades que serán ejecutadas en el proyecto. Deberá ser organizada como una extensión del DET para ayudar a asegurar que está completo y que no incluye actividades que no son requeridas como parte del alcance del proyecto. Así como con el DET; la lista de actividades debe incluir descripciones de cada actividad para asegurar que los miembros del equipo del proyecto entenderán como se deberá de ejecutar el trabajo.

- Restricciones: Las restricciones son factores que van a limitar las opciones del equipo del proyecto.

- Suposiciones: Las suposiciones son factores que, para los procesos de planeación, serán consideradas como verdaderas, reales, o ciertas. Las suposiciones generalmente involucran algún grado de riesgo y serán normalmente una salida del proceso de identificación de riesgos.

- Requerimientos de recursos: La duración de la mayoría de las actividades se verá influenciada significativamente por los recursos asignada a ella. Por ejemplo, dos personas trabajando juntas serán capaces de completar una actividad de diseño en la mitad del tiempo que le tomaría a cada uno individualmente realizar la tarea, mientras que una persona trabajando medio tiempo en la actividad tomará generalmente el doble del tiempo que la misma persona trabajando tiempo completo.

- Capacidades de recursos: La evaluación de la mayoría de las actividades se verá influenciada significativamente por las capacidades de los recursos humanos y materiales asignados a ella. Por ejemplo, si dos miembros de un equipo son asignados a una actividad de tiempo completo es de suponer que el miembro más experimentado la terminará en menor tiempo

- Información histórica: La información histórica de la duración más probable de muchas categorías de actividades, está muchas veces disponible de una o de más de las siguientes fuentes:

• Archivos de proyecto: una o más de las organizaciones involucradas en el proyecto puede mantener registros de resultados de proyectos previos que sean lo suficientemente detallados para ayudar en el desarrollo de los estimativos de duración. En algunas áreas de aplicación, individuos del equipo de trabajo pueden mantener tales registros.
• Bases de datos de estimación comerciales: mucha información histórica está disponible comercialmente. Estas bases de datos tienden a ser especialmente útiles cuando las duraciones no son función del contenido de trabajo real (por ej., cuanto tiempo se demora el concreto para curar; generalmente cuanto se demora un agente gubernamental para responder a ciertas requisiciones).
• Conocimiento del equipo de proyecto: los miembros individuales del equipo del proyecto pueden recordar estimativos actuales o previos. Mientras que tales recolecciones puedan ser útiles, son generalmente menos fiables que resultados documentados.

Herramientas y Técnicas:

- Opinión experta. : Las duraciones son muchas veces difíciles de estimar porque hay un número de factores que las pueden influenciar (por ej., niveles de recursos, productividad de los recursos). La opinión experta guiada por información histórica deberá ser usada cuando sea posible. Si tal experiencia no esta disponible, los estimativos son inherentemente inciertos y riesgosos.

- Estimación análoga: La estimación análoga, también llamada estimación de arriba—hacia abajo, precisa usar duraciones reales de una actividad previa y similar como base para la estimación de la duración futura de una actividad. Es usada frecuentemente para estimar la duración de proyectos cuando hay una cantidad limitada de proyecto (por ej., como en sus fases iníciales), la estimación análoga es una forma de opinión experta. La estimación análoga es más fiable cuando (a) la actividad previa es similar de hecho y no solo en apariencia, y (b) cuando los individuos preparando los estimativos tienen la experiencia necesaria.

- Simulación: La simulación involucra calcular múltiples duraciones con diferentes juegos de suposiciones. La más común es Análisis de Monte Carlo en la que una distribución de posibles resultados es definida para cada actividad y es a su vez usada para calcular la distribución de posibles resultados para todo el proyecto.

Salidas:

- Estimación de la duración de la actividad: Son evaluaciones cuantitativas del número de períodos de trabajo más probable que se requerirá para completar una actividad. La estimación de la duración de las actividades siempre deberá incluir alguna indicación del rango de posibles resultados.

Por ejemplo:
2 semanas ±2 días para indicar que la actividad tomará por lo menos 8 días pero no más de 12.
15% de probabilidad de exceder 3 semanas para indicar una alta probabilidad - 85% -de que la actividad tomará 3 semanas o menos.

- Bases de estimación: Las suposiciones hechas en el desarrollo de los estimativos deberán estar documentados.

- Actualizaciones a la lista de actividades: De la misma manera en que el proceso de definición de actividades puede generar actualizaciones al DET, la preparación de la red de diagrama de proyecto puede revelar instancias en las que una actividad deberá ser dividida o de otra manera redefinida de manera que se pueda diagramar la relación de lógica correcta.

* Desarrollo de la programación:

Consiste en analizar las secuencias de las actividades, las duraciones de las actividades, y los requerimientos de recursos para crear la programación del proyecto.

Entradas:

- Diagrama de red del proyecto: es una figura esquemática de las actividades del proyecto y sus relaciones lógicas (dependencias). Un diagrama de red de proyecto puede ser producido manualmente o por computador. Puede incluir los detalles completos de un proyecto o puede tener una o más actividades totalizadoras (hamacas). El diagrama deberá estar acompañado de una descripción que resuma y describa la lógica usada para las secuencias de las actividades. Cualquier secuencia fuera de lo usual deberá estar plenamente descrita. El diagrama de red de proyecto muchas veces se llama incorrectamente diagrama PERT (técnica de evaluación y repaso de programa (Program Evaluation and Review Technique)). Un diagrama Pert es un tipo de diagrama de red proyectos que se usa muy poco hoy en día.

- Estimación de la duración de las actividades: Estimación de la duración de la actividad: Son evaluaciones cuantitativas del número de períodos de trabajo más probable que se requerirá para completar una actividad. La estimación de la duración de las actividades siempre deberá incluir alguna indicación del rango de posibles resultados.

Por ejemplo:
2 semanas ±2 días para indicar que la actividad tomará por lo menos 8 días pero no más de 12.
15% de probabilidad de exceder 3 semanas para indicar una alta probabilidad - 85% -de que la actividad tomará 3 semanas o menos.

- Requerimientos de recursos: La duración de la mayoría de las actividades se verá influenciada significativamente por los recursos asignada a ella. Por ejemplo, dos personas trabajando juntas serán capaces de completar una actividad de diseño en la mitad del tiempo que le tomaría a cada uno individualmente realizar la tarea, mientras que una persona trabajando medio tiempo en la actividad tomará generalmente el doble del tiempo que la misma persona trabajando tiempo completo.

- Descripción del pool de recursos: El conocimiento de que recursos estarán disponibles en que tiempos y en que patrones es necesario para el desarrollo de la programación. Por ejemplo, los recursos compartidos podrán ser especialmente difíciles de programar ya que su disponibilidad puede ser altamente variable. El grado de detalle y el nivel de especificidad en la descripción del pool de recursos puede variar. Por ejemplo, para el desarrollar preliminar de la programación de un proyecto de consultoría, uno solo necesita saber que dos consultores estarán disponibles en un marco de tiempo específico. La programación final del mismo proyecto sin embargo, debe identificar que consultores específicos estarán disponibles.

- Calendarios: Los calendarios de proyecto y de recursos identifican períodos de tiempo donde es permitido trabajar. Los calendarios de proyecto afectan a todos los recursos (por ej., algunos proyectos solo trabajaran durante horas normales de negocio, mientras que otros trabajaran tres turnos diariamente). Los calendarios de recursos afectan a un recurso o categoría de recurso en particular (por ej., un miembro del equipo de proyecto puede estar de vacaciones o en un curso de capacitación, un contrato colectivo de trabajo puede limitar la labor de algunos empleados durante la semana).

- Restricciones. Son factores que van a limitar las opciones de los miembros del equipo de administración de proyecto. Hay dos categorías principales de restricción de tiempo, consideradas durante el desarrollo del programa:
Fechas impuestas. La entrega de ciertos productos en una fecha específica puede ser requerida por un patrocinador del proyecto, el cliente del proyecto, u otros factores externos (por ej., una ventana de mercadeo en un proyecto tecnológico, una fecha impuesta judicialmente en un proyecto de remedición ambiental).

Eventos claves o hitos de importancia: La entrega de ciertos productos en una fecha específica puede ser solicitada por un patrocinador del proyecto, el cliente de proyecto, u otros partidos interesados. Una vez programados, estas fechas se vuelven formales, y muchas veces sólo se pueden cambiar con gran dificultad.

- Suposiciones: Las suposiciones son factores que, para los procesos de planeación, serán consideradas como verdaderas, reales, o ciertas. Las suposiciones generalmente involucran algún grado de riesgo y serán normalmente una salida del proceso de identificación de riesgos.

- Holguras y tiempos de espera: Cualquiera de las dependencias puede requerir de una holgura o tiempo de espera (lags y leads) para poder definir de manera correcta la relación (por ej., puede existir un retraso de dos semanas entre la compra de un equipo y su instalación para su uso).

Herramientas y Técnicas:

- Análisis matemático: El análisis matemático requiere calcular las fechas teóricas tempranas y tardías para todas las actividades sin tener en cuenta cualquier limitación del pool de recursos disponibles. Las fechas resultantes no son la programación, sino que mas bien indican los periodos de tiempo en los que las actividades se deberían programar dadas las limitaciones de recursos y de otros tipos conocidas. Las técnicas más comunes conocidas son:

• Método de la Ruta Crítica (CPM): calcula un solo juego determinístico de fechas tempranas y tardías de comienzo y finalización para cada actividad, basada en una lógica de red secuencial y solo una duración. El foco de CPM es calcular la flotación para poder determinar que actividades tienen la menor flexibilidad de programación. Los algoritmos inherentes a CPM son muchas veces usados en otros tipos de análisis matemáticos.
• Método de Evaluación y Revisión Gráfica (GERT): permite el tratamiento probabilístico de tanto la red de lógica como de la estimación de las duraciones de las actividades (por ej., algunas actividades pueden no ser ejecutadas, algunas pueden ser ejecutadas algunas veces, y otras pueden ser ejecutadas varias veces).
• Técnica de Evaluación y Revisión de Programas (PERT): usa lógica secuencial de red y una distribución por pesos para la duración de las actividades para calcular la duración del proyecto. Aunque existen algunas diferencias superficiales, PERT se diferencia de CPM en que PERT usa la media de la distribución (el valor esperado) en lugar del el valor más probable usado originalmente en CPM. PERT se usa poco hoy día aunque muchas veces se usan estimados que se asemejan a PERT en cálculos de CPM.

- Compresión de duraciones: La compresión de duraciones es un caso especial de análisis matemático que busca maneras de acortar la duración del proyecto sin cambiar el alcance de este (por ej., cumplir fechas impuestas o metas de programación). La compresión de duraciones incluye técnicas tales como:

· Explosión (Crashing): el canje entre los costos y la programación son analizados para determinar el mayor grado de compresión a cambio del menor aumento posible en los costos. El crashing no siempre produce alternativas viables y muchas veces resulta en costos incrementados.

· Paso veloz (Fast Tracking): es realizar actividades en paralelo que normalmente se ejecutarían en secuencia (por ej., comenzar a escribir código en un proyecto de software antes de que su diseño haya terminado, o comenzar la construcción de los cimientos para una planta de procesamiento de petróleos antes de que sus ingenierías lleguen al 25%). El fast tracking muchas veces resulta en trabajos que hay que repetir, y aumenta de manera desproporcionada el riesgo asociado con el proyecto.

- Simulaciones: La simulación involucra calcular múltiples duraciones con diferentes juegos de suposiciones. La más común es Análisis de Monte Carlo en la que una distribución de posibles resultados es definida para cada actividad y es a su vez usada para calcular la distribución de posibles resultados para todo el proyecto.

- Heurísticas de nivelación de recursos: El análisis matemático muchas veces produce una programación preliminar que requiere más recursos durante ciertos periodos de tiempo de los que hay disponibles, o que requiere cambios en los niveles de recursos que no son manejables. Una heurística como "asignar recursos críticos escasos a actividades de la ruta critica primero" puede ser aplicada para desarrollar una programación que refleje tales restricciones. La nivelación de recursos muchas veces resulta en una programación que es mas larga en duración que la programación preliminar. Esta técnica es a veces llamada el "método basado en recursos", especialmente cuando se implementa con optimización por computador. La programación con base en restricciones de recursos es un caso especial de nivelación de recursos en donde la heurística involucrada es una limitación en la cantidad de recurso disponible.

- Software de administración de proyectos: es de uso común para asistir en el desarrollo de la programación del proyecto. Estos productos automatizan él cálculo del análisis matemático y de la nivelación de recursos, y por lo tanto permiten una consideración rápida de las muchas alternativas de programación. También son de uso común para la impresión y presentación del desarrollo de la programación del proyecto.

Salidas:

- Programación del proyecto: La programación del proyecto incluye al menos fechas de inicio y de terminación planeadas para cada detalle de actividad. (Nota: El cronograma de proyecto permanecerá preliminar hasta que las asignaciones de recursos hayan sido confirmadas. Esto sucederá de manera habitual no mas tarde que a la terminación del Plan de Desarrollo del Proyecto). El cronograma de proyecto puede ser presentado de forma resumida (la "programación maestra") o en forma detallada.

Aunque puede ser presentado en forma tabular, suele presentarse generalmente de forma gráfica usando uno o más de los formatos presentados a continuación:

• Diagramas de red de proyecto: Estas gráficas muestran usualmente tanto la lógica del proyecto como las actividades de su ruta crítica.
• Gráficas de barras: que también se conocen como diagramas de Gant , muestran tanto las fechas de comienzo como de terminación de las actividades y sus duraciones esperadas, pero no muestran sus dependencias. Son fáciles de leer, y son de uso frecuente en presentaciones ejecutivas.
• Gráficas de hitos o mojones: son similares a las gráficas de barras, pero identifican los comienzos o terminaciones programadas de las principales entregas e interfaces externas claves del proyecto.
• Diagramas de red de proyectos en escalas de tiempo: son una mezcla de los diagramas de red del proyecto y de los diagramas de barras de una manera tal que muestran la lógica del proyecto, las duraciones de las actividades, y la información de la programación.

- Detalle de soporte: El detalle de soporte para la programación del proyecto incluye al menos documentación de todas las restricciones y suposiciones identificadas. El grado de detalle adicional requerido varía de acuerdo al área de aplicación.

Por ejemplo:
En un proyecto de construcción, probablemente incluirá ítems tales como histogramas de recursos, proyecciones del flujo de caja, y programaciones de ordenas de compra y entregas.
En un proyecto electrónico, probablemente solo incluirá histogramas de recursos.
Información que frecuentemente se incluye como detalle de soporte contiene, pero no se limita a:
Requerimientos de recursos por unidad de tiempo, muchas veces en la forma de un histograma de recursos.
Programaciones alternativas (por ej., mejor caso o peor caso, recursos con o sin nivelar, y con o sin fechas impuestas).
Reservas de la programación, o cuantificaciones de riesgo.

- Plan de manejo de la programación: Un plan de manejo de la programación define como se manejaran los cambios a la programación. Puede ser formal o informal, con gran grado de detalle o basado de forma conceptual amplia dependiendo de las necesidades del proyecto. Es un elemento subsidiario del plan general del proyecto.

- Actualizaciones a los requerimientos de recursos. Las nivelaciones de recursos y actualizaciones a la lista de actividades pueden tener un efecto significativo sobre las estimaciones preliminares de los requerimientos de recursos.

* Control de la programación: Consiste en controlar los cambios a la programación del proyecto.

Entrada:

- Programación del proyecto: La programación del proyecto incluye al menos fechas de inicio y de terminación planeadas para cada detalle de actividad. (Nota: El cronograma de proyecto permanecerá preliminar hasta que las asignaciones de recursos hayan sido confirmadas. Esto sucederá de manera habitual no mas tarde que a la terminación del Plan de Desarrollo del Proyecto). El cronograma de proyecto puede ser presentado de forma resumida (la "programación maestra") o en forma detallado. La programación de proyecto aprobada, se conoce también como la línea de base, y es un componente de plan general del proyecto; provee la base para la medición y reporte del desempeño de la programación.

- Reportes de desempeño: Es colectar y diseminar información de desempeño. Esto incluye reporte de status, medición de avance, y pronósticos, proveen información sobre el desempeño de la programación de manera tal que se muestra que fechas programadas se han cumplido y cuales no. Los reportes de desempeño pueden también alertar al equipo de proyecto a temas que pueden causar problemas en el futuro.

- Requisiciones de cambio: Las requisiciones de cambio pueden ocurrir de muchas maneras; de forma oral o escrita, de manera directa o indirecta, iniciadas de manera interna o externa, por mandato legal o por opción propia. Estos cambios pueden requerir extender el plazo programado o pueden permitir acelerarlo.

- Plan de manejo de la programación: Un plan de manejo de la programación define como se manejaran los cambios a la programación. Puede ser formal o informal, con gran grado de detalle o basado de forma conceptual amplia dependiendo de las necesidades del proyecto. Es un elemento subsidiario del plan general del proyecto.

Herramientas y Técnicas:

- Sistema de control de cambios a la programación: define los procedimientos por medio de los cuales la programación del proyecto puede ser cambiada. Este incluye el papeleo, el sistema de seguimiento (tracking), y los niveles de aprobación necesarios para autorizar tales cambios. El sistema de control a la programación deberá estar integrado de manera íntima con el sistema general de control de cambios.

- Medición de desempeño: Las técnicas de medición del desempeño ayudan a cuantificar la magnitud de cualquier variación que ocurra. Una parte importante del control de la programación es decidir si la varianza de programación requiere acción correctiva. Por ejemplo, una demora considerable en una actividad no crítica puede tener poco efecto sobre el proyecto en general, mientras que un pequeño atraso en una actividad crítica o casi crítica puede requerir acción inmediata.

- Planeación adicional: Muy pocos proyectos se desarrollan exactamente de acuerdo a su plan. Cambios prospectivos pueden requerir nuevas o revisadas duraciones de actividades, secuencias de actividades modificadas, o análisis de programaciones alternas.

- Software de administración de proyectos: La habilidad del software de administración de proyectos de hacer un seguimiento de fechas programadas versus fechas reales y de pronosticar los efectos de los cambios de programación, reales o potenciales, hacen de esta herramienta un recurso útil para el control de la programación.

Salidas:

- Actualizaciones a la programación. Una actualización de programación es cualquier cambio en la información que se usa para administrar el proyecto. Los partidos interesados apropiados deberán ser notificados como sea necesario. Las actualizaciones a la programación pueden o no requerir de ajustes en otros aspectos en el plan general de proyecto. Las revisiones son una categoría especial de actualizaciones de la programación. Las revisiones son cambios a las fechas programadas de inicio y finalización en la programación de proyecto aprobada. Estas fechas solo son revisadas generalmente en respuesta a cambios en el alcance. En algunos casos, las demoras en la programación pueden ser tan severas que hay volver a calcular la línea de base, de manera que se puedan proveer datos realistas para la medición de desempeño.

- Acción correctiva: es cualquier cosa que se haga para hacer que el desempeño futuro del proyecto se ajuste a lo esperado en la línea de base del plan del proyecto. La acción correctiva en el campo de la administración del tiempo muchas veces requiere expeditar: acción especial que se toma para asegurar la terminación de una actividad a tiempo o con el menor retraso posible.

- Lecciones aprendidas: Las causas de varianza, el razonamiento detrás de las acciones correctivas escogidas, y otros tipos de lecciones aprendidas del control de la programación, deberán ser documentadas para poder que sean parte de las bases de datos históricas, tanto para este proyecto como para otros proyectos de la organización ejecutora.