Hay proyectos que parece que no se acaban nunca. Cliente y proveedor acuerdan realizar una serie de tareas, planifican su ejecución pero a la hora de ponerlas en marcha, alguna se eterniza y parece que nunca llegará a su fin. El problema suele estar en una mala definición de los requisitos del trabajo a ejecutar. Una mala identificación del problema a resolver, puede provocar cambios constantes durante la vida del proyecto, lo que obliga a replanificar constantemente y a tirar horas de trabajo a la basura.
Dependiendo de cómo se haya firmado el proyecto, a precio cerrado o con coste por hora hasta su finalización, una de las partes, cliente o proveedor, saldrá más penalizada de una situación como esta. El problema, en realidad, cuando no se cierra un proyecto, lo tienen las dos partes.
El proveedor porque no cierra un proyecto, con lo que ello puede suponer: costes de recursos dedicados que no son sufragados por el cliente; coste de imagen ante otros clientes; costes financieros mientras no se cobren partidas pendientes; coste de oportunidad de seguir con un proyecto “enquistado”;…
El cliente tiene un problema porque está dedicando recursos que tienen que atender su negocio a algo que no aporta valor a su cliente. A nivel interno, puede llegar a crear desconcierto en los trabajadores, e incluso desidia, repudiando un proyecto en el que han puesto esfuerzo y que no ve nunca la luz. Show me the money, se planteará alguno antes de recuperar el mínimo entusiasmo por el trabajo.
¿Qué se puede hacer para evitarlo? Como ya comentaba, una adecuada definición de requisitos es la mejor herramienta para permitir que un proyecto no caiga en ese maldito bucle de “no terminar jamás”. Si está todo perfectamente definido y aprobado por ambas partes, se evita el “no me gusta, cámbialo”, “ahora retoca esto también”,… Se hace lo pactado y punto. Ni más, ni menos.
Ojo, no se trata de estar un siglo entero definiendo cada apartado en profundidad, haciendo integrales triples en cada esquina, a ver si aguanta el modelo. Nada más lejos de la realidad. No se puede caer en el extremo contrario y morir por la parálisis por el análisis. De mayor a menor detalle, hasta que se llegue a un punto suficiente. El problema también puede surgir con la interpretación de “suficiente”, ya que no es lo mismo para el proveedor, muy acostumbrado a trabajar con proyectos, que para el cliente, normalmente mucho menos.
El cliente muchas veces no es capaz de ver y comprender todo el proyecto. Sabe lo que quiere, pero no comprende las tareas necesarias para lograrlo. La visión global que le permita entender todo su alcance, no debe suponerse. Si no se tiene muy claro que ésta exista, es recomendable también que el proveedor dedique jornadas de trabajo a ello. A veces pienso que hay gente que se cree que implantar un proyecto es cosa sólo de darle a un botón y listo. Nada más lejos de la realidad.
Lo mismo con el proveedor, aunque diga que ha comprendido todo el negocio, debe asegurarse de que es así. De lo contrario, la solución propuesta, no tiene por qué coincidir con lo que el cliente realmente necesita. Es más, se pierde la oportunidad de poder plantear una solución mejor, que aporte un mayor valor. Hay que explicar al cliente las cosas como son, sin tecnicismos y jerga que requiera un master en consultoría o un título de especialización en gestión de proyectos. Lo mismo con el proveedor, aunque tenga experiencia previa trabajando en el sector del cliente.
Si se dispone de una buena definición de requisitos, en la que tanto se ha insistido en los párrafos anteriores por ser -en mi opinión- la principal causa, y se traslada ésta a una lista de tareas, se podrá hacer una planificación en condiciones. Otra cosa es que luego no se pongan los medios adecuados, que también pasa. Equipos y personal que tienen que estar a su debido tiempo, tareas que hay que cerrar formalmente para pasar a la siguiente, calendarios de pagos que hay que cumplir,… Si no se encaja todo lo anterior y se cae en una contínua replanificación, cualquier documento que la recoja servirá para todo menos para seguir el proyecto, con todas sus consecuencias: pérdidas de tiempo, cero credibilidad por parte de los implicados, trabajo desconectado de los distintos agentes,…
En definitiva, como se ha podido ver en esta entrada, las consecuencias de trabajar en proyectos que nunca se acaban son desastrosas. Nadie desea que le toque un proyecto así, pero todos conocemos alguno que ha pasado, o pasa, por esa situación. Un horror, que al final estás deseando sacarte de encima y pasar a otra cosa, casi sin importar si se cumplen los objetivos inicialmente marcados. Es como llevar una cruz a cuestas, ahora que estamos cerrando la época de procesiones.
Pablo Herrero es Ingeniero Industrial en la especialidad de Organización Industrial, relacionado con la Ingeniería de Organización de empresas.
Escribe habitualmente en el blogFuera de Límites y ha colaborado en Pymes y Autónomos.
Puedes seguirlo en Twitter en @pabloherrero
Fuente: Blog Sage
Imagen: Charly Morlock
