14/4/2015 Las siete cosas que aprendí de PMP

data:text/html;charset=utf­8,%3Ch2%20class%3D%22date­header%22%20style%3D%22margin%3A%200px%200px%201em%3B%20position%3A%20r… 1/4

jueves, 17 de julio de 2014

Las siete cosas que aprendí de PMPHace más de tres lustros recibí la formación para la preparación de PMP (Project Management Professionalcertification). 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élentonces era un Jefe de Proyecto con poca experiencia, acostumbrado a técnicas degestión caseras (por no decir, chapuceras), muy diferentes de las propuestas por aquelorganismo. Salí contento de la formación pero sin la más mínima intención de aplicar loaprendido 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 grabadasen 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 estosaños, la certificación PMP ha cambiado y yo también. Es posible que estas buenasprácticas hayan recibido un nuevo enfoque pero creo que lo aprendido aún siguemanteniendo cierta vigencia.

UNA TAREA UNA "PERSONA"

Para planificar un proyecto, PMBok@ (Project Management Body of Knowledge) propone su descomposición entareas utilizando las famosas WBS (Workbreakdown Structures) que, más adelante, se combinarán conlas OBS(Organizational Breakdown Structure) para crear la RAM (Responsability Assigment Matrix) conocida tambiéncomoRACI (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ó miprimera 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 objetivosestablecidos, con la única persona con la que el Jefe de Proyectodebe hablar para conocer el grado de progreso de una actividad. Si latarea fuese especialmente compleja, será esta persona la encargadade subdividirla en otras y realizar las correspondientes asignaciones.Pero, desde el punto de vista de la jefatura de proyecto, este procesoes transparente. De no serlo, la descomposición realizada es,indudablemente, inadecuada.

Supongamos que un arquitecto necesita cavar un hoyo de ciertasdimensiones. Para acometer esta labor, contrata un equipo deexcavació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 vecomo un único proceso; un día camina por un terreno llano y al otro se encuentra con un hoyo. Si hay retrasos, será elcapataz del equipo de excavación quién deba responder. Seguramente, alegará que el conductor ha enfermado o quese ha encontrado con alguna roca enterrada. Muy interesante, pero al arquitecto estos problemas deben resultarleindiferentes, 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

14/4/2015 Las siete cosas que aprendí de PMP

data:text/html;charset=utf­8,%3Ch2%20class%3D%22date­header%22%20style%3D%22margin%3A%200px%200px%201em%3B%20position%3A%20r… 2/4

necesario para completarla.

Sin embargo el formador aconsejaba justamente lo contrario.Tras subdividir elproyecto en actividades, es conveniente, si no imprescindible, solicitar a cadaresponsable una estimación en tiempo, coste y esfuerzo. Después el Jefe deProyecto deberá valorarlas y asignar un grado de incertidumbre (un nivel deriesgo) en función de su experiencia y, si es afortunado, de los datoshistó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 capatazcuanto 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 unosplazos un tanto exagerados (estimación pesimista) o puede que quiera complacernos y se comprometa a unosplazos 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 conun factor de incertidumbre que cubra factores como la probabilidad de lluvia, la posibilidad de encontrarnos con unterreno 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: hacepartí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 nopodí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 el50% de los trabajos planificados, luego andaremos rondando el 70% ycontinuaremos así hasta que, justo cuando íbamos a entregar,comiencen los problemas. Es lo que se conoce como el síndromedel 90%.

Los responsables de los trabajos tienden a ocultar los problemasmientras consideren que aún tienen tiempo para resolverlos. Noquieren molestarnos con los detalles así que siguen reportandoavance hasta que se encuentran entre la espada y la pared.

Imaginemos al arquitecto preguntando "¿qué tal va el hoyo?" y alcapataz respondiendo "fantástico, ya hemos excavado la mitad". Es una información interesante pero ¿de qué nossirve?. 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 lostrabajos. Requiere confiar en los equipos de desarrollo y el progreso reportado puede verse afectado porimprevistos pero es tan válida como cualquier otra.

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

14/4/2015 Las siete cosas que aprendí de PMP

data:text/html;charset=utf­8,%3Ch2%20class%3D%22date­header%22%20style%3D%22margin%3A%200px%200px%201em%3B%20position%3A%20r… 3/4

Evaluación Media: se asigna un 50% de progreso tan pronto comienza una tarea y se mantiene así hastaque es completada. En teoría combina las ventajas de las dos anteriores pero, desde mi punto de vista, esla 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 delpresupuesto. Le rebatí comentando que si el Jefe de Proyecto entrega a tiempo utilizando los recursos que le asignala 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 logastado, es posible determinar el grado de avance del proyecto y, lo que es másimportante, prever futuras desviaciones en tiempo o esfuerzo.

Ir ajustado al presupuesto suele implicar que los trabajos han comenzado yfinalizado cuando estaba previsto y que los recursos asignados se correspondencon los planificados. Si los excavadores se encuentran con una roca que retraselos trabajos, seguramente solicitarán un incremento del presupuesto. Analizandolos costes en que hemos incurrido podemos saber si se han presentadoproblemas. 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, nodebes 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. Cuandocomente el problema al capataz, éste seguramente le responderá "no hayproblema, dime dónde quieres que cavemos; te va a costar XXXX". Parecedifícil imaginar que la empresa subcontratada para realizar los trabajos estédispuesta a asumir el coste provocados por los errores del responsable delproyecto.

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 demejora (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 susnecesidades. Pero los cambios en los requisitos implican cambios en la planificación y, sobretodo, un mayor costeque debe asumir el cliente (ver Los Clientes valoran la Flexibilidad de tu empresa, ¡Ten cuidado!) aprobando una nuevaoferta.

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 gradode satisfacción con los trabajos realizados.

Si es una estrategia de la organización, puede ser una práctica aceptable siempre y cuando esté claramentediferenciada de los trabajos planificados y el cliente sea consciente de ella. Sin embargo, durante el desarrollo del

14/4/2015 Las siete cosas que aprendí de PMP

data:text/html;charset=utf­8,%3Ch2%20class%3D%22date­header%22%20style%3D%22margin%3A%200px%200px%201em%3B%20position%3A%20r… 4/4

producto es común descubrir áreas de mejora que podrían aumentar sus prestaciones o disminuir el coste deproducción. Evidentemente, no es cuestión de ocultarlas, pero tampoco de implementarlas sin el conocimiento delcliente 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 quesuele resultar bastante cara. Imaginemos al capataz comentando al arquitectoque ha decidido enlosar el agujero para hacerlo más resistente a humedades. Elarquitecto estará encantado seguramente al no suponer ningún coste adicional.Pero, a partir de ese momento, considerará el enlosado como parte de losservicios contratados. Si llueve y las losas se derrumban exigiráresponsabilidades al contratista a pesar de no haber pagado por el trabajo. Nova a aceptar quedarse con un agujero derrumbado o gastar un euro más pararetirar los escombros.

Ofrecer más de lo previsto sin modificar el presupuesto es una prácticaconocida 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 losMundos de Yupi. La empresa gana una oferta, me asignan el proyecto, les digo que con ese presupuesto es imposiblecumplir 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 acumplir con los plazos, que los recursos asignados no sonsuficientes también sabes que no obtendrás el margen esperado oincluso que tu empresa acabará perdiendo dinero. Tardarás másen patear las Oficinas de Empleo, pero el resultado va a ser elmismo.

Sin embargo, existe un solución sencilla para este dilematemporal: negociar con el cliente un cambio de alcance nada máscomenzar los trabajos. Debes ser transparente y explicar lasdesviaciones que ya sabes se van a producir. Quizás no puedaspedir 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 dela 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 puedansurgir.