En este artículo voy a comentar algunos de los motivos que llevan a un proyecto fracasado o proyecto fallido y que he encontrado a lo largo de mi carrera profesional. Lo cual puede servir de experiencia a otros colegas en forma de lecciones aprendidas.
Nota: Animo a los lectores a incluir sus experiencias (positivas o negativas) como comentarios al pie de este artículo; ya que con toda seguridad estas servirán de ayuda a otros colegas e incrementarán la utilidad de este texto.
Si te gusta este post y te interesa aprender más sobre la gestión de proyectos, te sugerimos que descargues nuestra guía o nuestro set de plantillas profesionales. Así, de paso, nos ayudas a seguir creando contenido de valor para ti 😉 Gracias!!
Un error común en organizaciones pequeñas es centrarse más en hacer el proyecto que en gestionarlo. Esto se traduce en una falta de procedimientos a nivel de gestión, y por tanto en una mayor dificultad para planificar y controlar los proyectos.
Este aspecto se ve agravado cuando en la organización no existe una cultura de dirección de proyectos, lo que adicionalmente impide implementar estos procedimientos. Esta situación no puede considerarse como un error del director del proyecto, el cual debe asumir una función de administrador más que de director, sino de la propia organización.
Cuando esto ocurre, una posible solución es incrementar la comunicación y el número de reuniones de seguimiento. De esta forma se sustituye la falta de procedimientos por la comunicación interpersonal. Aunque lo más recomendable es disponer de los principales documentos de planificación del proyecto (cronograma, costes, etc), aunque no hace falta desarrollarlos en mucho detalle.
Otro error frecuente es empezar a ejecutar el trabajo sin tener claro lo que debe hacerse, lo que en la práctica genera trabajo adicional, insatisfacción del cliente y atrasos. Por mi experiencia este error suele producirse por diferentes motivos:
Otro caso que guarda mucha relación con el punto anterior es la situación que se da cuando estás entregando un paquete de documentos, y alguien, a veces desconocido hasta aquel momento, dice que estos no cumplen con lo solicitado. ¿Quién es este individuo?¿Por qué no se calla?.
Esta situación es un ejemplo claro de un stakeholder que no fue correctamente identificado en su día, y por tanto sus requerimientos no fueron incluidos en el proyecto. Obviamente aplicar las técnicas de identificación de stakeholders en las fases iniciales del proyecto ayuda, pero en la práctica es muy útil definir interlocutores únicos dentro de cada organización. De tal forma que sean estos los que hablen en nombre del grupo, y se responsabilicen de recolectar toda la información dentro del grupo. Esto en cierta forma no impide que el problema ocurra, pero facilita que estos casos se puedan tratar como solicitudes de cambio.
Cuando hablamos de cambios en proyectos debemos recordar que estos deben ser analizados y aprobados antes de su aplicación, por tanto los errores en este punto vienen por fallos en este procedimiento.
En algunos casos se aceptan cambios sin haber analizado su efecto sobre el coste y el plazo total del proyecto, lo que al final provoca desviaciones. Todos los efectos producidos por un cambio deben de identificarse y cuantificarse, y es algo que debe ser asumido por el cliente en el momento de aceptar su aplicación en el proyecto.
Una vez aprobado un cambio, este debe divulgarse y aplicarse en los entregables. A veces este proceso falla, y la gestión del cambio finaliza en la aprobación, sin que las personas que están ejecutando el trabajo se enteren del cambio. Esto es equivalente en la práctica a una indefinición del alcance, ya que un cambio aprobado pasa a formar parte de este.
Cualquier proyecto tiene riesgos asociados, y no considerar los márgenes para ellos puede ocasionar desviaciones de costes y plazos. Por ello siempre se debe incluir este margen, aunque sea en forma de porcentaje en proyectos pequeños que no justificarían una mayor dedicación de recursos a este tema.
Discrepancias entre lo vendido y lo que el cliente espera. ¿Te suena?. En muchas organizaciones la venta del proyecto no forma parte del ciclo de vida de este, por lo que el director del proyecto solo entra en acción una vez recibido el pedido.
Esto es un error, ya que formalmente la venta sería equivalente a la fase de inicialización, ¿o acaso en la oferta y el pedido no se define de forma general el alcance, presupuesto y plazo? Por ello es recomendable que el director del proyecto participe de forma activa en el planteamiento de la oferta, y en la estimación inicial de los costes y plazos.
Perdida de información cuando el proyecto pasa de un equipo a otro, por ejemplo del equipo de ingeniería a el equipo de fabricación. Esto suele deberse a fallos en la comunicación o en la documentación. En este aspecto es importante entender que el equipo que recibe el proyecto actúa como un “cliente” del primer equipo. Por tanto este debería poder participar en la definición de los documentos a generar por el primer equipo, introduciendo en ellos sus necesidades.
También es importante definir hitos en el proyecto para que los diferentes traspasos de información ocurran de forma oficial, así como listas de puntos para confirmar que toda la información que debe traspasarse está considerada en estos hitos.
Aquí es donde mejor se entiende la frase “el director de proyectos hace hacer”. Un error común, sobretodo en directores de proyectos con formación técnica, es pretender participar activamente en la ejecución de las tareas.
Como se ve en los diferentes artículos de esta página, el director del proyecto debe ocuparse de varios aspectos de gestión, aparte de aspectos burocráticos propios de cada organización. Esto requiere tiempo y tener una visión general del proyecto a medio-largo plazo. Si este dedica su tiempo a ejecutar una tarea en concreto, y por tanto focalizada y centrada en el corto plazo. ¿Cómo puede tener tiempo de realizar sus funciones y mantener la visión general a medio-largo plazo?. El resultado es que el proyecto va a la deriva y que los problemas aparecen de golpe.
Un error habitual cuando se empieza es limitar la comunicación con el cliente y la dirección a los hitos del proyecto (entregas, reuniones oficiales, etc.). Esto provoca nerviosismo en estas personas, el cual acaba repercutiendo en forma de presión extra que genera el proyecto fallido. Por ello es importante mantener una comunicación regular con ellos, mediante informes periódicos o comunicaciones informales.
La práctica demuestra que cuando estos están enterados de la situación del proyecto, este se simplifica, incluso en el caso de problemas reales. El simple hecho de informar que se conoce un problema, de lo que se está haciendo para solucionarlo, y de los progresos, ya supone una rebaja importante de la tensión. Y en muchos casos esta mayor comunicación ayuda a evitar los problemas o a detectarlos antes.