Christian A. Estay-Niculcar's research blog

Espacio de reflexión personal dedicado a la investigación aplicada cuando se vincula la ciencia proyectual con la disciplina informática, y se aplican al desarrollo de las personas y de la gestión empresarial.

Ingeniería del proyecto: el problema del desarrollo de software (6/7): estados de una mala gestión de proyectos

Los errores mostrados en la tabla del post previo (ver aquí) y muchos otros más, ocurren y han sido reportados profusamente en la literatura. No obstante, se han podido determinar algunos estados que indican una gestión de proyectos inefectiva o de que es prudente plantearse usarla. Estos estados de un proyecto son:

  • modo ajustado (crunch mode);
  • marcha mortal (death march); y,
  • fuera de control (runaway).

Modo ajustado

El modo ajustado, para Glass, describe un proyecto que se encuentra extremadamente ajustado a la programación. Se habla que existen fuertes presiones que sienten los participantes del proyecto. Es el estado cuando el proyecto anda por los límites del programa de trabajo, más bien superándolo.

En este estado, dentro del proyecto informático comienza a notarse que:

  • “las semanas tienen siete días y los días 24 horas”;
  • “los días son cortos y las noches largas”;
  • empiezan las primeras fugas;
  • hay una ‘ralentización’ de la motivación;
  • se suceden las re-planificaciones de forma frecuente;
  • etc.

Marcha mortal

La marcha mortal, según Glass, describe un estado en que el proyecto tiene una programación difícil de conseguir. Se habla que “hay olor a fracaso” (“esto huele mal”) entre los participantes. Para Yourdon, un proyecto en marcha mortal posee una valoración de riesgo de falla sobre el 50 por ciento (incluyendo riesgos técnicos, del personal, legales, políticos, etc.).

Según Ribera este estado es un Modo Imposible de trabajo debido a que:

  • “El plazo es inferior a la mitad de lo que racionalmente se precisa”;
  • “El personal asignado es inferior a la mitad que habitualmente se asignaría a un proyecto de estas características”;
  • “El presupuesto se ha recortado a la mitad”, y,
  • “La funcionalidad, requisitos, y otros aspectos técnicos son superiores al doble de lo normal”.

El mismo Ribera acota, que es estas situaciones surgen preguntas como: “¿Qué hace un chico como yo en un proyecto como éste” o “¿Cómo puedo sobrevivir a este proyecto sin perder mi salud física y mental y mi dignidad?”.

Fuera de control y escalada

Un proyecto fuera de control, o “Runaway”, describe un estado o un estado de cosas manifestadas cuando un proyecto está cerca o después de su término. Sencillamente, el proyecto está fuera de sus límites, o ya no tiene límites, hablándose, según Glass, que el proyecto falló o está pronto a fracasar.

Cuando se está fuera de control, se puede decir que estamos ante una bola de nieve, la cual resulta de una escalada de errores por motivos, que según Keil y Mixon, se deben a factores psicológicos, sociales y organizacionales. Estos errores son consecuencia de una gestión inadecuada, fallida o nula, que pone al personal y especialmente a gestores, ante una variedad de problemas que supera sus capacidades de gestión y de resolución de problemas. Esta situación hace que un error lleve a otro, produciéndose una cadena creciente, una escalada de problemas de gestión, debido al cansancio, fatiga y desorientación que supone la tensión de la situación.

Lo anterior es lo que se llama escalada y romperla requiere una alta capacidad de superar el estrés físico y mental que supone un rescate, hundimiento o salvamento parcial del proyecto

____________________________________

Este post se relaciona con otros más, todos vinculados al tema de estudiar y comprender el problema del desarrollo de software desde una fuerte óptica de la gestión de proyectos.

_____________________________________

Textos usados como fuentes de problemas:

  • GLASS, ROBERT L. (1998). Software Runaways. Lessons Learned from Massive Software Project Failures. Prentice Hall. 259 pp.
  • GLASS, ROBERT L. (1999). Computing calamities. Lessons learned from product, projects, and companies that failed. Prentice Hall. 302 pp.
  • KEIL, M.; y MIXON, R. (1994). Understanding runaway IT project: preliminary results from a program of research based on escalation theory. Proceedings of the Twenty-Seventh Hawaii International Conference on Systems Science, 3:469- 478.
  • RIBERA, J. L. (2000). Project Management. MBA Course IESE, Universidad de Navarra (Spring 2000).

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Información

Esta entrada fue publicada en 2012/02/04 por en * Business - Informatic - Technology - Projects - Strategy - Society - Systems y etiquetada con .

CEO & Co-Founder de EstayConsulting – Consultoría Estratégica

Miembro de Red

//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js (adsbygoogle = window.adsbygoogle || []).push({});

Categorías

A %d blogueros les gusta esto: