Estimando con PERT, a fondo

0

Tal y como se lee en la primera frase de su artículo en la wikipedia, PERT es una técnica para la evaluación y revisión de programas (o proyectos). Realmente más que una técnica es un conjunto de técnicas. Hablamos de toda una metodología creada por la armada americana para la planificación de costes, plazos y riesgos asociados. Un trabajo muy completo en el que dos de las técnicas han destacado con el paso del tiempo sobre las demás. La primera de ellas, es el diagrama PERT. La seguida es la estimación PERT. Es de esa estimación PERT de la que hablaré en este artículo. Como siempre, no me quedaré en explicar la teoría que puedes encontrar en cualquier página o blog por Internet, sino a contaros mi experiencia personal y los consejos que extraigo de mi experiencia. Espero que os sirvan.

Concepto

Cuando estimamos el coste, los recursos necesarios o el tiempo de una actividad, tal y como adelanté en un artículo anterior, necesitamos estimador dos valores:

  • El valor esperado.
  • La desviación estándar de la medida.

El valor esperado es el promedio de lo que tardaríamos en ejecutar la tarea si la repitiésemos cientos de veces. Unas veces tardaremos más, otras menos, el promedio nos dará el valor esperado. Hablamos de la medida de esperanza, tal y como se define en teoría de la probabilidad. La desviación estándar es lo fiable que es esa esperanza. Es decir, lo que en promedio se suele desviar el resultado con respecto a la esperanza.

Si el párrafo anterior te ha parecido demasiado freak, lo ilustraré con un ejemplo:

En el desarrollo de una página web, el diseño de la home tiene una duración variable que no logramos ver de que depende. Tenemos bastantes proyectos a las espaldas y la PMO nos informa de que la esperanza es de 4 días con una desviación estándar de 2 días. Esto quiere decir que probablemente se tarde entre 2 y 6 días en realizar el diseño. Sería raro tardar más o menos que esos valores. Diríamos que creemos que se tardará 4 días, pero que a lo mejor nos equivocamos. En cambio si la esperanza es de 4 días, pero la desviación estándar es de medio día, significaría que lo normal es tardar de 3,5 días a 4,5 días, o lo que es lo mismo, que creemos que se tardará 4 días y que estamos bastante seguros de que será muy acertada nuestra estimación.

Como se puede ver del ejemplo, la desviación estándar nos dará lo que nos fiamos de nuestra medida y por lo tanto nos permitirá definir las reservas de contingencia necesarias. Si estamos muy seguros de que nuestra medida es correcta, las reservas serán pequeñas. Si en cambio la desviación es alta, nuestras reservas tendrán que aumentar para afrontar el riesgo de una mala estimación.

El problema es que si a priori estimar el valor esperado ya es complicado, no digamos estimar la desviación estándar. Pues para eso la estimación PERT viene en nuestra ayuda. Nos permite poner un número en ambos valores con un método que intenta ser lo más objetivo posible, para una tarea que normalmente está sujeta a un alto grado de subjetividad.

PERT permite obtener el valor esperado y la desviación estándar en una estimación de forma objetiva

Por supuesto que una estimación objetiva es muy complicada, siempre habrá un factor subjetivo. Pero el método nos permite intentar ser lo más objetivos posibles. Esto tiene muchas ventajas, siendo quizás la repetibilidad y la oportunidad de mejora continua que representa.

Por último, la desviación estándar suele representarse con la letra sigma,  \sigma^{}_{}, por lo que muchas veces hablaremos de “la sigma”, para acortar.

Profundizando en la sigma

Si dominas el concepto de desviación estándar, puedes saltarte este capítulo. Si no, te animo a que lo leas para entender mejor este valor.

Como ya hemos dicho la desviación estandar es lo que “se suele desviar” el resultado de la estimación. Pero esto es muy vago. La verdad es que la sigma tiene un significado muy concreto. Vamos a revisarlo.

NOTA: A partir de este momento asumiré que la distribución es normal. Si no sabes lo que significa esto, no te preocupes, sólo lo digo para evitar comentarios sobre las afirmaciones que digo a continuación, ya que sólo son aplicables a una distribución normal.

Tenemos un valor esperado y una sigma. Con estos valores estamos diciendo que la mitad de la veces tardaremos menos que el valor esperado y que la mitad de las veces tardaremos más. Es decir, hay una probabilidad del 50 % de que tardemos menos que el valor esperado. Y del 50 % de que tardemos más. La sigma nos dice que aproximadamente 2 de cada tres veces no nos separaremos más del valor esperado que en esa sigma. Es decir, si el valor esperado es 5 días y la sigma es 1 día; 2 de cada 3 veces estaremos entre 4 y 6 días. Como lo que nos importa es controlar el caso peor, podemos decir que no nos retrasaremos más de la sigma el 84 % de las veces. Hay un riesgo de retrasarmos más de la sigma del 16%. Es decir, con el ejemplo anterior, sólo el 16 % de las veces tardaremos más de 6 días. Se conoce como dos-sigma al doble de la sigma. La probabilidad de retrasarnos en más de dos-sigma es aproximadamente del 2 %. Con el ejemplo anterior, sólo el 2% de las veces, tardaremos más de 7 días (5 esperados + 2 días de dos-sigma). Y entendemos como tres-sigma al triple. Sólo el 0,1 % (o sea una de cada mil veces) tardaremos más que tres-sigma. En el ejemplo, sólo una de cada mil veces tardaremos más de 8 días.

Esto hace que tomar la sigma como un valor razonable de por donde se mantendrán los valores sea lo habitual (acertando el 66% de las veces). Y si queremos seguridad completa, ampliaremos la horquilla a tres-sigma, en la probabilidad de fallar es muy baja.

La siguiente figura expresa claramente estos valores:

Los valores iniciales

Bueno, vamos al ajo. El objetivo es estimar la esperanza y la sigma de la duración de una tarea (él método se puede utilizar también para otros valores como coste o recursos). Para ello debemos calcular tres valores:

  • Valor probable: El tiempo que se suele tardar con más frecuencia.
  • Valor optimista: El tiempo mínimo que se puede llegar a tardar.
  • Valor pesimista: El tiempo máximo que se puede llegar a tardar.

La manera de estimar estos tres valores será diferente en cada caso, dependiendo del conocimiento que tengamos. A priori yo me he encontrado con dos casos muy diferentes:

  • Disponiendo de lecciones aprendidas
  • Sin disponer de lecciones aprendidas

Es decir, ¿Hemos hecho tareas similares en el pasado? y casi más importante ¿Hemos documentado las duraciones? Si disponemos de información sobre estos casos podremos estimar los valores de forma mucho más objetiva. Si no, entrarán en juego técnicas más subjetivas.

Por valor optimista y pesimista hablamos de valores extremos. Es decir, hablamos de desviaciones de tres-sigma. Es decir, hablamos de que sólo una de cada mil veces tardaremos más que el pesimista, por ejemplo. Es decir, hablamos de pesimista de verdad y de optimista de verdad.

Hay que tener en cuenta que de rebote estamos mapeando los riesgos a las estimaciones. Es decir, estamos haciendo una estimación cuantitativa de los riesgos. Esta estimación cuantitativa de riesgos es lo que determinará el valor de la sigma.

Obtener los valores sin lecciones aprendidas

En estos casos no hay otra que tirar del conocimiento experto. Es decir, buscar a gente que, aunque no lo haya documentado, tenga experiencia en tareas similares, o por lo menos pueda “hacerse una idea” de lo que se tarda en este tipo de tareas. En muchos casos hablaremos del técnico que va a realizar la tarea. Aquí es donde muchos Project Manager fallan (y donde yo he fallado en el pasado, que no soy un bicho raro), ya que transfieren la responsabilidad de la estimación al técnico. Hay que entender que un técnico no es un Project Manager y que le estamos pidiendo que haga algo para lo que no ha sido entrenado. Hay varios aspectos que se pueden dar cuando le “encargamos” a un técnico que estime:

  • El técnico puede no saber lo que le pides, por lo que puede ponerse muy optimista o pesimista. Es necesario hacerle preguntas claras o no sabrá responderlas.
  • A muchos les entra un canguele especial cuando les pides un número. Se lo toman como si les pidieses que hiciesen ellos el nudo de la soga con el que se van a ahorcar. ¿Y si luego tardo más de lo que digo? ¿Me tendré que comer el marrón?. Hablamos de estimar tiempos, no de transferir responsabilidades.
  • No son conscientes de lo importante que es el trabajo que se les pide, por lo que algunos se lo toman a la ligera, como si se tratase del trabajo burocrático “de los jefes”, de los que “juegan a gestionar proyectos”. No como ellos que hacen “el trabajo de verdad”.

