Calidad y Tecnología: Las siete cosas que aprendí de PMP

Hace más de tres lustros recibí la formación para la preparación de PMP (Project Management Professional certification). No recuerdo la fecha exacta y, lo que es más lamentable, he olvidado también el nombre de formador. Era el presidente de PMI (Project Managment Institute) en España pero hasta ahí llego.

Fui un alumno participativo lo que equivale a decir rebelde y un tanto puñetero. Por aquél entonces era un Jefe de Proyecto con poca experiencia, acostumbrado a técnicas de gestión caseras (por no decir, chapuceras), muy diferentes de las propuestas por aquel organismo. Salí contento de la formación pero sin la más mínima intención de aplicar lo aprendido en el trabajo. Como decía el gran Obelix: "están locos estos americanos".

Sin embargo, algunas recomendaciones de aquél formador anónimo quedaron grabadas en mi cabeza y, poco a poco, las fui interiorizando y aplicando en mi trabajo diario.

Son siete lecciones, tamizadas por el tiempo y mi experiencia profesional. En estos años, la certificación PMP ha cambiado y yo también. Es posible que estas buenas prácticas hayan recibido un nuevo enfoque pero creo que lo aprendido aún sigue manteniendo cierta vigencia.

UNA TAREA UNA "PERSONA"

Para planificar un proyecto, PMBok@ (Project Management Body of Knowledge) propone su descomposición en tareas utilizando las famosas WBS (Workbreakdown Structures) que, más adelante, se combinarán con las OBS (Organizational Breakdown Structure) para crear la RAM (Responsability Assigment Matrix) conocida también como RACI (de las iniciales de los actores implicados: Responsable - Aprobador - Consultado - Informado)

Este proceso debe continuar hasta que cada tarea quede asignada a un sola "persona". Y en este punto llegó mi primera objeción. Consideraba que varias personas podían y debían colaborar para realizar una misma tarea.

El formador me explicó que, en este contexto, el concepto "persona" debe asociarse con el responsable del cumplimiento de los objetivos establecidos, con la única persona con la que el Jefe de Proyecto debe hablar para conocer el grado de progreso de una actividad. Si la tarea fuese especialmente compleja, será esta persona la encargada de subdividirla en otras y realizar las correspondientes asignaciones. Pero, desde el punto de vista de la jefatura de proyecto, este proceso es transparente. De no serlo, la descomposición realizada es, indudablemente, inadecuada.

Supongamos que un arquitecto necesita cavar un hoyo de ciertas dimensiones. Para acometer esta labor, contrata un equipo de excavación (excavadora, capataz, operador y asistentes). Aunque es evidente que, para realizar la excavación, varias personas deberán realizar diferentes trabajos, el arquitecto lo ve como un único proceso; un día camina por un terreno llano y al otro se encuentra con un hoyo. Si hay retrasos, será el capataz del equipo de excavación quién deba responder. Seguramente, alegará que el conductor ha enfermado o que se ha encontrado con alguna roca enterrada. Muy interesante, pero al arquitecto estos problemas deben resultarle indiferentes, el trabajo no está hecho y punto.

PARA PLANIFICAR, PREGUNTA

Por aquel entonces, consideraba el proceso de planificación como una responsabilidad exclusiva del Jefe de Proyecto. Su experiencia debería permitirle conocer con suficiente detalle cada actividad como para estimar cuanto tiempo sería necesario para completarla.

Sin embargo el formador aconsejaba justamente lo contrario.Tras subdividir el proyecto en actividades, es conveniente, si no imprescindible, solicitar a cada responsable una estimación en tiempo, coste y esfuerzo. Después el Jefe de Proyecto deberá valorarlas y asignar un grado de incertidumbre (un nivel de riesgo) en función de su experiencia y, si es afortunado, de los datos históricos de los resultados de tareas similares acometidas con anterioridad.

Es un proceso de negociación que concluirá cuando se alcance un consenso. Jamás deberían iniciarse los trabajos sin él.

