Un proyecto es un:
- … esfuerzo temporal para crear un producto, servicio o resultado único,
- … sobre el que existe incertidumbre, por su naturaleza única,
- … con una organización y recursos ad-hoc, de carácter ínterfuncional,
- … articulado en un programa de trabajo,
- … que puede ser integrado en otro producto o servicio.
He escuchado recientemente en varios foros que a partir de ahora los nuevos modelos de contratos que se celebren entre cliente y proveedor deberán incluir cláusulas de riesgo compartido entre ambos. Pero, ¿cómo debemos entender el riesgo compartido si aún arrastramos prácticas históricas que han marcado la relación entre ambos? Veamos algunos ejemplos:
- Pliegos prácticamente inalcanzables que por una determinada cantidad cubren equipamiento, servicios y mantenimiento de los sistemas objeto del pliego. En el mejor de los casos el equipamiento y el mantenimiento asociados son medibles, controlables y acotados. Pero cuando hablamos de la palabra “servicios” se abre un abanico que tiende al infinito.
- Algunas veces en el caso de los servicios, nos encontramos con pliegos que, con suerte, los detallan, pero cuando nos adentramos en el desarrollo de aplicaciones a medida es imposible abarcar funcionalidades que se detectan sobre la marcha en el proyecto (me remito a la imagen del iceberg). Por supuesto, hay metodologías que detectan en fases tempranas esta casuística y se podría actuar sobre las que podrían considerarse funcionalidades “adicionales”, bien como un añadido al proyecto (improbable en el caso de pliegos), como una segunda fase en la implantación (sigue estando el coste del lado del proveedor) o descartar su realización (ya tenemos al cliente descontento).
Tenemos aquí las tres variables clave en la gestión de cualquier proyecto (tiempo, coste y personas) que “agitados, pero no mezclados” deberían conseguir que el proveedor no pierda dinero y que el cliente quede satisfecho.
Pero, ¿esto sucede en la realidad? Sinceramente, no estoy segura. Hace poco leí un artículo en el que se animaba a las empresas a prescindir de los jefes de proyecto como medida de reducción de costes, ya que realmente ellos no aportaban nada a la cadena de valor, pues el trabajo era ejecutado por quienes realmente lo hacían. De alguna manera, la función desarrollada por los jefes de proyecto pasaba a distribuirse entre dos perfiles (los que venden y los que hacen) para “ir tirando”.
En línea con este artículo me llegó a través de Linkedin Today este otro “9 Things That Motivate Employees More than Money” y cuanto menos, resulta curioso el punto 2 en el cual animan a las empresas a prescindir de los jefes de proyecto para aumentar la motivación de resto del personal, ya que con esta medida “irán al trabajo más temprano, se quedarán hasta más tarde y dedicarán más energías a solucionar problemas”.
Mi opinión es contraria a los planteamientos anteriores y la reflexión que nos debemos hacer es la siguiente: si se quiere compartir riesgo (si el producto o servicio no está en la fecha pactada) o si las tareas propuestas por el proveedor en las distintas fases del proyecto (instalación, formación) no pueden realizarse por causas no imputables a él (instalaciones o personal no disponible por parte del cliente), habrá que esforzarse en establecer un procedimiento compartido para ajustar estos pliegos.
Porque, al final, de lo que se trata es de ir a la búsqueda del beneficio compartido, de que el proyecto se implante en tiempo, costes y forma establecida y, sobre todo, que los usuarios del sistema lo adopten con facilidad, que tanto ellos como la organización se beneficien de sustantivas mejoras y que la empresa contratada obtenga unos beneficios industriales razonables.
María Luisa Santa María tiene más de 15 años de experiencia en la gestión de grupos de trabajo para la implantación de proyectos informáticos de alto impacto en términos de mejora de la calidad y reducción de costes. http://es.linkedin.com/pub/maisasantamaria |