Ojo, que no estoy diciendo que sean bichos raros o que les eche la culpa de algo. Todo lo contrario. Conseguir la estimación es nuestra responsabilidad, no la suya. Por lo que hay que tener claro que implicarles es para ayudarnos, no para quitarnos el muerto de encima. Y que ellos no están formados para ello.

Para evitar estos problemas, yo lo que hago es plantear preguntas directas:

  • ¿Cuánto creemos que tardará la tarea?
  • Si todo fuese bien, ¿Cuál es el mínimo que se podría llegar a tardar?
  • Si todo saliese mal, ¿Cuál es el máximo que se podría llegar a tardar?

Si podemos hacer las preguntas a más de uno y luego comparar, mejor.  Hay que explicar que el mínimo, es un mínimo para el caso mejor que se puedan imaginar. Lo mismo que el máximo. Y fijémonos en el orden de las preguntas. Primero pregunto cuanto crees que tardarás. Yo lo suelo acompañar de “a lo mejor tardar más o menos, pero ¿Qué crees que es lo normal?”. Eso ya les quita el miedo de pillarse los dedos, porque estamos dejando claro que se puede tardar más. Después en las otras dos, se quedan todavía más tranquilos, porque te dirán valores de mínimo y máximo con los que estén cómodos.

Un aspecto importante es el tamaño de estas tareas. Hay que despiezar las tareas al máximo posible, que tengan sentido. Es mejor pedir la estimación del coste de cada pantalla de la aplicación que de un módulo completo. Por norma una tarea que se tarde un mes o más en realizarla es candidata de dividirse (a veces no se puede, pero otras sí). Una estimación basada en juicio de expertos es más exacta cuanto más pequeño sea el trabajo a realizar. Nuestra cabeza tiene un límite y es capaz de imaginarse mejor el trabajo de un día que el de un mes.

Otra cosa importante es pedir que te justifiquen en qué se han basado cuando ponían los tiempos de los casos optimistas y pesimistas, es decir, que te digan que riesgos u oportunidades han detectado, a fin de tener también en la misma ronda un input importante para la gestión de riesgos. De la misma manera hay que comunicar los riesgos que ya conocemos al técnico o técnicos que van a realizar esa estimación. Primero porque los sitúa a la hora de saber qué es lo que les estas pidiendo, segundo porque los incluirán en sus estimaciones. Yo me he encontrado con técnicos que al pedirles la estimación, para el caso pesimista me han dicho 5 días. Después les digo ¿Has tenido en cuenta el caso en el que el cliente no le gusta el resultado y nos lo cambia como ya pasó en el proyecto del año pasado? En ese momento me contestan cosas como “Buah! pero eso es ponerse muy pesimista. Si nos ponemos así, nos podemos ir a 15 días!” Pues es precisamente eso de 15 días lo que quiero oír.

Al final, con esto habremos obtenido los tres valores sin tener conocimiento previo, sólo con “juicio de expertos”.

Como comentario en las estimaciones basadas en juicio de expertos es normal que la estimación óptima y la probable sean muy similares o incluso iguales y que la pesimista se vaya de madre. Incluso hay ocasiones en las que la optimista puede ser 0 (es posible que no haya que hacerlo). Todo esto es normal y no debe preocuparnos.

Obtener los valores con lecciones aprendidas

Ya tenemos casos de tareas similares. Algunas veces hablaremos de tareas comparables, como en el ejemplo de diseñar la home de una web. En otros hablaremos de tareas relacionadas, pero que no son comparables, como por ejemplo programar una pantalla (dependerá de cuantas tablas, lógica que aplique o elementos gráficos haya que incluir).

Veamos primero el caso fácil, tareas análogas. En estos casos yo propongo eliminar el 10 % de resultados más extremos y hacer la media del resto: esto será el más probable. Después cogeremos el máximo y el mínimo que se haya obtenido nunca y los usaremos como estimaciones optimistas y pesimistas. Os pongo un ejemplo de como lo apliqué hace poco:

