Las 10 malas prácticas más comunes en la gestión de proyectos

No importa la experiencia real en proyectos, muchas veces se cometen errores y se utilizan malas prácticas en la gestión diaria y a largo plazo de un proyecto.

En este artículo se abordan brevemente algunas de estas malas prácticas o errores que aparecen como resultado de la gestión diaria. No prima la exhaustividad ni se pretende comentar las sugerencias de la literatura relacionada. Se pone a disposición como material complementario del estudio y práctica de la gestión de proyectos y al rol de gestor como máximo responsable del resultado obtenido. En este caso nos referimos esencialmente a la gestión de proyectos informáticos, aunque los problemas aquí expuestos y sus soluciones pueden ser extrapolados a otro tipo de proyectos. Existen muchos métodos y buenas prácticas a la hora de estimar, planificar, controlar, etc. Cubrirlos va más allá del objetivo de este documento.

1) Incorrecta estimación/planificación del proyecto

Este es el error más común y depende de varios factores, no siempre con una solución a nuestro alcance. Se pueden destacar los aspectos que más influyen: un cliente sin objetivos claros, requisitos demasiado cambiantes, especificaciones no oficiales, incapacidad técnica, fijarse metas demasiado optimistas o arriesgadas (fechas de entrega agresivas, equipo reducido, descontrol de tareas, nula gestión de la calidad, etc.). Veamos cuatro de los casos más comunes:

• Caso 1: Se tiene escaso o nulo conocimiento del entorno destino del software que se quiere desarrollar o el proyecto es el primero de su tipo para el equipo. Se necesita un estimado y plan lo antes posible (AYER) y se propone un estimado y plan iniciales.

Desgraciadamente, en la mayoría de los proyectos, este estimado será el final, sobre todo para el cliente. Si el estimado de presupuesto y tiempo está muy por encima del coste real se renuncia a la confianza del cliente o se puede perder la oportunidad de lograr una licitación. En el caso contrario, si el presupuesto está muy por debajo del coste real, se cae en incumplimientos, baja la calidad del producto final, se dispara el estrés del equipo de desarrollo o se acaba abandonando el proyecto.

Recomendaciones: Siempre que sea posible, destacar los problemas de asumir esta estimación como final, mostrar las amenazas más comunes que presentará un plan precipitado y proponer un tiempo mínimo que permita hacer un estudio de factibilidad, lograr una estimación más precisa y realizar el análisis de riesgos contando con la mayor cantidad de requisitos posibles. Es preferible un disgusto breve al principio que una larga vida de reproches e incumplimientos después.

• Caso 2: La estimación del proyecto es de 9 meses y el gestor de proyectos propone un plan de 8 meses, asumiendo que la productividad aumentará ejerciendo presión. Este proyecto siempre puede considerarse como un fracaso pues, aunque se entregue a tiempo al cliente (8-9 meses), el elevado nivel de estrés del equipo hará que baje su rendimiento, afectará a su salud y promoverá una actitud negativa hacia el trabajo.

Recomendaciones: La estimación – como su nombre indica – es aproximada. Lo correcto es intentar que sea lo más exacta posible y atenerse a ella, evolucionando solo en los casos en los que los cambios así lo requieran.

• Caso 3: Existe una correcta planificación y las tareas estás asignadas a sus responsables. Un miembro del equipo tiene problemas para completar a tiempo sus tareas y el gestor o líder decide asignar parte de sus tareas a otro miembro con mejor desempeño. Esto es premiar la morosidad y castigar el cumplimiento.

Recomendaciones: Escoger cuidadosamente a los miembros del equipo. Analizar la situación actual de la persona con problemas de desempeño y en el caso en que sea factible, ayudarla y potenciar su rol en el equipo. Si esto no es posible, sustituirla y, si no hay otra opción, mantenerla ajustando estimados y planes.

• Caso 4: El estimado es holgado y aprobado por el cliente. Esta situación – que puede ser una ventaja para trabajar sin presiones y poder entregar un producto con una calidad superior – puede ser contraproducente debido al fantasma de la procrastinación. Procrastinar es diferir, aplazar y se presenta en ambientes relajados y no controlados. Esto no significa que se deba controlar en exceso: esto sólo generaría apatía y malos desempeños a la larga. Los mecanismos de control deben planificarse según las tareas y responsabilidades de cada individuo, no solo en general.

