miércoles, 21 de marzo de 2012

Medición del Progreso en Actividades con Costo Cero

¿Cuánto es el costo de esperar? A veces hay un costo financiero debido a la inversión congelada, otras veces hay costo indirecto relacionado con los recursos humanos esperando. Sin embargo, este costo indirecto es comúnmente modelado como un paquete de trabajo general separado. En el caso más común, hay actividades con costo cero; al menos, hay actividades sin “costo directo”. Esta es la razón porque Ud. puede encontrar el campo llamado “demora” o “tiempo de espera” en la mayoría de las herramientas de planeación de proyectos. Vea el siguiente ejemplo de la segunda mano de pintura.




El Valor Planeado, como comúnmente lo conocemos, no cambia durante el tiempo de espera. Esto es porque PV es medido en la dimensión de costo y el “tiempo de espera” no tiene costo. Como consecuencia, EV1 y EV2 tienen el mismo valor en t2. Viendo el Valor Ganado, pareciera que el proyecto está igualmente bien en ambas situaciones. Desafortunadamente, el proyecto está demorado un tiempo “d” en el segundo caso.


Alguien podría decir que la solución es observar la programación ganada o “Earned Schedule” (ES), porque ES es medido en unidades de tiempo. Bien, mi respuesta es no, de acuerdo a la forma más común de definir ES, la programación ganada falla también. Veamos, ES es comúnmente definido como “el momento en el que el Valor Ganado devengado debió ser ganado”. Entonces, cuanto t = t2, ES1 = ES2. No ayuda para nada.


Mi recomendación es usar un “ES medido” en lugar de un “ES calculado”. ¿Qué significa esto?. Bien, divida el Valor de la Programación Ganada en unidades de tiempo para cada periodo de medición. El progreso en la programación será automáticamente acreditado al final del periodo si el “tiempo de espera” ya ha comenzado, de otro modo, si la espera no ha comenzado, entonces ningún progreso será acreditado. Es imposible tener una Varianza de Programación (SV) en la dimensión del costo con este método pero es posible tener una Varianza de Programación en la dimensión del tiempo si la espera no comenzó a tiempo. Haciendo esto, cuando t = t2, ES1 = t2 y ES2 será t1.

Es importante advertir sobre gente tratando de vender “calculadoras de programación ganada”. Este problema continúa si Ud. usa una “calculadora de programación ganada”. Este problema sólo se soluciona usando “medición de la programación ganada”.

viernes, 6 de enero de 2012

Gestión de Programas vs Gestión de Proyectos

¿Ha pensado alguna vez que su Proyecto es, en realidad, un Programa?. "Si todo lo que tienes es un martillo, todo problema parece un clavo" [Bernard Baruch]. ¿Su problema es un clavo o un tornillo?. ¿Es posible que usted vea sus necesidades como un proyecto porque usted sabe sobre la gestión de proyectos?. De acuerdo con el PMBOK© del PMI®, un proyecto grande puede ser dividido en sub-proyectos. De acuerdo con "El Estándar de Gestión de Programas"© del PMI®, un programa es un "grupo de proyectos relacionados administrados de una manera coordinada para obtener beneficios y control no disponibles a través de la gestión de forma individual". Creo que a veces, en la gestión relacionada con "componentes" como un proyecto o un programa, es simplemente una decisión. Se puede administrar en dos maneras, pero probablemente esta será la decisión más importante que se tome en este proceso y va a aumentar o disminuir significativamente sus probabilidades de éxito.


En la Gestión de Programas hay "componentes" que pueden ser "proyectos" u otro tipo de trabajo, como "servicios continuos". Si usted necesita manejar algo que no puede ser definido como un proyecto debido a su carácter continuo, entonces usted no tiene un gran proyecto, lo que tiene es un programa.

 
En la Gestión de Programas se decide iniciar componentes, si ciertas condiciones son satisfechas. Usted no va a empezar a construir algo que nadie puede mantener u operar. En Gestión de Programas esto es siempre una actividad explícita y en Gestión de Proyectos depende del plan del proyecto. Si es necesario revisar el inicio y fin de las componentes de acuerdo con razones superiores, es probable que tenga un programa.