En un servicio de soporte que dirijo el equipo formó parte de un proyecto de subida de versión de un programa crítico para el negocio. La subida ponía en peligro múltiples integraciones. El equipo se encargó de las pruebas de validación de todas las integraciones. Algunas duraron un par de días. Otras duraron semanas. No por que fuesen más complejas, sino porque surgieron múltiples problemas por el camino (funcionales que no colaboran, entornos de preproducción no disponibles, fabricantes de la aplicación con la que se integra que no colaboran, problemas de permisos, etc.). Durante las pruebas el equipo anotó el esfuerzo necesario y tiempo invertido en realizar cada una de ellas. Actualmente estamos inmersos en un proyecto similar y se me solicitó estimar el tiempo para las pruebas. Aproveché la lección aprendida y calculé de forma 100% objetiva los valores probable, optimista y pesimista, para poder aplicar luego PERT.

El caso en el que las tareas no son análogas, pero si relacionadas, debemos encontrar un sistema que nos permita parametrizarlo en base a características de la tarea. En desarrollo, por ejemplo, siempre podemos contar con parámetros como el número de tablas, número de campos, número de roles de usuario, etc. Con eso en mano la fórmula paramétrica no sólo nos debe dar el valor probable, sino también el optimista y el pesimista.

Lo reconozco, nunca he tenido la oportunidad de elaborar un sistema paramétrico que estime los tres valores. Pero ha sido por falta de lecciones aprendidas. De tenerlas, si se tienen los suficientes conocimientos de estadística, no es muy complicado.

Si no, siempre podemos utilizar el juicio de expertos y hacerlo obviando las lecciones aprendidas, pero perdemos dos grandes ventajas:

  • Las estimaciones a partir de las lecciones aprendidas son mucho más fiables que las que provienen del juicio de expertos.
  • Las estimaciones de lecciones aprendidas son más objetivas, con todas las ventajas que la objetividad nos ofrece.

Aplicar el método PERT

Bueno, ya tenemos los valores probable, optimista y pesimista. Ahora aplicaremos dos simples fórmulas que nos darán el valor esperado y la sigma:

PERT

En donde los índices de t se corresponden con:

  • e: el valor esperado
  • o: el valor optimista
  • m: el valor probable
  • p: el valor pesimista

La fórmula es directa y de fácil aplicación. La idea es calcular el valor esperado y la sigma de todas las tareas.

Combinando el PERT de distintas tareas

Bueno, ya tenemos el PERT aplicado a todas nuestras tareas. El siguiente paso es “sumar” el resultado de dos tareas. Es decir, queremos saber el tiempo que tardarán dos tareas consecutivas (o dependientes). O queremos saber el coste conjunto de dos tareas. Así tenemos que combinar las esperanzas y las sigmas, para obtener una esperanza y una sigma conjunta.

El primer caso, el de la esperanza, es fácil. Simplemente se suman. Así dos tareas consecutivas con esperanza de 2 días, vistas como un grupo tendrán una esperanza de 4 días.

El de la desviación estándar no es tan fácil. Hablamos de distintas tareas y de lo que se desviarán de la estimación. A priori el hecho de que una tarea se desvíe y otra no, son cosas independientes. Es decir, que haya tardado más en la primera tarea no implica que en la segunda tarde más. En este caso hablamos de tareas independientes estadísticamente. Pero no siempre es así. A veces el motivo que hace que una tarea se retrase, es el mismo que puede hacer que otra se retrase. Por ejemplo, el hecho de que el programador experto se ponga enfermo y el proyecto deba realizarse con programadores junior, no retrasará una tarea, sino todas. En estos casos hablamos de tareas dependientes estadísticamente. La forma de calcular la sigma del grupo de tareas es diferente dependiendo de si son dependientes entre ellas o no.

Tareas independientes

Si las tareas fuesen totalmente independientes no se pueden sumar las sigmas, hay que aplicar un poco de mates, ya que es muy improbable que todas salgan mal. La forma de caluclarlo es la siguiente: Calcularemos el cuadrado de todas las sigmas, sumaremos el resultado y haremos la raiz cuadrada de esa suma. Esa será la sigma para todo ese conjunto de tareas. Veámoslo en un ejemplo:

Tenemos tres tareas con sigmas 2, 2 y 1 respectivamente. Calculamos el cuadrado de todas ellas: 4, 4 y 1. Los sumamos, obteniendo 9. Hacemos la raiz cuadrada y nos sale 3. Así la sigma conjunta de las tres tareas es 3 y no 5 (que sería la suma de las sigmas). 

Así, en el ejemplo, la probabilidad de que nos retrasemos más de 3 días en el grupo de las tres tareas es del 16 %.

