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”.

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.