En la Gestión de Programas la promesa a los patrocinadores y a las partes interesadas se relaciona más con los beneficios que con el alcance. Por supuesto que un programa tiene un alcance, pero el énfasis está puesto en los beneficios en lugar de su alcance. Si la promesa suena como "dar vivienda a un centenar de personas" y Ud. está diseñando una solución para eso, o su promesa suena como "la generación de energía verde de manera innovadora" y Ud. está visitando las instalaciones innovadoras con el fin de decidir, entonces es probable que Ud. tenga un programa, no un proyecto.

Muchos programas se revisan en instancias de decisión cada año y reciben nuevos fondos después de esa revisión. Es por eso que un director de programa necesita estar preparado para los procesos de auditorías periódicas. Si el programa sigue siendo útil y sigue creando beneficios entonces, probablemente, va a ser extendido. Esto suena opuesto a la definición de proyecto y es muy común en la Gestión del Programas.

 
Es triste decir que muy a menudo veo Gerentes tratando de manejar Programas como si fueran Proyectos. Espero que hayan visto este artículo antes de ese momento, y usted está en el momento de decidir si su necesidad de un martillo o un destornillador.

domingo, 30 de octubre de 2011

Retraso desde la planeación de proyectos

Si usted tiene dos actividades paralelas que deben finalizar antes de una tercera, su proyecto probablemente se va a atrasar. Esto no es retórica y no una frase irónica. Es un hecho matemático.

Tomemos un plan de dos actividades que terminan en el mismo momento. Supongamos que la estimación de tiempo para que las actividades se hizo de manera que es igualmente probable para cada una de ellas terminar antes o después del tiempo t estimado final (la manera común). La probabilidad de que ambas actividades terminen en un momento menor o igual a t, será el producto de P (x <= t)P(y <= t), por lo tanto, ½ * ½ = ¼. Esto significa que es improbable acabar con las actividades en el tiempo.

El momento de finalización más probable se puede calcular sumando la duración media al instante de inicio. La duración es una variable no determinista. Tiene una distribución de probabilidad que depende de la naturaleza la actividad. Sin embargo, voy a mostrar este simple hecho haciendo matemáticas con dos actividades con diferentes distribuciones exponenciales que inician en momentos distintos. El resultado se puede ver en la siguiente imagen. Las dos actividades se pueden modelar como una. El momento más probable finalización de la actividad integrada se puede obtener añadiendo delta (δ) a la finalización de las actividades paralelas.



¿Cuál es la importancia de esto?. Este es un problema común haciendo planes. Hay proyectos condenados a llegar tarde desde la planeación. Haga uso de los amortiguadores de alimentación (feeding buffers) que son recomendados por la gente de "Cadena Crítica". Esta es una buena manera de evitar el problema. Por supuesto, usted también puede pedir a consultores como yo, que le ayuden con estos asuntos.
Demostración

Calculemos el tiempo final más probable para la actividad compuesta:


La función de densidad tiene la siguiente probabilidad:


La fórmula es:



El límite inferior es d porque la función es cero antes del límite:


Reemplazando con la función de probabilidad exponencial:



Reordenando:



Integrando:



El resultado es el fin de las dos actividades más un delta (δ):



miércoles, 14 de septiembre de 2011

Riesgo en la Gestión de Proyectos

Los evaluadores de proyectos tienen la tendencia a ser demasiado optimistas. Existen dos claras tendencias que rigen este comportamiento. Una viene de una característica natural del ser humano y la otra proviene de las acciones voluntarias, deliberadas y éticamente reprobables.

El optimismo a ultranza (Wishful Thinking) es la formación de creencias y la toma de decisiones de acuerdo a lo que podría ser agradable de imaginar en lugar de apelar a la evidencia, la racionalidad o la realidad. Manteniendo todo lo demás igual, los sujetos tienden a predecir que los resultados positivos son más probables que los resultados negativos. En un experimento sencillo, con el resto de las cosas en igualdad de condiciones, los participantes tienen una mayor probabilidad de escoger una carta que tenía una carita sonriente en el reverso que una que tenía el ceño fruncido.

De otro modo, los planificadores pueden deliberadamente subestimar los costos y sobreestimar los beneficios, con el fin de obtener aprobación de sus proyectos, sobre todo cuando los proyectos son grandes y cuando las presiones organizativas y políticas son altas.

No importa el origen del optimismo a ultranza, es necesario superarlo. El resultado de un proyecto siempre será mejor si se trabaja con la realidad. Permítanme decir algo importante: el riesgo es parte de la realidad. Aún más, el riesgo es parte del costo. Esta parte del costo se llama "Valor Monetario Esperado de Riesgo" (EMV) y existe.

Vamos a hacer una analogía física. La mecánica cuántica, también conocida como la física cuántica o la teoría cuántica, señala un límite fundamental en la precisión con la que ciertos pares de propiedades físicas, tales como la posición y el momento de una partícula, pueden ser a la vez conocidas. Esto también se conoce como principio de incertidumbre.

En la práctica, esto significa que trabajamos con la probabilidad de estar en una posición en un momento determinado. Esto no quiere decir que la materia no existe. No es así. Esto significa que hay propiedades que no se puede conocer con exactitud, en ciertas condiciones. Trate de patear un ladrillo de materia cuántica sin zapatos. Va a darse cuenta de que la materia existe. Se va a sentir exactamente del mismo modo que si se ignora el Valor Monetario Esperado de riesgo en el cálculo de ETC (estimado para completar) de un proyecto. Lo mismo es válido para calcular el presupuesto de un proyecto.

¿Cómo calcular EMV?


 

viernes, 19 de agosto de 2011

Supervisión de Programas

Recordemos primero que un Programa es "un grupo de proyectos relacionados administrados de manera coordinada para obtener beneficios y control que no pueden ser obtenidos a través de la administración individual". Interpretando la definición, hay acciones que podrían tomarse a fin de mejorar el resultado general, a pesar de que algunas de estas acciones podrían ser malas para un proyecto en particular. En este artículo voy a explorar las acciones básicas para un programa.

He utilizado algunas gráficas comunes para supervisar programas desde hace años, que voy a cambiar en este artículo, a fin de presentar un nuevo gráfico que tiene en cuenta conceptos de "programación ganada".

En el siguiente gráfico, cada burbuja es un proyecto. Como se explicó en la definición, se ha sustituido el eje-x por SPI, calculado como ES/AT en lugar de EV/PV. De lo contrario, según la definición clásica de SPI, todo proyecto va a terminar en el eje-y. Utilizando SPI = ES/AT, la posición final de un proyecto estará determinada por el desempeño temporal.



En este gráfico, el tamaño de la burbuja está determinado por ETC. De acuerdo con esto, cada proyecto va a terminar como un punto.

En el cuadrante siguiente, vemos el resultado de una mala estimación o una ejecución notable. En cualquier caso, es mejor analizar los detalles porque hay una oportunidad de mejora. Si el EAC confirma la tendencia, mi recomendación es reducir el presupuesto del proyecto amarillo como un control de cambios formal e incrementar el presupuesto del proyecto de color rojo en el cuadrante opuesto. Con el incremento del presupuesto, el proyecto de color rojo debe "comprar tiempo", que significa utilizar los recursos económicos nuevos para mejorar el rendimiento del tiempo.



En el cuadrante siguiente, vemos una situación más común. El proyecto azul tiene un mal desempeño de costos con un buen desempeño temporal. Si el EAC confirma la tendencia, mi recomendación es "vender servicios" al proyecto verde en el cuadrante opuesto. Esto significa que el proyecto azul tiene será retrasado a causa de una nueva carga de trabajo, pero esto no es un problema. A cambio, el proyecto verde va a liberar los recursos económicos que el proyecto azul necesita. Ambos cambios tienen que ser formales, de lo contrario vamos a patrocinar una mala práctica: la corrupción del alcance.



Las últimas acciones recomendadas son sólo ideas para una hipotética situación ideal. No siempre los cambios propuestos se pueden hacer. Naturalmente, el director del programa tiene que aplicar su propio criterio después de considerar las condiciones reales.

lunes, 1 de agosto de 2011

Análisis de Proyecciones en EVM

Es bueno revisar gráficamente las proyecciones en EVM con el fin de comprender las posibilidades y limitaciones. Las fórmulas más conocidas de EVM necesitan algunas correcciones para ser utilizadas en aplicaciones prácticas. Estas correcciones vinieron de la práctica de Programación Ganada o "Earned Schedule". Recordemos la definición de la Programación Ganada (ES), con una proyección del valor actual de EV sobre la curva PV. Podemos utilizar la "t" después de la sigla para diferenciar el Índice de Desempeño de Tiempo calculado con ES, del Índice de Rendimiento de Tiempo clásico calculado como EV/PV, como se puede ver en la siguiente imagen.
Click para maximizar