Tareas dependientes

Si las tareas son completamente dependientes, significa que todas se van a retrasar o adelantar en la misma medida. Así la sigma resultante es la suma de todas las sigmas. En el ejemplo que he puesto en el caso de independientes, hablaríamos de una sigma de 5.

Vamos a ver si soy capaz de explicarlo de forma conceptual. En el caso de independientes algunas tareas irán mal y otras bien. Lo que como gestores nos da miedo es que todas vayan mal, y eso no es muy probable. Con lo cual la sigma se hace más pequeña (medición más fiable). En cambio en el caso de que sean dependientes, sí que es más probable que todas vayan mal. De hecho si una va mal, todas irán mal. Por eso la sigma es más elevada.

El caso en los proyectos de TI

En el caso de proyectos de TI la experiencia me dice que las estimaciones que hacemos en las tareas no son totalmente independientes, pero tampoco son completamente dependientes. Hay riesgos que aplican a todas las tareas y riesgos que sólo aplican a una tarea. Por ejemplo, podemos tener un cliente más quisquilloso de lo común, que nos retrase todas las entregas. O podemos haber entendido mal un requisito que nos retrase una única tarea. Así que tenemos un mezcla entre ambos mundos.

Con esto en mano lo que hago yo es combinar la sigma de las dos maneras anteriores y hacer el promedio. Esto es como decir que hay una ligera dependencia entre tareas.

Volviendo al ejemplo de las tres tareas con sigmas 2, 2 y 1. Al combinar la sigma como tareas independientes se obtiene 3. Al combinarla como dependientes se obtiene 5. Así consideraremos un valor promedio entre ambos, de 4.

Utilizando el resultado

¿Y ahora como utilizamos esas sigmas y esas esperanzas? Pues de forma muy sencilla. Primero hacemos la planificación ignorando las sigmas, sólo usando los valores esperados. Con esto estimamos todo: recursos, plazos, presupuestos, … y conformamos la línea base.

La sigma la usaremos para las reservas. Para el presupuestos haremos la sigma combinada de todas las tareas y obtendremos la sigma de nuestro coste. Para el plazo haremos la sigma combinada de las tareas que están en ruta crítica, obteniendo la sigma de los plazos. Yo recomiendo traducir esta sigma directamente como reservas de contingencia (sólo en un 14% de los proyectos no cumpliremos). Pero la decisión dependerá de la política de cada organización. Si estamos dispuestos a asumir más riesgos podemos coger media sigma o incluso no poner reservas. Si en cambio queremos blindar el proyecto, podemos optar por usar dos-sigma o incluso tres-sigma para establecer las reservas.

En un proyecto hay tres tareas A, B, C. A tiene una duración esperada de 10 días, con una sigma de 2. B tiene una duración esperada de 5 días con una sigma de 2. C tiene una duración esperada de 20 días con una sigma de 2. B y C tienen como predecesora a A. Con esto la ruta crítica es A-C, con un tiempo esperado del proyecto de 30 días. La sigma de la duración del proyecto sería de 3,4. Dirección nos informa que debemos dar un plazo muy fiable, ya que el coste de acabar más tarde de lo planificado sería muy elevado. Decidimos poner una reserva de tres-sigma. Por lo tanto se indica un plazo de 40 días, incluyendo el colchón de 10 días (3*3,4).

En el mismo proyecto el coste es de 1.000 € por día de trabajo en cada tarea. Por lo tanto el coste esperado es de 35.000 €. La sigma combinada es de 4.000 €. La política de la organización es establecer las reservas en la desviación estándar. Se establece el presupuesto en 39.000 €, incluyendo 4.000 € de reservas.

Un cliente nos encarga un proyecto cuyo coste se estima en 10.000 € con una sigma de 2.000 €. El gestor de cuenta nos dice que el precio ofertado será clave y que el proyecto es estratégico, por lo que se pueden asumir riesgos del 50% (es decir, que la probabilidad de superar el presupuesto sea del 50%). Con esto en mente presupuestamos el proyecto a 10.000 € sin reservas.

Conclusión

Esta metodología nos permite traducir rápidamente los riesgos a reservas y de una forma mecánica y objetiva. Además nos permite evitar “hinchar” presupuestos sin que quede claro. Sinceramente a mi me ha ayudado y me está ayudando mucho a hacer estimaciones que cada vez son mejores.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios