Si has gestionado un proyecto, sea de lo que sea, seguramente te habrás dado cuenta que existe un triángulo sagrado en la gestión de proyectos, en un vértice el alcance del proyecto, en otro los recursos disponibles y en el tercer vértice el tiempo. Hay una extraña ley que vela día y noche para que la superficie definida por los vértices de dicho triángulo sume siempre lo mismo. Siempre me ha fascinado esta ley y voy a exponer algunos ejemplos. Dejadme definir antes los 3 conceptos básicos en la gestión de un proyecto:

  1. Alcance: define aquellos aspectos que se espera abordar dentro del proyecto. Como parte del alcance es importante también definir lo que se queda fuera del alcance (principalmente para evitar malentendidos y calibrar la expectativa del que encarga el proyecto).
  2. Recursos: son los recursos con los que se cuenta para acometer la empresa de ejecución del proyecto. En el ámbito de proyectos de servicios, como por ejemplo proyectos tecnológicos, generalmente los recursos que condicionan más el proyecto son los humanos, es decir, la personas que está previsto participen en el proyecto.
  3. Tiempo: es el tiempo que se estima será necesario para llevar a cabo el proyecto y conseguir el alcance definido para el proyecto con los recursos disponibles.

Uno de los grandes retos que tiene un gestor de proyectos es calibrar bien el triángulo sagrado del proyecto. Un buen gestor de proyectos debe comprender muy bien el alcance del proyecto y lo que implica, saber con qué recursos dispone (y de qué son capaces) y estimar el tiempo necesario para acometer el proyecto. Y otro de los grandes retos que tiene es mantener el pulso del triángulo durante todo el tiempo de desarrollo del proyecto, pues es probable que aparezcan cambios en el alcance, recursos y tiempo durante el camino y convendrá gestionarlo. Ahí algunos ejemplos:

Disminución de recursos a medio proyecto

Pongamos por ejemplo que se desea abordar un proyecto para desarrollar una aplicación informática que permita realizar la reserva de vuelos por internet. Supongamos que después de realizar una análisis de lo que el cliente desea salen 40 ítems que configuran el alcance. Supongamos que se estima que el desarrollo de la aplicación implicará 6 meses de trabajo de un equipo de 4 personas. ¿Qué pasa si de golpe causan baja 2 personas del equipo (porque los asignan a otro proyecto, porque los despiden, porque se largan, etc.)? Suponiendo que las 4 personas rinden igual (lo cual es mucho suponer), si se quiere mantener el alcance implicará que el proyecto se va a realizar en 12 meses en lugar de 6. Aquí es importante que no le tiemble el pulso al gestor y lo comunique a los responsables en el mismo momento que se sabe de la baja (como más tarde peor). Otra opción, con el fin de mantener la estimación de tiempo de 6 meses sería reducir el alcance; esto es, en lugar de realizar la aplicación con 40 ítems pues rebajarlo al número de ítems que haga que se cumpla el tiempo de 6 meses (esto podría ser 20 ítems si todos los ítems implicaran el mismo esfuerzo). Aquí conviene que el gestor sepa exponer bien la situación y tenga dotes de negociación para llegar un consenso en el recorte del alcance. Un buen compromiso suele ser partir el proyecto en fases y acometer una primera fase con la fecha deseada con los 20 ítems. Y más adelante abordar la segunda fase con los 20 ítems restantes.

Incremento de alcance a medio proyecto

Otro caso que se da a menudo es que en medio de un proyecto se detectan aspectos que sería deseable abordar. Entonces corre la tentación de añadir estos aspectos en el alcance del proyecto y todavía más tentación por parte del cliente de añadirlos por el mismo precio. ¿Que pasaría si lo hacemos? pues que se alargará el tiempo de entrega si no se incrementan los recursos. De nuevo, el gestor tiene que tener la valentía para exponer este hecho a los resposables del proyecto. Si se quieren mantener las fechas de entrega se deberán incrementan los recursos: se incorporan más personas en el proyecto o manteniendo los mismos se hacen más horas respecto las previstas. Aquí el gestor tiene que hacer las gestiones oportunas para conseguir el «salvoconducto» para meter más personas al proyecto. Las vías para conseguir el salvoconducto pueden ser varias, a lo mejor se ha negociado una derrama con el cliente para aportar más dinero, quizás la empresa desarrolladora asume el riesgo y autoriza a poner más personas cubriendo ella el coste, etc.

Fechas caprichosas versus fechas estimadas

Otra caso usual en la gestión del proyectos es el hecho de modificar «caprichosamente» la fecha en la que se debe entregar el proyecto respecto la fecha estimada inicialmente. Por caprichosamente me refiero que no es producto de estimar el esfuerzo de cada tarea del proyecto, asignar las tareas a los recursos disponibles y deducir (sumando y multiplicando) la fecha de finalización del proyecto, sino que la fecha final obedece a condicionantes externos (imposición de alguien, entrega para cobrar una factura en una fecha determinada, una demo presentación del producto en público, etc.). De manera parecida al caso anterior el buen gestor tiene que hacer que vuelva a «cuadrar» el triangulo sagrado o de lo contrario habrá conflictos. ¿Cómo? pues o toca la «barbita» de quien sea para que se autorice poner más recursos o consigue convencer a quién sea que el alcance previsto para el proyecto no se va a cumplir para la fecha caprichosa. Todas las otras variantes van a generar conflicto. Si se obliga a hacer horas extras a las personas sin pagarlas y/o sin tener en cuenta planificaciones establecidas (vacaciones, etc.) el conflicto está servido. Una persona descontenta en su trabajo no suele trabajar igual de bien que cuando está satisfecha y es muy probable que las tareas que haga no ponga todo su empeño, con lo cual va a desembocar en una disminución de la calidad.

Un buen gestor no puede hacer milagros y modificar cosas que no están en sus manos, pero lo que sí puede y debe hacer es analizar el equilibrio del alcance, tiempo y recursos y hacer las gestiones pertinentes en todo momento. Como es usual el logro de un proyecto no depende de una persona y aquí el gestor no hace más que poner su granito de arena.