Utilizando triángulos similares, es posible obtener el Estimado al Completar (EAC) en la dimensión temporal, como se puede ver en la siguiente imagen.
Click para maximizar


Ahora podemos recordar que el valor máximo de EV es BAC. Entonces tenemos un punto final y con ello podemos trazar un pronóstico lineal de EV.
Click para maximizar


Análogamente, el índice de desempeño de costo puede ser utilizado como una razón para pronosticar el Estimado al Completar en la dimensión de los costos. Utilizando EAC es posible tener una proyección para el AC.
Click para maximizar


De esta manera, podemos tener una proyección de costos y tiempo. Esta forma de proyección de EV y AC toma el pasado como información suficiente para predecir el futuro. Un mejor resultado se obtiene si se clasifican las actividades de tal manera que los resultados anteriores se aplican únicamente a las actividades similares en el futuro.

lunes, 11 de julio de 2011

EVM Web

He creado Earned Value Management Web (http://evmweb.com), un sistema colaborativo basado en Web. Tiene “Control Integrado de Cambios” también. Es gratis para la mayoría de los usuarios. Temporalmente el sistema está disponible en inglés y español, y está abierto para beta testers.

Como muchos otros profesionales, descubrí EVM preparando mi examen de certificación para PMP. Encontré que es posible implementar un sistema EVM sobre muchos sistemas comunes de gestión de proyectos, posible pero no probable. Fui esclavo de la planilla de cálculo por años. Los esfuerzos de implementar el sistema fueron comparables con los beneficios. He encontrado que esos sistemas no están enfocados en EVM y me decidí a crear algo más especializado. Regístrese ahora. Espero recibir su opinión y ayuda para mejorarlo.

martes, 21 de junio de 2011

EVM para Grandes y Pequeños Proyectos

Ha gestionado alguna vez un pequeño proyecto. Por supuesto, los pequeños proyectos son la regla y los grandes la excepción. Sin embargo, la mayoría de nosotros ha aprendido cómo gestionar grandes proyectos y sólo algunos pocos han aprendido cómo gestionar los pequeños.
Si Ud. solo tiene experiencia en pequeños proyectos, no sienta vergüenza de aquello. Si Ud. no piensa que los proyectos rápidos y de poco presupuesto son difíciles, entonces probablemente no sabe mucho de proyectos. Ocasionalmente, he pensado que los buenos gestores de proyectos son realmente puestos a prueba en pequeños proyectos.
Es fácil decir qué debe tener una reunión de kick-off cuando Ud. tiene semanas y aun más para prepararla. Cuando solo tiene un par de días para prepararla, entonces no tendrá mucho tiempo para pensar en filosofía. En tal caso, es mejor saber hoy qué es necesario decir, porque no va a tener otra oportunidad.
¿Ha tratado alguna vez de supervisar un pequeño proyecto con EVM?. Bien, dígame si esto no le suena familiar: es casi imposible saber cuánto se ha gastado en el proyecto. Si no está de acuerdo con esto, piénselo nuevamente. Algunas de las principales razones son:
  • El primer reporte de contabilidad probablemente va a tardar tanto como el proyecto
  • La mayoría de las facturas son recibidas cerca del fin de proyecto
  • Los esfuerzos de recursos humanos son controlados contando (con los dedos de las manos) cuánta gente puede ver y comparando con cuánta gente fue planeada
Reciba algunas sugerencias de un experto en pequeños proyectos (yo):
  1. Manténgalo tan simple como sea posible
  2. Hay alguna forma de EVM que pueda ser usada en pequeños proyectos. Sí, la hay. EVM no significa que Ud. necesite medir cada hora gastada en su proyecto. Una buena manera de evitar la tarea de supervisar cada hora es definir valores medios y grandes unidades de esfuerzos, como mes-persona.
  3. Los métodos estándar de medición de EVM incluyen la alternativa LOE (Nivel de Esfuerzo). Esto significa que puede medir esfuerzos de recursos humano, como la gestión de proyectos, de tal manera de contabilizar automáticamente en la medida que el tiempo pasa.
  4. Otra simplificación es posible. Los Principios Contables dicen que un costo es contabilizado cuando ocurre. No importa si la factura fue impresa y, ciertamente no importa si esta llegó a sus manos. Defina al principio del proyecto una forma de contabilizar los costos, aun cuando los contadores puedan ir más lento.
Por supuesto, usar un buen y simple EVMS será de una gran ayuda para reducir los esfuerzos de supervisión de un proyecto. Recordemos que yo prometí el lanzamiento de un EVMS basado en web para julio. Estoy trabajando en ello.

jueves, 9 de junio de 2011

NASA propuso reducir requerimientos para Sistemas de Gestión de Valor Ganado (EVMS) para contratos de precio fijo (FFP)

De acuerdo a Federal News Radio, recientemente la NASA propuso reducir los requerimientos para establecer y mantener un Sistema de Gestión de Valor Ganado (EVMS) en el caso de contratos de precio fijo (FFP). Esto significa que, para pequeños proyectos FFP, no va a existir la necesidad de una aplicación completa de la conocida técnica.

He aplicado EVM en pequeños proyectos por varios años con una hoja de cálculo y una asistente. El “Practice Standard for Earned Value Management” del PMI tiene 50 páginas es fácil de leer y aplicar. El “ANSI/EIA-748-B-2007” tiene menos de 25 páginas y es igualmente fácil de aplicar. Sin embargo, he revisado algunos documentos públicos de la NASA a cerca de EVM y pienso que el sistema en grande y complejo. Probablemente, los procesos de la NASA fueron diseñados para proyectos de más de US$ 50 millones.

EVM es una buena técnica que combina mediciones de alcance, tiempo y costo en un único sistema integrado. Cuando se aplica adecuadamente, provee una alerta temprana de problemas de desempeño aun para pequeños proyectos. Es claro que la mayoría de los Sistemas de Gestión de Proyectos no están enfocados en EVM y no son de gran ayuda. Es por esto que estoy construyendo un simple EVMS basado en web, que va a ser lanzado en Julio de este año. Por favor envíeme un mensaje si desea convertirse en un beta tester para él.

domingo, 29 de mayo de 2011

Externalidades de la plataforma Deepwater Horizon de BP y la planta nuclear de Fukushima Daiichi

Una externalidad es un efecto positivo o negativo de algunos agentes económicos, no transmitido a través de cualquier cobro o de pago, que afectan al consumo o la producción de otros agentes. La contaminación y los riesgos generados por actividades peligrosas son algunos ejemplos de externalidades negativas.

Muchos proyectos son económicamente viables debido a la falta de control sobre las externalidades negativas. La plataforma Deepwater Horizon de BP y la planta nuclear de Fukushima Daiichi tienen algo en común: el tiempo ha demostrado que las externalidades fueron subestimadas.

¿Cómo calcular las externalidades de los riesgos de un proyecto?. Un estudiante no graduado de ingeniería puede hacerlo. El costo de las externalidades es la suma de los diferentes riesgos, multiplicado por el impacto de esos riesgos. El problema no es la forma de calcular los riesgos, el problema es la falta de voluntad para hacerlo.

El coste total y beneficio para la sociedad se definen como la suma de los beneficios económicos y los costos para todas las partes implicadas (las partes interesadas). Simplificando, la sociedad tiene que evitar participar en cualquier forma en los proyectos con un costo total esperado mayor que los beneficios esperados. Una buena manera de hacer esto es cargando un mal proyecto con el coste de las externalidades esperadas, convirtiendo ese proyecto en uno económicamente inviable.

Los proyectos son mi pasión. No estoy proponiendo dejar de hacer proyectos. Yo estoy proponiendo trabajar con responsabilidad social, realizando una buena Gestión de las Partes Interesadas.

Proponer proyectos con claras externalidades negativas, es una cuestión de ingenieros muy incompetentes y malas personas. Un buen Gerente de Proyecto tiene que ser consciente de las externalidades de sus proyectos. El Código de Ética y Conducta Profesional del PMI declara que "Tomamos decisiones y medidas basándonos en lo que mejor conviene a los intereses de la sociedad, la seguridad pública y el medio ambiente".