Recomendaciones: Estimar de forma más certera, controlar de forma adecuada el trabajo individual y la marcha de las tareas. Detectar fluctuaciones en el ambiente laboral.

2) Inadecuada asignación de roles en el equipo de desarrollo

Este error se presenta generalmente cuando se asignan roles por disponibilidad y no por idoneidad. El riesgo latente al asignar una persona inadecuada a un rol aumenta a medida que es mayor el nivel de responsabilidad del mismo. Una persona puede ser excelente en un rol o tarea y pésima en otro, por eso es importante:

• Perfilar el rol para escoger un profesional con un profesiograma equivalente.
• Tener en cuenta que a medida que un proyecto se vuelve más crítico, mayor debe ser la capacitación del gestor, los ingenieros, analistas, programadores, etc.
• Valorar que a veces es preferible renunciar a un proyecto antes que asignarlo a un equipo incapaz o inestable.

3 – Asumir en vez de contrastar

Los siguientes aspectos deben ser conocidos y contrastados. Es un fallo clásico de muchos gestores – cuando no se tiene la información o ésta es incompleta – asumir lo que no se conoce. Esto es más peligroso que decidir en la incertidumbre. En caso de desconocer los factores esenciales, hay que averiguarlos y oficializarlos. Se debe contar con:

• Objetivos específicos, realistas y medibles del proyecto.
• Fecha de inicio y entrega.
• Recursos disponibles (tecnologías, presupuesto, personal).
• Tendencias de los proyectos específicos con ese cliente.
• Especificaciones de requisitos, riesgos y pronosticar qué se puede esperar para evitar sobresaltos.

4 – Planificar sin incluir a todos los responsables

En esta etapa crucial se debe incluir todo el personal responsable en el proyecto. En el caso de faltar responsables, la precisión del plan se verá afectada y esto dificultará la comprensión del cronograma y la asignación de las metas. Esta cuestión es especialmente delicada en el caso de los directivos. Por eso, se debe contar con:

• Asignación completa de los roles en el equipo.
• Programa del proyecto, fases, actividades y tareas.
• Recursos necesarios para lograr cada actividad.
• Plan de comunicación y gestión de riesgos.
• Asociación visible con al menos un directivo.

5 – Demasiada multitarea

La multitarea es un factor importante y una ventaja cuando hablamos de capacitación. Sin embargo, demasiadas tareas/proyectos a la vez hacen que baje el rendimiento y se convierten en un freno para todo el equipo. Se recomienda:

• En el caso de probada improductividad, reducir los proyectos/tareas abiertos en un 25%-50% (WIP – Work in Progress).
• Es preferible cerrar o pausar algunos proyectos/tareas que mantener varios abiertos a la vez.
• Utilizar metodologías ágiles que ahorren tiempo sin comprometer la calidad.
• Utilizar métodos cuantitativos de planificación y control que permitan una mejor distribución del trabajo.

6 – Falta de comunicación

La comunicación es esencial en un proyecto. Para establecer una comunicación elemental se necesita un emisor, un receptor, un mensaje y un protocolo. La no existencia de estos provoca equívocos, apatía y desorganización (otros aspectos a tener en cuenta son ACK, ruido, sincronización, etc.). Como mínimo, hay que contar con:

• Planificación de las reuniones e interacciones más importantes.
• Establecer las normas, protocolos y tecnologías para comunicarse.
• Asegurar que toda persona conoce esta planificación y medios a su alcance.
• No confiar solo en el software para llevar el proyecto, el contacto personal es necesario muchas veces.

7 – No saber decir que no

Un gestor de proyectos puede ser capaz, tener todos los datos y herramientas necesarios para elaborar un buen plan, controlarlo, garantizar su seguimiento y lograr un buen producto. Sin embargo, un rasgo personal que puede lastrar al resto del equipo es cuando no sabe decir que no. Si un gestor dice ‘no’, no significa que él sea negativo. Decir que no significa que se conoce que en este contexto, bajo estas condiciones y requisitos lo que se le pide no puede ser entregado en tiempo y forma. Implica un buen conocimiento del proyecto y el equipo, las capacidades y estimados y de lo que se quiere y con qué nivel de calidad se desea conseguir. Decir que no en el momento adecuado muestra carácter e inspira respeto.

• Ejemplo: Cuando el cliente o la gerencia solicitan la entrega de un producto antes de la fecha que indican los estimados (o mantener la misma fecha y recursos cuando se han introducido cambios importantes en las especificaciones que obligan a realizar nuevas estimaciones y ajustes en la planificación). Si ya se sabe que no se va a poder cumplir los requisitos o que habrá que renunciar a parámetros de calidad, se debe decir que no, explicando los motivos y buscando un consenso con el cliente y la gerencia. El éxito de este proceso de replanteamiento es esencial para la correcta consecución del proyecto.

8 – Inflexibilidad

En este caso nos referimos a utilizar el no en exceso y de no adaptarse a los cambios adecuadamente. Muchos gestores siguen el plan inicial ciegamente, subestimando la comunicación, desoyendo sugerencias y críticas, olvidándose de supervisar la mecánica del equipo y ajustar su actitud y el plan a los cambios inevitables que van surgiendo. Este tipo de gestor nunca será líder: poco a poco alimentará la inapetencia, el odio o el miedo en los miembros de su equipo. Sus proyectos solo podrán cumplirse si dispone de recursos en exceso o un equipo de desarrollo de extrema calidad. En este caso son buenas prácticas:

• Dar un paso atrás y volver a mirar todo el proyecto, incluso replantearse alguna de sus fases.
• Revisar cómo han ido las cosas hasta ahora y cómo se puede mejorar el trabajo futuro sobre la base de lo que ya ha cambiado.
• Sentir y medir el estado personal (autocontrol, inteligencia emocional, comparativa temporal, proyección del yo, etc.)
• Sentir y medir el estado de los miembros del equipo (empatía, tendencias grupales, compartir, encuestas no formales, etc.)
• No significa hacer cambios constantemente, sino estar abiertos a sugerencias y críticas que ayuden al proyecto.

9 – Entregar con pendientes

Es contraproducente entregar en puntos intermedios o al final dejando elementos sin terminar (consciente o inconscientemente). Se recomienda actuar de la siguiente forma:

• Reunirse con promotores y otras figuras de interés para el proyecto antes de que se complete.
• Desarrollar una lista de control de cierres donde se identifiquen las tareas no acabadas que restan para la consecución.
• Establecer el modo y plazo en que se finalizarán y con ellas el proyecto en su totalidad.

10 – Demasiada Macro o Micro gestión

Exceso de control, comprobaciones no planificadas, integraciones de soluciones fuera de horario. Este problema se presenta usualmente en gestores de proyecto sin mucha experiencia o que no conocen las herramientas actuales de control e integración. La micro gestión es negativa para el proyecto y fatal para todo el equipo: no deja lugar al desarrollo ni a la iniciativa y causa descontento generalizado. Se recomienda evitar:

• No estimular los resultados.
• Subestimar las aportaciones de los miembros del equipo.
• Permitir elementos discordantes en el equipo.
• Obviar la conciencia de grupo.
• Concentrarse exclusivamente en los macro resultados y obviar los detalles y  las individualidades.

Éstos son algunos de los errores y malas prácticas más comunes en la gestión de proyectos. Se agradecerán contribuciones no recogidas en este artículo o en la bibliografía señalada para adicionar a la lista, describir más en detalle las cuestiones expuestas o estudiar otros casos, siempre respetando la brevedad y las diferentes opiniones.

Bibliografía recomendada

• Biafore, B. Successful Project Management. O’Reilly, 2011.
• Cobb, C. The Project Manager’s Guide to Mastering Agile. Wiley, 2015.
• Kuster, J. Project Management Handbook. Springer, 2015.
• Stepanek, G. Software Project Secrets. Apress, 2012.