Con criterio de Project Manager

El tiempo ha llegado en que el producto final de nuestro proyecto sea entregado al cliente, pero dado que experimentamos literalmente cientos de cambios en la definición y dado que nunca fue autorizado un cambio en la fecha de entrega, el producto final se redujo a contar con un porcentaje de la funcionalidad original.
Permítanme hacer un paréntesis con respecto a esto.

Hace tiempo, cuando trabajaba en otra compañía, acostumbraba bromear con los clientes acerca de los entregables y les decía: “Normalmente solo puedo satisfacer dos de las tres variables siguientes: Costo, Calidad y Tiempo… Si necesitas que el proyecto acabe rápido, probablemente tendremos que sacrificar la calidad y/o tendrás que pagar más. Si necesitas que salga rápido Y barato, entonces no tendrá mucha calidad. Si requieres que el producto tenga mucha calidad pero a bajo costo, entonces nos vamos a tardar en entregarlo”. Haz las combinaciones que quieras… aquellos que han trabajado en proyectos me podrán entender.
En Project Management se habla de la muy conocida triple restricción: Tiempo, Alcance y Presupuesto (o recursos). Comunmente encontramos un diagrama con un triángulo equilatero en el que cada una de las tres palabras (restricciones) se encuentran dibujadas en cada vértice del triángulo o en cada lado (como la imagen que anexo). La lectura a este diagrama es la siguiente: el Director del Proyecto debe asegurarse de que el cliente reciba todo lo que se prometió usando solamente el presupuesto establecido y dentro del tiempo estipulado al inicio del proyecto. En referencia al triángulo existe otra palabra, pero esta va al centro del mismo, y esa palabra es Calidad. Cualquier cambio en una de esas variables impacta a las otras y por ende a la calidad.
De tal forma que antes no estaba tan equivocado con mi broma de las tres variables, pero mi enfoque era incorrecto: si quieres ser un profesional deberas entregar todo dentro de las tres restricciones y no solo dos.

Regresando al tema de este post (después de un largo paréntesis), nuestro equipo fue restringido en tiempo, pero nos liberaron la variable del presupuesto, de tal forma que podíamos agregar más gente al proyecto (incurriendo en más gastos) pero deberíamos entregar en el mismo tiempo acordado. También acordamos entregar un núcleo de funcionalidad básico que satisfaciera las necesidades más apremiantes y que en versiones posteriores del producto podríamos entregar el resto de la funcionalidad.
Entregamos el producto para ser probado por el usuario antes de pasar a una etapa de uso definitivo. Una vez que el usuario empezó a hacer uso de su nueva herramienta empezó a retroalimentarnos con respecto a la funcionalidad. Empezamos a manejar largas listas de issues y tuve la necesidad de reportar diariamente el status individual de cada problema. Estas revisiones duraron semanas antes de empezar a reducir la frecuencia de la revisión.
En ocasiones, como Gerente del Proyecto me ví reducido a un Administrador de Problemas y eso no me agradaba. ¿Qué había de aquellos gráficos de Gantt y de la administración de los recursos? ¿Cómo se relacionaba mi trabajo actual (perseguir desarrolladores de sistemas en busca de status y de la solución de los problemas) con el Team Development, Project Procurement y Earned Value? ¿Qué tenía que ver mi junta diaria de quejas del cliente con el Risk Monitoring Control, el Cost Budgeting o el Performance Reporting?
En un momento dado hice un alto para reflexionar porque parecía que nunca iban a dejar de salir problemas y que nunca terminaríamos con esas estresantes reuniones de status en las que reportábamos 5 pendientes resueltos y me avisaban de 10 más.
Estas son las lecciones que aprendí una vez que salí de mi momento de introspección.

1. Si el cliente pudiera resolver su problema el mismo, no te hubiera buscado.
2. Cuando un cliente te elige para resolverle su problema, su problema se convierte en tu problema y debes resolverlo como si fueras el.
3. Independientemente de lo que se hizo bien y de lo que se hizo mal, hoy te encuentras en una situación que tienes que afrontar, asegúrate de hacerlo con el criterio adecuado: si eres desarrollador de sistemas, afronta tu situación como desarrollador de sistemas; si eres Gerente de Proyectos, afronta tu situación como Gerente de Proyectos.

Inmediatamente dediqué un recurso a buscar defectos en nuestro producto de manera proactiva (Quality Assurance) para no esperar a que el cliente los encontrara – así eliminamos la ansiedad y redujimos la molestia del cliente.
Saqué de mi mente los problemas de bajo impacto y baja prioridad – eso me dio “oxígeno psicológico” y pude pensar mas claro.
Una vez dominados los problemas existentes, regresé a mi lista de entregables (WBS) y a la definición de calidad que había definido para cada uno de ellos. Verifiqué que estuvieramos cumpliendo con todo como lo habíamos prometido (Quality Plan).
Hice una agenda de fechas en las que estaríamos atendiendo cada issue mayor (Schedule) e hice un estimado para su completación (Estimate To Complete).
Así fue como llevé mi aburrida tarea de administración de problemas de regreso al campo del Project Management. Nuevamente y a manera de conclusión, si vas a administrar problemas, asegúrate de hacerlo con criterio de PM. Si te toca hacer un post en un blog, asegúrate de hacerlo con criterio de PM. Si estás planeando tus vacaciones, asegúrate de hacerlo con criterio de PM. Esto hace más probable el éxito y hace todo mas divertido.

Palabra final: Si no te gustan los proyectos con problemas, entonces estás en la profesion equivocada: Un cliente nunca viene a darte soluciones, dinero, beneficios o a invitarte a pasar buenos ratos, el cliente siempre llega con un problema que requiere solución completa, rápida y barata.