Crashing y el Fast Tracking

 Crashing y el Fast Tracking

 El Crashing consiste en asignar más recursos a las tareas, si un recurso tarda 8 horas en realizar una tarea, ¿cuanto tardarán 2 recursos? si los proyectos fuesen como las matemáticas la respuesta sería 4, pero no siempre es así, depende del tipo de tarea que sea y de los recursos que estemos utilizando, imaginar que solo disponemos de un PC con un determinado software para realizar una tarea, aunque tengamos dos personas que sepan utilizar ese software, no podemos asignar dos personas a esa tarea ya que estamos limitados por el PC+Software.

 El Fast Tracking consiste en la paralelización de tareas, es decir tareas que inicialmente eran secuenciales, pasan a realizarse en paralelo, de esta forma se comprime la planificación. El Fast Tracking conlleva un riesgo ya que estamos adelantando tareas que no debería comenzar antes de que finalizasen otras, si es necesario acelerar fechas no tendremos más remedio que sumir el riesgo.

 A la hora de acelerar el cronograma debemos aplicar mucho sentido común y tener en cuenta la limitación de los recursos. Las planificaciones lo aguantan todo, la ejecución ya es otra cosa...

 Los recursos adicionales pueden provenir de dentro del equipo del proyecto, o pueden ser contratados temporalmente fuera del equipo. Uno de los objetivos del “crashing” es reducir al mínimo el costo incremental. En la teoría se ven los ejemplos clásicos de cómo acortar la duración de un cronograma haciendo crashing sobre las actividades menos costosas del camino crítico. Sin embargo, a cambio de completar el trabajo antes de lo previsto, el crashing conduce siempre a costos incrementales adicionales al proyecto. Si el proyecto lo puede aceptar o puede ser trasladado al cliente, el crashing es una opción muy viable.

A comparación del Fast-Tracking sólo es posible si las actividades a colocar en paralelo pueden ser solapadas (técnica o lógicamente), en el caso de Crashing es necesario tener en cuenta la ley de recursos decrecientes o Ley de Brooks donde no siempre agregar recursos a una tarea atrasada hace que está pueda ser acortada.

Cualquier persona con cierta experiencia en manejo de proyectos sabe que existen una variedad de factores que pueden mover la fecha límite del mismo. No es raro encontrarnos que algunas de las actividades son más difíciles de lo que habíamos previsto, o que es necesario poner recursos más experimentados en alguna tarea. Muchas veces descubrimos que las tareas fueron mal estimadas. Como Project Manager, si usted descubre que existe un retraso en el cronograma que puede poner en riesgo la fecha límite, su primera obligación es tratar de determinar la causa. Si se empeña en buscar “remedios” para paliar rápidamente el problema sin saber la causa, la situación probablemente se repetirá. La segunda obligación es tratar de hacer las correcciones necesarias para que el proyecto vuelva a su curso normal, utilizando las técnicas más apropiadas, pero tenga en cuenta que hacia el final del proyecto, las opciones se van reduciendo.