¿Cómo responder productivamente a arriesgar en un proyecto de gestión de operaciones

En respuesta a los riesgos cuando se producen es una de las grandes pruebas de un gerente de proyecto operaciones. Esto es particularmente complicada por de tres " leyes Nº 148; que el trabajo en contra de completar de manera eficiente el proyecto. Una ley, la ley de Parkinson, se aplica a los tiempos cuando las cosas van bien. Los otros dos, la ley de Brook y el derecho de Homero, que patear cuando ya estás abajo.

Mantenga su productividad: la ley de Parkinson

Cyril Northcote Parkinson observó en 1955 que " El trabajo se expande para llenar el tiempo disponible para su finalización ". Basó esta observación en años de trabajo con la administración pública, sin embargo, los ingenieros y programadores a menudo acusado de " de oro chapado " o " sobre-ingeniería " (estos son los dos términos que significan que los ingenieros han desarrollado el proyecto mucho más allá de lo que el cliente requiere o se preocupa) cuando se deja con el exceso de tiempo.

Sin embargo, apretando plazos demasiado para evitar " sobrerregulación " también puede ser contraproducente. Las investigaciones muestran consistentemente que los empleados, cuando se enfrentan a plazos claramente poco realistas, simplemente renuncian a tratar de reunirse con ellos y avanzar muy lentamente.

El mejor método para evitar la ley de Parkinson sin conducir a los empleados a la desesperación es establecer líneas de tiempo moderadamente agresivos.

Recuperarse de los retrasos: la ley de Brook y el derecho de Homero

Cuando un proyecto se enmarca tarde, conseguir el proyecto de nuevo en marcha es sorprendentemente difícil. Por lo general, los administradores recurren a uno de los cuatro métodos:

• Adición de recursos (por lo general, los empleados adicionales)

• Los empleados que trabajan horas extras

• Retrasar el proyecto

• La reducción del alcance del proyecto

Los dos primeros métodos son a la vez problemático, debido al ciclo de retrabajo. La investigación también muestra que la reanudación - trabajo que usted pensaba que era completa, pero resulta ser defectuoso y necesita ser renovado - es una gran parte de todos los proyectos. Retrabajo es frecuente en todos los proyectos de construcción de aeropuertos, a las casas de remodelación, con el desarrollo de nuevos servicios, a la escritura de software.

En cualquier proyecto, hay una serie de tareas para completar. los tareas pendientes en el proyecto se han completado por personal un bronceado tasa de finalización de la tarea aparente. Algunos de estos son de hecho realmente completado. Sin embargo, muchos de ellos sólo aparecen completó. En realidad, se convierten retrabajo sin descubrir, el cual tendrá que ser hecho de nuevo. A medida que se descubrió este retrabajo, aumenta la tareas pendientes esa necesidad de ser completada.

El ciclo de retrabajo interfiere con la finalización del proyecto debido a la adición de sólo el personal aumenta el personal de efectivos después de un retraso ya que los nuevos empleados a aprender lo suficiente sobre el proyecto para ser útil. Sin embargo, en el corto plazo, hasta que los nuevos empleados llegan a la velocidad, la experiencia promedio de personal se reduce (por lo menos en este proyecto). Esto aumenta la tasa de error, lo que eleva la reanudación sin descubrir, retrasando así el proyecto.

La ley de Brook

Adición de los trabajadores a un proyecto final de su ciclo de vida generalmente resulta en errores y retrasos. Esta es la razón detrás de la ley de Brook, que es " la adición de los trabajadores a un proyecto a finales hace que sea aún más adelante ". La implicación es que si usted necesita agregar recursos, entonces usted realmente necesita para hacerlo antes de que realmente los necesita con el fin de entrenar correctamente y prepararlos para ayudar.

Esto también significa que usted tendrá que vigilar con vigor su proyecto de modo que usted puede agregar recursos a la primera aspiración de problemas.

Una alternativa a la adición de nuevos trabajadores es trabajar trabajadores existentes horas extras. Esto generalmente funciona siempre y cuando usted no trabaja horas extras ellos por mucho tiempo. De lo contrario, el derecho de Homero entra en juego.

La ley de Homero

Si hace horas extras un hecho de la vida de los empleados durante demasiado tiempo, que va a terminar estirando el calendario de su proyecto, de acuerdo a la ley de Homero. Trabajar horas extras aumenta la productividad en el corto plazo. A la larga, sin embargo, aumenta la fatiga, que a su vez incrementa la tasa de error, estableciendo el ciclo de retrabajo de nuevo, esta vez con una venganza.

Retrasar el proyecto

Adición de los empleados para un proyecto a finales menudo no funciona, y los empleados que trabajan horas extras tiene una utilidad limitada, así que a veces el mejor enfoque para la gestión de riesgos relacionados con la productividad es revisar el calendario para reflejar un retraso. Si bien esto puede parecer derrotista, en realidad puede hacer el proyecto hecho más rápido que la adición de nuevas personas o trabajar horas extras de su personal actual por mucho tiempo, ya que no se iniciará el ciclo de retrabajo.

Funcionalidad Sacrificio

Otro enfoque que funciona bien es que sacrificar la funcionalidad, también conocido como la reducción de su alcance.

Sacrificar la funcionalidad es a menudo una estrategia exitosa para la gestión de un proyecto retrasado. Una forma de implementar este enfoque es diseñar " sacrificial " funcionalidad en el proyecto en la fase de planificación. Si el proyecto se ejecuta sobre el presupuesto o se retrasa, entonces esta funcionalidad puede ser sacrificado.

Las ventajas de este enfoque son de dos tipos. Temprano en el proyecto, mientras que todavía está a tiempo, todos los empleados están totalmente ocupados para que no pierdan tiempo en exceso de la ingeniería del proyecto. Más adelante, si el calendario proyecto no va mal, que lo ha identificado lo que la funcionalidad se puede caer con el menor impacto en la satisfacción del cliente.

Por ejemplo, un proveedor de software entregado 85 por ciento de su proyecto de software a un cliente a tiempo, y el cliente estaba razonablemente feliz. Sin embargo, el proveedor se aseguró de que el 85 por ciento entregado contenía la funcionalidad que era más importante para el cliente. En un nivel más prosaico, todos hemos convertimos en papeles en la escuela en la que nos hemos sacrificado algo de contenido a fin de no llegar tarde!