Continuando con el ejemplo de la excavadora, lo lógico es preguntar al capataz cuanto tiempo va a tardar en hacer el hoyo. Por mucho que nos empeñemos, es evidente que él ha hecho mucho más agujeros que nosotros. Toca entonces evaluar la propuesta y comenzar el proceso de negociación. Quizás el capataz esté protegiéndose y proponga unos plazos un tanto exagerados (estimación pesimista) o puede que quiera complacernos y se comprometa a unos plazos que sabe no podrá cumplir (estimación optimista).

Toca negociar con él hasta encontrar una estimación que satisfaga a ambas partes. Y aún así habrá que ajustarla con un factor de incertidumbre que cubra factores como la probabilidad de lluvia, la posibilidad de encontrarnos con un terreno más duro del previsto o el número de errores que el contratista ha cometido en el pasado.

Este proceso de preguntar, negociar, consensuar y asignar un nivel de incertidumbre tiene una ventaja adicional: hace partícipe al responsable en la planificación y le compromete con los objetivos establecidos.

NO PREGUNTES "¿CÓMO VAMOS?"

Mi malestar continuaba en aumento. No entendía nada. Debía preguntar cuando no lo consideraba conveniente y no podía hacerlo para saber como iban los trabajos.

Sin embargo, conseguí comprender que de nada sirve preguntar "¿Qué tal vamos?". Nos dirán que bien, que ya hemos completado el 50% de los trabajos planificados, luego andaremos rondando el 70% y continuaremos así hasta que, justo cuando íbamos a entregar, comiencen los problemas. Es lo que se conoce como el síndrome del 90%.

Los responsables de los trabajos tienden a ocultar los problemas mientras consideren que aún tienen tiempo para resolverlos. No quieren molestarnos con los detalles así que siguen reportando avance hasta que se encuentran entre la espada y la pared.

Imaginemos al arquitecto preguntando "¿qué tal va el hoyo?" y al capataz respondiendo "fantástico, ya hemos excavado la mitad". Es una información interesante pero ¿de qué nos sirve?. Sólo necesitamos saber si estará acabado a tiempo para poder llamar a la hormigonera.

Para evaluar el avance de un proyecto debe fijarse un criterio claro y objetivo:

Evaluación Optimista: considerar que una tarea está completada al 100% nada más comienzan los trabajos. Requiere confiar en los equipos de desarrollo y el progreso reportado puede verse afectado por imprevistos pero es tan válida como cualquier otra.

Evaluación Pesimista: no asignar ningún progreso a una tarea hasta que esté completada. Tiene la ventaja de que no tendremos que rectificar un progreso ya reportado y el inconveniente de que siempre parecerá que vamos algo retrasados. Aún así, es mi preferida.

Evaluación Media: se asigna un 50% de progreso tan pronto comienza una tarea y se mantiene así hasta que es completada. En teoría combina las ventajas de las dos anteriores pero, desde mi punto de vista, es la menos adecuada (como dicen por ahí, "ni chicha ni limoná")

TODO ES DINERO

La gran batalla comenzó cuando el formador afirmó que para controlar un proyecto basta con analizar el estado del presupuesto. Le rebatí comentando que si el Jefe de Proyecto entrega a tiempo utilizando los recursos que le asigna la organización, ha cumplido su trabajo. Si ha resultado más caro de lo previsto, no es su problema. Era un ingenuo.

Continuó la exposición explicando cómo, comparando lo presupuestado con lo gastado, es posible determinar el grado de avance del proyecto y, lo que es más importante, prever futuras desviaciones en tiempo o esfuerzo.

Ir ajustado al presupuesto suele implicar que los trabajos han comenzado y finalizado cuando estaba previsto y que los recursos asignados se corresponden con los planificados. Si los excavadores se encuentran con una roca que retrase los trabajos, seguramente solicitarán un incremento del presupuesto. Analizando los costes en que hemos incurrido podemos saber si se han presentado problemas. En una primera aproximación el dinero nos permite obviar los detalles.

No voy a entrar en detalles sobre las diferentes técnicas que propone PMBok@ para el control de presupuestos. Simplemente una recomendación: primero mira el dinero y luego busca las explicaciones de las desviaciones.

NO HAGAS CASO AL CLIENTE

Una vez que has presentado una propuesta al cliente, incluyendo una planificación en tiempo, coste y esfuerzo, no debes cambiarla, diga lo que diga el cliente (no os asustéis, aclararemos este tema).

