Los errores de la triple restricción en los proyectos

En el entorno de desarrollo de los proyectos es muy común ver como estos se desvían de sus objetivos iniciales y terminan sin resolver los problemas que les dieron luz verde, pierden el “norte” y como consecuencia de esto pierden también su razón de ser, ocasionando brechas en las percepción del proyecto desde diferentes puntos de vista, vemos a un Project Manager contento con la finalización exitosa en tiempo, costo y alcance de su proyecto, pero vemos a un Sponsor y a Stakeholders completamente fastidiados con un producto o servicio final que no satisface sus necesidades.

La pregunta cae sobre su propio peso, ¿Qué paso? ¿Quién es el responsable? ¿Qué se hizo mal o que se dejó de hacer?

Yo siempre doy como un ejemplo clásico de estos casos el típico proyecto de implementación de un ERP (Enterprise Resource Planning), y es que los que hemos estado vinculados directa e indirectamente en la implementación de este tipo de software o símiles (SCM, EAM, PPM, etc) sabemos que la mayoría de beneficios que estos sistemas integrados nos ofrecen son de corte estratégico del negocio, beneficios tales como ahorro de costes, mejora de productividad, calidad del servicio, etc., pero que luego cuando se procede al proyecto de implementación este se centra en los requisitos que conforman el alcance, en los costos definidos del proyecto y en el tiempo estimado inicial, perdiendo así el norte del proyecto, del problema que resuelve y de las necesidades que satisface.

No me malinterpreten, muchas de estas soluciones son excelentes para optimizar resultados en las empresas, pero cuando aparecen estas brechas antes mencionadas, normalmente son errores en la planificación y concepción del proyecto, mas no errores del software.

Y es que el peor error que puede cometer un Project Manager es centrar su proyecto en una triple restricción que no responde a objetivos definidos en lugar de definir inicialmente objetivos y sobre estos re expresar la triple restricción, lo primero sucede frecuentemente.

Objetivos vs Requisitos o Requerimientos

El problema normalmente nace cuando el proyecto se concibe desde una lista de requisitos, que pueden contener las características del producto o servicio que se solicita y que, como todos los que trabajamos con proyectos sabemos, son propensos a cambios durante la ejecución, y luego si el proyecto no tiene un "norte" definido termina deambulando con un producto o servicio final que muchas veces no resuelve ninguna necesidad.

Se deben definir objetivos del proyecto, objetivos que respondan a los objetivos empresariales del plan estratégico y que puedan medirse y controlarse durante y después del proyecto, lo que dará una medida de éxito del mismo para dar un soporte real a los problemas que le dieron luz verde inicialmente.

Si bien estos objetivos también pueden ser propensos a cambios, sabremos que el cambio de un objetivo del proyecto podría cambiar toda la dirección del proyecto mismo, lo cual causara un replanteo total de su plan, en cambio los requisitos son mas flexibles dependiendo de un control de cambios aprobado por el sponsor.

Podemos decir finalmente que si bien la triple restricción es una medida de control importante para los Project Manager, son los objetivos los que finalmente establecen si el proyecto ha llegado realmente a un buen puerto o no.