Marcha de la muerte es un término acuñado por Edward Nash Yourdon.
El término definido como un proyecto de marcha de la muerte es aquel cuyos “parámetros del proyecto” exceden la norma en al menos un 50 por ciento.
En la mayoría de los proyectos, esto significa que se han impuesto una o más de las siguientes restricciones al proyecto :
El programa se ha comprimido a menos de la mitad de la cantidad estimada por un proceso de estimación racional; por lo tanto, el proyecto que normalmente se esperaría que dure 12 meses calendario ahora debe entregar sus resultados en seis meses o menos. Debido a las presiones competitivas de la competencia empresarial en el mercado global actual, junto con el concepto de “tiempo de Internet” de la era de las puntocom de la industria informática, esta es probablemente la forma más común de proyecto de marcha de la muerte.
El personal se ha reducido a menos de la mitad del número que normalmente se asignaría a un proyecto de este tamaño y alcance; por lo tanto, en lugar de recibir un equipo de proyecto de 10 personas, se le dijo al gerente del proyecto que solo hay cinco personas disponibles. Esto puede deberse a la creencia ingenua de alguien de que un nuevo lenguaje de programación o entorno de desarrollo de aplicaciones duplicará mágicamente la productividad del equipo, a pesar de que el equipo no recibió capacitación o práctica con la nueva tecnología y probablemente ni siquiera consultado sobre la decisión de usar la tecnología en primer lugar. Desafortunadamente, está sucediendo con mucha más frecuencia, ya que esta edición de la Marcha de la Muerte se está escribiendo en la primavera de 2003, debido a la recesión económica en curso y los recortes asociados en los presupuestos de TI.
El presupuesto y los recursos asociados se han reducido a la mitad. Nuevamente, esto es a menudo el resultado de la reducción de personal y otras medidas de reducción de costos, pero también puede ser el resultado de una licitación competitiva en un contrato de precio fijo, donde el gerente de proyecto en una empresa de consultoría es informado por el departamento de marketing de que “lo bueno la noticia es que ganamos el contrato; la mala noticia es que tuvimos que reducir su presupuesto a la mitad para vencer a los competidores “. Este tipo de restricción a menudo tiene un impacto inmediato en la cantidad de personal del equipo del proyecto que puede ser contratado, pero las consecuencias a veces son un poco más sutiles, por ejemplo, puede llevar a la decisión de contratar desarrolladores de software junior relativamente poco costosos y sin experiencia, que los veteranos de mayor costo. Y puede conducir a una atmósfera generalizada de pellizcos que hace imposible que el gerente del proyecto ordene pizza para el equipo del proyecto cuando pasan todo el fin de semana en la oficina trabajando horas extras.
La funcionalidad, las características, los requisitos de rendimiento u otros aspectos técnicos del proyecto son el doble de lo que serían en circunstancias normales. Por lo tanto, es posible que se le haya dicho al equipo del proyecto que necesita comprimir el doble de funciones en una cantidad fija de RAM o espacio en disco que su competidor; o puede que le hayan dicho que su sistema tiene que manejar el doble del volumen de transacciones que cualquier sistema comparable haya logrado alguna vez. Las limitaciones de rendimiento pueden o no conducir a un proyecto de marcha de la muerte; después de todo, siempre podemos aprovechar un hardware más barato y más rápido, y siempre podemos buscar un algoritmo más inteligente o un enfoque de diseño para lograr un rendimiento mejorado. Pero duplicar la funcionalidad, es decir, las características disponibles, generalmente significa duplicar la cantidad de trabajo que debe llevarse a cabo; eso lleva a un proyecto de marcha de la muerte.
La consecuencia inmediata de estas limitaciones, en la mayoría de las organizaciones, es pedirle al equipo del proyecto que trabaje el doble y / o el doble de horas por semana de lo que se esperaría en un proyecto “normal”. Por lo tanto, si la semana laboral normal es de 40 horas, a menudo se encuentra un equipo del proyecto de la marcha de la muerte trabajando 14 horas al día, seis días a la semana. Naturalmente, la tensión y la presión aumentan en tales entornos, por lo que el equipo de la marcha de la muerte opera como si estuviera en una dieta constante de Jolt cola.
Por supuesto, incluso un proyecto sin las restricciones de horario, personal, presupuesto o funcionalidad descritas anteriormente podría tener un alto riesgo de fracaso, por ejemplo, debido a políticas hostiles entre el departamento de TI y la comunidad de usuarios. Pero más comúnmente, la razón de la evaluación de alto riesgo es una combinación de las limitaciones descritas anteriormente.
Incluso puede clasificar estos proyectos de muerte en proyectos de pequeña escala, proyectos de mediana escala, proyectos de gran escala, etc.
Gracias por leer la respuesta. Y para más consultas puedes comentar a continuación.
