Saltar al contenido

Programaci贸n de las fechas de las tareas importantes del proyecto no contractuales

Aquí veremos cómo implementar una fecha de inicio de tarea no contractual específica sin la inserción de una restricción de tarea. Algunas directrices de programación especifican que todas las restricciones deben definirse por contrato, por ejemplo, una fecha de finalización del contrato. Esto limita significativamente la aplicación de restricciones en un horario. Pero, ¿qué hace un programador cuando el director del proyecto solicita una fecha específica de movilización (generalmente una fecha no contractual importante en la vida de un proyecto)?

La mayoría de las directrices de programación no prohíben absolutamente el uso de restricciones de tareas, pero generalmente desalientan su uso generalizado. Algunas directrices dicen, una vez más, por ejemplo, que todas las limitaciones deben definirse contractualmente. Como se mencionó anteriormente, esto limita significativamente el uso de restricciones en un horario. El problema con las restricciones es doble:

  1. Es posible que pierda su camino crítico continuo o el más largo.
  2. Hacen que el horario sea estático. Las programaciones estáticas, es decir, las programaciones con muchas limitaciones de tareas, no responderán bien a los cambios en la situación del proyecto.

El objetivo es una programación dinámica que actualice automáticamente las fechas de inicio y fin de las tareas en función de los cambios en las estimaciones de la duración de las tareas y las relaciones entre ellas. Lo que queremos considerar hoy es si existe un trabajo en torno al cual se establezca la fecha de movilización, según la petición del director del proyecto, pero se evite la aplicación de una restricción.

Este artículo examina cómo implementar una fecha de inicio de tarea no contractual específica sin la inserción de una restricción de tarea. Los programas de notas de este blog fueron creados en Primavera P6 Professional.

A veces parece que las pautas de programación obstaculizan la verdadera narrativa de la situación de programación. ¿Por qué prohibir o limitar la utilización de restricciones, si una restricción puede ayudar a expresar la verdadera descripción de los eventos del programa? Pero como hemos visto anteriormente, las restricciones tienen sus aspectos negativos:

  1. Su camino crítico o el más largo puede desarticularse.
  2. Algunas partes de su horario pueden volverse estáticas.

Por lo tanto, es preferible evitar, en la medida de lo posible, la inserción de restricciones. Por lo tanto, queremos examinar los entornos de trabajo para situaciones en las que podamos estar tentados a recurrir a una restricción de tareas.

En la Figura 1 tenemos nuestro proyecto de demostración.

Figura 1

Este es un programa típico para un contrato del gobierno. Obsérvese, en particular, la diferencia entre la “fecha prevista de finalización” del 10 de abril de 2017 y la “fecha de finalización del contrato” del 22 de mayo de 2017. Debido a este tiempo de amortiguación entre la “fecha de finalización prevista” y la “fecha de finalización del contrato”, el director del proyecto puede retrasar el inicio de la construcción o “movilizar el equipo” unos días y no tener un impacto negativo en la finalización del proyecto. En la actualidad, “movilizar equipos” comienza el 7 de febrero de 2017. El director del proyecto desea aplazar la “movilización de equipos” hasta el 20 de febrero de 2017.

Por lo tanto, la construcción o “movilización de equipo” está programada para comenzar el 7 de febrero de 2017, pero el director del proyecto solicita una fecha de inicio de “movilización de equipo” del 20 de febrero de 2017. El tema que se está debatiendo es cómo definir la fecha de inicio de “movilización de equipos” del 20 de febrero de 2017. La lógica natural del calendario comienza la movilización el 7 de febrero de 2017, pero tenemos que retrasar la movilización hasta el 20 de febrero de 2017. Esto se logra fácilmente aplicando una restricción de `empezar con o después$0027 a `movilizar el equipo$0027, Figura 2.

Figura 2

Sin embargo, al insertar esta restricción incurrimos en nuestros dos problemas de restricción:

  1. Pierdes tu camino crítico continuo o el más largo.
  2. Su horario se vuelve estático.

¡No es bueno! Como se muestra en la Figura 2, perdemos nuestro camino más largo y continuo al insertar una restricción de “Comenzar o Terminar” en “Movilizar equipo”.

¿Qué es lo que hacemos? ¿Forzamos al gerente de proyecto a comenzar a “movilizar el equipo” antes de lo deseado? ¿O hay un trabajo alternativo? Hay un trabajo recomendado en torno a cuestiones menos inherentes. El trabajo consiste en extender la duración de los$0027Presentaciones de Revisión/Aprobación de la Gobernación$0027 hasta que se inicie la$0027movilización de equipo$0027 el 20 de febrero de 2017, Figura 3.

Figura 3

Por lo tanto, cambie la duración original de los “Envíos de Revisión/Aprobación de la Gobernación” de 10 días a 19 días. Los puristas pueden quejarse de que el gobierno sólo necesita 10 días para revisar las presentaciones. La realidad es que el gobierno puede tomar 19 días para revisar las presentaciones sin afectar negativamente el calendario. Si usted informa al gobierno que tienen tiempo adicional o no es su discreción.

Este trabajo sólo se convierte en un problema si se actualiza el progreso del programa semanalmente. Si es así, entonces$0027Presentaciones de Revisión/Aprobación de la Gobernación$0027 pueden terminar antes de lo programado y la pregunta es ¿por qué no empiezas a$0027movilizar el equipo$0027? Los aspectos positivos, sin embargo, son:

  1. Mantén tu camino más largo y continuo.
  2. Su horario sigue siendo dinámico.

Resumen

La programación se convierte en una situación delicada de compensaciones cuando se le pide que especifique una fecha de inicio de tarea que no coincida con la lógica natural de la programación. En estas situaciones, los programadores pueden verse tentados a insertar una restricción de tarea para restringir la programación a una fecha de inicio de tarea deseada.

Sin embargo, las directrices de programación suelen desalentar el uso generalizado de las restricciones. También es preferible encontrar otro enfoque para mantener un camino más largo y continuo y un calendario dinámico. Sin embargo, el compromiso puede ser tan simple como ampliar la duración original de una actividad anterior. Las instantáneas del progreso de períodos más cortos, quizás semanales, pueden tener problemas para narrar el progreso del programa cuando la tarea extendida se completa antes de lo programado.

Los aspectos positivos de este compromiso, sin embargo, son convincentes. Debemos decir para que conste que si hubiéramos modificado la relación de fin a comienzo (FS) entre `reunión previa a la construcción$0027 y `movilizar el equipo$0027 añadiendo una cantidad de tiempo para llenar el vacío de tiempo habríamos podido mantener nuestro camino más largo y tener la restricción de `movilizar el equipo$0027. Sin embargo, las directrices suelen decir que a todas las relaciones fin-inicio se les debe asignar un desfase de 0, por lo que su uso de desfase está restringido.

También puede estar interesado en nuestro artículo Programación de los Conundrums de Mejores Prácticas.