Imaginemos de nuevo a un indeciso arquitecto que, a mitad de excavación, decide que el agujero no está en el emplazamiento más adecuado. Cuando comente el problema al capataz, éste seguramente le responderá "no hay problema, dime dónde quieres que cavemos; te va a costar XXXX". Parece difícil imaginar que la empresa subcontratada para realizar los trabajos esté dispuesta a asumir el coste provocados por los errores del responsable del proyecto.

Esta situación, impensable en los proyectos de obra civil, es, sin embargo, frecuente en otros sectores.donde el cliente cambia continuamente los requisitos y realiza interminables propuestas de mejora (especialmente en el entorno del desarrollo software).

No es que no debamos atender estas peticiones. No es cuestión de entregarle un producto que no responda a sus necesidades. Pero los cambios en los requisitos implican cambios en la planificación y, sobretodo, un mayor coste que debe asumir el cliente (ver Los Clientes valoran la Flexibilidad de tu empresa, ¡Ten cuidado!) aprobando una nueva oferta.

NO OFREZCAS MÁS DE LO QUE TE HAN PEDIDO

Es frecuente pensar que, ofreciendo al cliente algún desarrollo adicional no ofertado, se consigue aumentar su grado de satisfacción con los trabajos realizados.

Si es una estrategia de la organización, puede ser una práctica aceptable siempre y cuando esté claramente diferenciada de los trabajos planificados y el cliente sea consciente de ella. Sin embargo, durante el desarrollo del producto es común descubrir áreas de mejora que podrían aumentar sus prestaciones o disminuir el coste de producción. Evidentemente, no es cuestión de ocultarlas, pero tampoco de implementarlas sin el conocimiento del cliente y, de nuevo, sin evaluar y aprobar los costes necesarios para emprender tales desarrollos.

Ofrecer más de lo esperado, intentar sorprender al cliente, es una cortesía que suele resultar bastante cara. Imaginemos al capataz comentando al arquitecto que ha decidido enlosar el agujero para hacerlo más resistente a humedades. El arquitecto estará encantado seguramente al no suponer ningún coste adicional. Pero, a partir de ese momento, considerará el enlosado como parte de los servicios contratados. Si llueve y las losas se derrumban exigirá responsabilidades al contratista a pesar de no haber pagado por el trabajo. No va a aceptar quedarse con un agujero derrumbado o gastar un euro más para retirar los escombros.

Ofrecer más de lo previsto sin modificar el presupuesto es una práctica conocida como Gold Platting y debe evitarse a toda costa (ver "Sorprender al cliente, ¿una buena práctica en la gestión de proyectos?").

NO ACEPTES UN PROYECTO SI SABES QUE VA A FRACASAR

Esta afirmación fue la gota que colmó el vaso de mi paciencia. Aquélla persona vivía entre alucinaciones en los Mundos de Yupi. La empresa gana una oferta, me asignan el proyecto, les digo que con ese presupuesto es imposible cumplir los plazos y que me niego a aceptarlo y, al día siguiente, estoy en la calle.

Sin embargo, y como siempre, tenía razón. Si sabes que no vas a cumplir con los plazos, que los recursos asignados no son suficientes también sabes que no obtendrás el margen esperado o incluso que tu empresa acabará perdiendo dinero. Tardarás más en patear las Oficinas de Empleo, pero el resultado va a ser el mismo.

Sin embargo, existe un solución sencilla para este dilema temporal: negociar con el cliente un cambio de alcance nada más comenzar los trabajos. Debes ser transparente y explicar las desviaciones que ya sabes se van a producir. Quizás no puedas pedir al cliente más dinero pero puedes hacerle comprender que tendrás que limitar las funcionalidades del producto en algún sentido si quiete que el proyecto llegue a buen puerto.

Aunque podáis pensar lo contrario, el cliente suele mostrarse comprensivo ante este tipo de situación. Quizás sepa de la dura negociación con compras o sea consciente de algunas indefiniciones en la especificación. En el fondo, él está tan interesado como tú en que el proyecto sea un éxito. El también debe responder de los problemas que puedan surgir.

También puede interesarte: