Me pareció oportuno entretejer con nuestras pláticas sobre Gestión de Proyectos la presentación de la nube como herramienta de análisis y solución de conflictos (ver blog del lunes 20 de Abril: Revisitando la Nube de COVID-19) La Incertidumbre inherente a todo proyecto genera innumerables conflictos a lo largo de toda la aventura que representa cualquier tipo de proyecto. Al menos yo, no puedo decir que me he encontrado con un proyecto en el que no hubo alguna sorpresa. Y normalmente, estas ¨sorpresitas¨ provocan que cuestionemos nuestros planes. CONFLICTO: ¿seguimos con el plan o empezamos a improvisar un plan alterno?
Y ningún conflicto es más recurrente que el precioso momento de reportar nuestros avances en alguna tarea que forma parte de un proyecto.
¿Cómo rayos reportamos al avance de una tarea en la que esperamos que suceda alguna sorpresa? ... yo siempre he sentido que es como si comprara el boleto de una rifa y me pidieran que diera el avance sobre ganar el premio ... la respuesta inmediata es: ¡no tengo ni idea!
Y por el otro lado, también entiendo que debemos dar alguna idea sobre lo que estamos haciendo para que los demás puedan planear sus propias actividades. Ya ni los médicos de gran prestigio pueden darse el lujo de hacer esperar a sus pacientes indefinidamente. Existen tantas opciones hoy, que si no damos algún tipo de promesa que suene razonable, nuestro interlocutor buscará por otro lado una respuesta que le satisfaga.
Así que estamos atrapados en un conflicto recurrente: ¿cómo damos un reporte de avance creíble, que de tranquilidad a quien nos lo pida, pero sin meternos en un problema por generar expectativas que luego no podamos cumplir? ¡Ese sí que es un conflicto interesante! Y deberemos enfrentarlo recurrentemente durante nuestra participación en ese proyecto. ... ¿A qué hora se me ocurrió meterme en esto?
¡No temais! ... ¡Smith está aquí! ... (perdón, pero moría por usar esa querida frase de un programa de TV de mi infancia: Perdidos en el Espacio)
Muy bien, tomemos esto seriamente. Usemos un ejemplo. Tomemos las tareas de un proyecto:
Suponga que esta es la situación inicial de este proyecto. Todo empieza con una tarea del área de diseño para la que nos dieron un estimado de dos días. Luego sigue una tarea del área de prototipos y casi en paralelo hay una segunda tarea para el área de diseño. Por el momento fijemos nuestra atención solo en estas tres tareas. Hemos marcado con color rosa las tareas que conforman la Cadena Crítica y con color verde el Buffer del Proyecto.
Ahora asuma que han transcurrido 4 días y es momento de saber como vamos con este proyecto. Así que vamos con el personal de Diseño y les preguntamos: ¿cómo van con la tarea que les tocó para dar inicio a nuestro proyecto?
La respuesta tradicional será dada como un porcentaje de avance relativo a la tarea total. Imagino que esto fue provocado por los ingenieros que normalmente toman control de los proyectos.. Yo no se ustedes, pero a mí eso de calcular porcentajes se me complica. ¡La famosa regla de tres nunca fue lo mío! Y todavía peor si al cálculo de un porcentaje debo agregar un cierto factor de incertidumbre ... así que haré lo que todos terminamos haciendo: me fumaré un número y diré que ese es mi avance ... veamos, ¿que número suena como que si he avanzado, pero sin que me comprometa a mostrar algo muy avanzado? ... ¡ah!, ¡ya se!, ¡10%! ... diré que llevo 10% de avance...
Y aquí encontramos un tema por resolver. Reportar avances en términos de porcentajes no solo es impreciso, sino que además deja mucho margen para que la gente se ponga creativa ... lo que verdaderamente queremos saber es: ¿cuánto te falta para terminar?:
Así que pedimos reportes de avance NO como porcentajes de las tareas, SINO como número de recursos/días para terminar:
Diseño nos dice que terminó la primera tarea, pero de la segunda, pese a que llevan algo hecho, estiman que les faltan 4 días mas, que era la duración total que se había estimado para esa tarea. ¡Qué bueno que incluimos un buffer/colchón para proteger la Cadena Crítica!
Listo. Avance gratificado. ¿Y prototipos?, ¿cómo van con su tarea?, ¿Cuanto les falta a ellos para terminar? ...
¡Válgame Dios!, ¡no han podido hacer nada! ... eso quiere decir que toda la Cadena Crítica del proyecto se moverá a la derecha en el tiempo. Usaremos unas barritas rosas paralelas al plan para ir actualizando el estado del proyecto. Como podemos observar, el retraso de prototipos si mueve la Cadena Crítica, pero gracias al Buffer del Proyecto la fecha promesa de entrega no ha sido afectada.
Así son los proyectos. Cada tarea tendrá variaciones respecto a lo planeado. La gran pregunta es: ¿cuándo deberemos modificar nuestro plan y cuándo deberemos seguir adelante sin tomar medidas extraordinarias?
Reportar avances en número de unidades/días faltantes nos permite tomar mejores decisiones porque podemos ver mejor el impacto en el proyecto
Por favor ponga atención en el semáforo de tres colores que se encuentra en la parte baja de la derecha. Esa diagrama se llama ¨Fever Chart¨(Medidor de la Temperatura¨) Es muy útil para ir monitoreando el estado del proyecto conforme vayamos avanzando. Lo explicaremos en detalle en nuestro siguiente Blog.
Comentarios