Un cronograma de proyecto correctamente desarrollado es una obra de arte, pero uno mal creado puede ser una fuente de frustración para el equipo de proyecto y un riesgo para el éxito general del proyecto. Desarrollar un cronograma antes de dedicar tiempo a descomponer el alcance de un proyecto es probablemente el principal error de la mayoría de los planificadores deficientes, pero le sigue de cerca el uso incorrecto de dependencias, restricciones y fechas límite en el cronograma.
Las dependencias de cronograma representan una conexión lógica entre dos actividades discretas. Estas relaciones deben estar relacionadas con la naturaleza de las actividades mismas y NO con quién realizará las tareas u otras restricciones similares. Las dependencias más comúnmente proporcionadas incluyen:
- Finalizar para comenzar: la relación causal más común, por lo que no se necesita explicación para su uso.
- Comenzar para finalizar: rara vez se utiliza, pero es útil al desarrollar un cronograma hacia atrás desde una fecha de finalización fija.
- Comenzar para comenzar: esto representa una verdadera relación entre dos actividades y no tiene nada que ver con sus predecesoras. Si tengo dos tareas que comienzan al mismo tiempo debido a un predecesor, eso se representa mejor como dos relaciones de finalizar para comenzar (por ejemplo, las pruebas de sistemas y el desarrollo de documentación pueden comenzar una vez que se complete el desarrollo, pero no hay relación entre las pruebas de sistemas y el desarrollo de documentación, por lo que no queremos usar una dependencia de comenzar para comenzar aquí). Esta dependencia se usa a menudo con un retraso para representar la conexión entre dos actividades que se ejecutan en paralelo pero que no pueden comenzar exactamente al mismo tiempo (por ejemplo, aplicar la primera capa de pintura y aplicar la segunda capa de pintura). Un ejemplo real de comenzar para comenzar es una carrera entre dos corredores donde cada corredor se representa como una actividad separada: aunque es probable que terminen en diferentes momentos, ambos deben comenzar exactamente al mismo tiempo.
- Finalizar para finalizar: generalmente se utiliza para representar actividades que deben completarse al mismo tiempo para no afectar a sus actividades sucesoras o a uno o más de los objetivos del proyecto. Un ejemplo no relacionado con proyectos de esto es la preparación de alimentos en un restaurante: los chefs deben asegurarse de que el plato principal y los adornos estén listos exactamente al mismo tiempo para que se pueda hacer el emplatado sin afectar la calidad.
Las restricciones representan una limitación del mundo real que impide que una actividad comience o termine cuando normalmente lo haría (según la fecha de inicio del proyecto o sus dependencias). Las restricciones a menudo se utilizan incorrectamente, ya que la inclinación natural de un planificador novato es establecer manualmente las fechas de inicio o finalización de las tareas. Ejemplos válidos de restricciones incluyen dependencias de recursos (por ejemplo, la falta de disponibilidad de una sala de capacitación) o factores externos (por ejemplo, períodos de apagón de mantenimiento que afectarían ciertos tipos de tareas). Los calendarios de recursos o tareas, si son compatibles con un motor de programación, proporcionan una alternativa al uso de restricciones. Sin embargo, con cualquiera de estas características, es una buena idea documentar la condición específica que justificó el uso de la restricción o el calendario para que, si la condición ya no se aplica en un momento posterior, se pueda eliminar la restricción, lo que podría mejorar el rendimiento del cronograma.
Las restricciones se utilizan ocasionalmente (especialmente “finalizar en” o “finalizar a más tardar”) donde una fecha límite funcionaría mejor. Mientras que las dependencias y restricciones afectan la lógica de programación y las fechas de inicio o finalización de las tareas, las fechas límite proporcionan un indicador visual al planificador de que es probable que se pierda una fecha límite “real”. En cronogramas grandes, puede haber numerosos hitos, pero solo puede haber algunas fechas límite reales que deben cumplirse. Para asegurarse de que el planificador esté consciente de las posibles consecuencias negativas de un cambio en la programación, las fechas límite proporcionan un medio “suave” de notificación que no impedirá que las tareas se muevan libremente o que el cronograma se optimice.
A veces se omiten los retrasos a favor de tareas artificiales que se insertan entre dos actividades dependientes. Por ejemplo, una vez que he realizado un pedido a mi proveedor, pasará un período de tiempo hasta que se entregue el equipo. Utilizar una tarea para representar este tiempo de adquisición y entrega es incorrecto a menos que la actividad la realice el equipo de proyecto y, además, esto desequilibrará el cálculo del porcentaje completo del proyecto en general. Un enfoque mejor es introducir un retraso entre las dos actividades que represente el número esperado de días o semanas para la actividad de adquisición y entrega.
Aunque no he intentado proporcionar una guía completa para cada una de estas características, espero que aclare su uso de manera que se pueda utilizar la herramienta adecuada para el trabajo correcto.
Kiron D. Bondale (PMP) es el Gerente de Servicios al Cliente de Solution Q Inc., que produce e implementa soluciones de gestión de cartera de proyectos. Kiron ha gestionado múltiples proyectos de TI de tamaño mediano a grande y ha trabajado durante más de doce años en capacidades de gestión de proyectos internos y de servicios profesionales. Ha establecido y gestionado Oficinas de Gestión de Proyectos (PMO) y ha brindado servicios de consultoría en gestión de cartera de proyectos a clientes de diversas industrias. Kiron participa activamente en el Project Management Institute (PMI) y se desempeñó como director voluntario en la Junta del Capítulo PMI Lakeshore de 2003 a 2009. Kiron ha publicado artículos sobre gestión de proyectos en varias publicaciones de la industria y ha presentado temas de GCP/GP en múltiples conferencias y webinars. Para obtener más pensamientos de Kiron sobre gestión de proyectos, visite su blog en http://solutionq.wordpress.com/.
