Ingeniería del proyecto: el problema del desarrollo de software (7/7): razón de ser de una gestión de proyectos en informática

Se ha dicho que la gestión de proyectos es una manera de hacer frente a problemas y retos. También hemos añadido los estados de un proyecto que presenta problemas de gestión. Ahora se presentan razones más concretas que justifican la gestión de proyectos en un proyecto en general y en un proyecto de base tecnológica. Ellas son:

actuación predictiva; y,
recuperación.

A. Actuación predictiva

Para varios autores, una forma de actuar predictivamente en los problemas de gestión, es anticiparse a ellos con una completa y adecuada gestión de proyectos, la cual puede medirse si con la gestión se garantizan alcanzar los siguientes Factores Críticos de Éxito (planteados por Jurison):

Objetivos claramente definidos.
Apoyo claro y total de la dirección.
Presupuesto adecuado y realista.
Programa coherente, racional y realista.
Participación y confianza real del cliente y usuarios.
Buen liderazgo del proyecto.
Revisiones continuas, constructivas y positivas del proyecto.
Gestión y control eficiente y eficaz del cambio.
Buenas comunicaciones entre integrantes del proyecto.
Anticiparse y solucionar los problemas que surjan con una gestión de contingencias.

B. Recuperación

Otros autores señalan que la gestión de proyectos permite determinar el momento y las acciones de recuperación de un proyecto, igualmente de que estas acciones se lleven delante de manera adecuada. En este caso se habla de una de-escalación y/o la convocación de un caballero blanco.

B.1. De-escalar

En una de-escalación se toman acciones que permitan superar los diversos problemas de gestión ante una escalada. Para Ribera recuperarse de una escalada puede ser:

recortar la envergadura del proyecto;
aumentar la productividad mediante mejoras a corto plazo; y/o,
asumir que el proyecto no terminará a tiempo, atrasar el plan y adoptar medidas de control de daños.

Lo que para Glass se traduce en tomar acciones en el siguiente orden de preferencia:

extender las fechas;
usar mejores procedimientos de gestión;
más personal;
más fondos;
reducción en alcance del proyecto;
mejores metodologías de desarrollo;
cambiar tecnología; y,
abandonar el proyecto.

Acciones que, para Montealegre y Keil, no tendrían ningún efecto si no se apela a la colaboración y cooperación de los participantes involucrados en el proyecto o, sencillamente, des-institucionalizar el proyecto, dejando la de-escalación como un problema interno de gestión a superar internamente.

Un ejemplo sería el caso caso de un proyecto informático al que se le agregan requerimientos informalmente (fuera de planificación). Esto produce que no se pueda finalizar el proyecto en los plazos previstos. Ante esta situación, se de-escala. Así, se re-comienza leyendo los documentos de definición, incluyendo el plan de actividades inicial y los cambios autorizados, y luego se documentan todos los puntos agregados extraoficialmente, todo esto para tratar de clarificar cuales son las causas de los desvíos que llevaron a nuevos requerimientos y además informales. Con esto en mano, se propone reunirse con las partes interesadas que son claves en el proyecto y acordar qué se agregaría o quitaría en adelante. Basados en todo esto y en los acuerdos, las actividades restantes y los recursos disponibles, se arma un nuevo cronograma. En este ejemplo, esta situación que permite recuperar el proyecto, debe considerar el análisis del presupuesto para ver si alcanza o no y prever nuevas fuentes de financiamiento.

B.2. El caballero blanco

Una forma posible de superar los problemas de gestión es contratar a un experto en salvar proyectos, aquella persona milagrosa que viene a salvar todo mal funcionamiento y a intentar recuperar el proyecto: el caballero blanco (white knight). En este tipo de solución debe considerarse la asesoría y la consultoría en proyectos como un medio válido de conseguir algún caballero blanco.

Un ejemplo de este caso sería un proyecto informático descontrolado, donde cada acción no concreta en nada específico y tampoco se mantiene el orden interno. La contratación de un interventor externo, sea un jefe de proyecto específico o una consultora organizacional, como si fuera un caballero blanco, quien se posiciona como líder con poder suficiente para ordenar y organizar el proyecto. Se debe reunir con cada una de las partes afectadas e involucradas y retomar cada requerimiento del proyecto para estudiar su estado de avance. El problema que puede surgir es el rechazo por parte del equipo o stakeholders del proyecto al caballero blanco, motivo por el cual se debe seleccionar en muchos casos a alguien con prestigio y reconocimiento.

____________________________________

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.
JURISON, JAKK. (1999). Software project management: the manager’s view. Communications of the AIS, 2 (17). September.
MONTEALEGRE, RAMIRO; Y, KEIL, MARK. (2000). Deescalating Information Technology Projects: Lessons from the Denver International Airport. MISQ research article.
RIBERA, J. L. (2000). Project Management. MBA Course IESE, Universidad de Navarra (Spring 2000).