¿Es posible usar al mismo tiempo métodos tradicionales y Agile?

Soy Iván Rivera, PMP

Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me ocurra). Puedes leer un poco sobre mi formación aquí.

En un grupo de WhatsApp al que pertenezco surgió recientemente la conversación (eterna) de cuáles son las ventajas y desventajas de usar métodos tradicionales y Agile.

Yo quiero cambiar el sentido de la conversación analizando si es posible usar al mismo tiempo métodos tradicionales y Agile. ¿En qué condiciones?, ¿cuáles son las ventajas que se obtienen al final.

Es un tema recurrente y no es nuevo, por lo que voy a presentar algunas conclusiones que he recopilado de diferentes artículos:

¿Cómo puede recuperarse un proyecto que está fallando?

Soy Iván Rivera, PMP

Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me

ocurra). Puedes leer un poco sobre mi formación aquí.

Desde el repositorio de temas importantes propongo ahora este post de Brad Egeland que aunque fechado en 2013, es un tema que no pasa de moda.

Como dice Brad, ningún administrador de proyecto quiere estar en un proyecto fallido o hacerse cargo de un proyecto fallido, a menos que tenga complejo de Superman y guste de tratar de salvar el día. Pero es una realidad de la profesión de Administración de proyectos: más proyectos fracasarán que triunfarán. Varias encuestas han encontrado que entre el 50 y el 75% de todos los proyectos fracasan en algún grado, ya sea por temas de presupuesto, de cronograma, de satisfacción del cliente o simplemente por la incapacidad de entregar la solución planificada.

Lo que Brad sugiere es planificar cómo tratar con los problemas y riesgos en los proyectos y tener algunas estrategias clave para revertir aquellos proyectos que parecen dirigirse rápidamente hacia el fracaso. Si bien las formas específicas de arreglar un proyecto fallido dependerán de los problemas particulares que este enfrentando, Brad sugiere tres estrategias generales e innovadoras con un buen grado de éxito para ayudar al Administrador del proyecto a llegar al corazón de los problemas, mejorar la situación con un cliente insatisfecho u obtener la cooperación necesaria de los involucrados en el proyecto para volver a encaminar el proyecto con diferentes grados de costo y esfuerzo.

¿Como alinear al equipo de trabajo?

Desde la página de Project Times propongo ahora el siguiente post en el que Dana Brownlee nos señala cómo alinear al equipo de trabajo usando un Acta de Equipo (Team Charter).

Dana describe una situación conocida por cualquier Administrador de Proyectos: miembros del equipo que parecen seguir sus propias reglas, no entregan lo prometido, entienden mal o malinterpretan las tareas y/o solicitudes, se quejan de prioridades poco claras, etc.

Señala también que sobre todo en las primeras etapas de desarrollo del equipo (aunque también durante etapas posteriores), hay equipos disfuncionales que simplemente no están "en la misma página". Este problema tiene diferentes causas: no desarrollar las habilidades adecuadas en el equipo, falta de liderazgo o de apoyo ejecutivo, procesos interrumpidos, confundir las decisiones políticas, cambio constante, o la falta de comunicación organizacional, etc. Debido a que las causas de la disfunción suelen variar, rara vez hay solución única. Sin embargo, el Acta de Equipo puede ayudar a aliviar muchas de estas cuestiones. Dana dice que la ha trabajado con éxito una y otra vez... Y que si el equipo no tiene una, es como un barco sin timón.

Diez consejos para (facilitar) la administración de proyectos

photo © 2007 Sam Churchill | more info (via: Wylio)

Ahora Pat Gray nos propone desde Helium: Diez consejos para  (facilitar) la administración de proyectos.

Pat inicia comentando que si bien es cierto que la administración de proyectos es gratificante, también está llena de tensión, peligros y desastres potenciales.

El éxito en un proyecto difícil se consigue haciendo feliz al cliente, a la gerencia (sus jefes) y al equipo de trabajo y se puede lograr siguiendo los sencillos consejos que nos propone Pat:

¿Por qué fracasan los proyectos de TI? (Segunda parte: Las razones de Standish Group)

Un segundo artículo titulado “Why a project fails?” de Amit Sarkar refiere a un estudio de Standish Group cuyos resultados muestran que las diez razones más frecuentes por las que fallan los proyectos de TI son:

1. Mala planeación. Los administradores tienden a pensar en la planeación como una pérdida de tiempo con el argumento erróneo de que es mejor ocupar el tiempo actuando que planeando.

2. Objetivos y metas poco claras. Esta causa también aparece en el post anterior. En este caso la causa se atribuye a que muchos proyectos de TI se elaboran en forma progresiva y se planea por oleadas.

¿Por que fracasan los proyectos de TI? (Primera parte)

Recientemente Computer Weekly publicó un artículo de Tony Collins llamado: Las 5 causas por las que fracasan los proyectos de IT, desde el punto de vista del asegurador.

Tony menciona una mesa de trabajo organizada en Londres por la publicación y una empresa aseguradora el pasado 24 de noviembre, en la que se discutieron las 5 causas de fracaso en proyectos de TI según los registros de la aseguradora Hiscox, especializada en reclamos por proyectos de TI fallidos.

Al final del resumen me he permitido agregar algunas notas en base a mi propia experiencia.

Clientes problema

Recientemente publicaron en "Bussines Oportunities en español" una entrega llamada "Las empresas dejan ir a empleados problemáticos. ¿Es una buena idea hacer lo mismo con clientes problemáticos?".

En la mencionada entrega se habla de algunos tipos de cliente problema:

"...un cliente (que) exige un precio que destruye toda ganancia. O inclusive peor, cuando crea un caos en materia de precios en toda la industria. "

"...un cliente (que) exige un producto especial que envía a su personal de investigaciones y desarrollo en la dirección equivocada, al margen de su estrategia y de sus objetivos financieros. "

"...un cliente (que) le falta el respeto a sus empleados. "

A estos yo agregaría:

El cliente que durante la ejecución del proyecto regatea los precios, o el que exige mas recursos (o recursos mas especializados), sin justificarlos plenamente.

El cliente que exige al PMP que realice actividades fuera de su ámbito de competencia.

El cliente que constantemente quiere cambiar el alcance del proyecto, sin asumir su responsabilidad por ello (tiempo, costo).

Al respecto mi comentario al post original fue:

"De hecho, pretender conservar un cliente dándole la razón a toda costa se puede convertir la larga en una lápida no solo para el proyecto, sino para toda la empresa.

Antes de esa decisión se pueden considerar opciones que no necesariamente implican perder al cliente: se pueden buscar asociaciones de trabajo con otras empresas, trasladar el cliente a alguna empresa amiga, etc.

Pero al final, si no hay otra opción, se le debe dejar ir y aprender de la experiencia para poder continuar en el negocio."

Me parece que cada organización debe tener una política perfectamente delineada para atacar y resolver estas situaciones. A partir de esta política, el PMP debe trabajar con los clientes problema usando al máximo su capacidad de negociación tanto con ellos como al interior de su propia organización.

Y finalmente, no olvidemos que en muchas casos la decisión de emprender un nuevo proyecto o de dejar ir a un cliente no es tomada por el PMP, ya que él solo puede emitir recomendaciones al respecto. Corresponde a otra entidad (la oficina de proyectos, el consejo de administración, el dueño) respaldar o no estas recomendaciones.