UNA PROGRAMACIÓN DÉBIL es una responsabilidad en la gestión de proyectos. Pocos gerentes de proyectos negarán ese hecho, porque más de unos pocos han sufrido las consecuencias de un sistema de programación endeble. Los gerentes exitosos entienden que un sistema robusto tiene un potencial significativo de control del proyecto más allá de sus aplicaciones fundamentales de planificación y medición del rendimiento. Incluso cuando la programación básica es relativamente fuerte, la gestión del proyecto puede beneficiarse de mejoras y eficiencias que maximicen la capacidad del sistema y los productos.

Cuando el control del proyecto es la función principal de un sistema de programación, la credibilidad es su atributo más importante. Un destino cierto aguarda al gerente de proyecto que debe depender de información menos que sólida. Un sistema que no es confiable o que está siendo manipulado puede ser peor para la gestión del proyecto que no tener programación en absoluto. Los gerentes experimentados saben que los métodos técnicos aplicados para producir la red de programación pueden influir directamente en la credibilidad de los productos de la red. Los sistemas de programación de referencia son sólidos en su aplicación de procesos detallados que aseguran consistencia y disciplina, ya que estos son los que sostienen la integridad y credibilidad de la red para proporcionar la base de un control de proyecto realista y completo. La aplicación de las mejores prácticas es cómo los "cachas" de la programación bien musculada destacan los sistemas delgados y enclenques en la playa de la gestión de proyectos.

¿Pero qué pasa con los sistemas que no están a la altura de los estándares de referencia? ¿Qué enfoques son adecuados para mejorar un sistema de programación existente que apoya la gestión de proyectos pero que no es del todo eficaz y eficiente en hacerlo? Nuestras recomendaciones abordan sistemas de este tipo, y son fácilmente adaptables a situaciones específicas. Excluyendo un conjunto central de seis, las sugerencias pueden implementarse por separado. El aumento de la programación puede abarcar tanto o tan poco esfuerzo como decida el iniciador. Ciertamente, puede ser incluso más extenso que la asimilación de todos los consejos presentados aquí. La clave es preservar las ganancias obtenidas y no dejar que se marchiten.

Un Conjunto de Mejores Prácticas Basadas en la Realidad

Estas recomendaciones evolucionaron a partir de una iniciativa de mejora de la programación para el sitio de Hanford del Departamento de Energía, emprendida para el Proyecto del Sistema de Remediación de Residuos de Tanques. El entorno gubernamental obligó ciertos requisitos y procesos para el programa en cuestión, y las recomendaciones se desarrollaron bajo un proceso para "diseñar" el sistema para lograr ciertos objetivos o resultados. Cada técnica prospectiva puede adoptarse o no, según cómo sirva para implementar o mejorar una función de programación que apoye objetivos discretos para el sistema que se va a mejorar.

Los pasos para avanzar el programa sujeto original fueron primero identificar los insumos dados y luego especificar los medios de programación que se esperaban resultaran en los resultados deseados. Los parámetros de entrada para el sistema precursor se definieron como infraestructura (herramientas y capacidad material para la programación), definición de actividades, controladores lógicos (compromisos, necesidad de integración, etc.) y tablas de tasas/disponibilidad de recursos.

Se esperaba que los resultados cumplieran con el objetivo blando—control del proyecto—y los requisitos más directos y duros: productos reales de programación/informes, redes que reflejen la integración con costos y alcance, y credibilidad. Los determinantes de credibilidad pueden establecerse como criterios para cualquier iniciativa de programación, basándose en factores comúnmente aceptados como impulsores para el sistema o proyecto particular. Más tarde, la revisión decisiva confirmará si los resultados del sistema han cumplido con los criterios. Por ejemplo, un impulsor de credibilidad puede ser la necesidad de gestión de la ruta crítica (como en el caso del gobierno). Los participantes determinaron qué criterios de programación ofrecían una base adecuada para la gestión de la ruta crítica y desarrollaron recomendaciones para sostener esa capacidad.

Aquí presentamos algunas de las recomendaciones que resultaron de esta iniciativa gubernamental. Estas sugerencias generalmente asumen un programa de gran tamaño que programa múltiples proyectos de duración superior a un año, utilizando software de computadora que calcula datos completos de costo/programación para la medición del rendimiento. Se presume que el sistema de programación apoya la resumida de una jerarquía de horarios; algún ciclo presupuestario predominante; la gestión de la línea base, incluyendo el control de cambios; y algún ciclo regular de actualización de la medición del rendimiento. Cualquier suposición, y los consejos relacionados con ella, pueden ignorarse si no se aplica a un sistema particular.

Propuestas de Aumento

Las recomendaciones pueden adaptarse y combinarse de múltiples maneras para acondicionar y fortalecer un programa de programación enclenque. Sin embargo, al igual que se advierte al liviano que consulte a un médico antes de emprender un ejercicio físico serio en un esfuerzo por muscularse, se advierte al gerente que desea implementar estas recomendaciones que considere cuán bien la situación del proyecto prevaleciente acomodará la iniciativa y si es necesario planificar el alcance y estimar los costos.

La implementación de los enfoques propuestos aumentará la efectividad y la eficiencia para mejorar continuamente la capacidad general del programa. Una estrategia central destinada a asegurar que el sistema de prerrequisito esencial es la base para todas las recomendaciones subsecuentes. Ciertas técnicas centrales y otras refuerzan directamente la programación como una función central de la gestión de proyectos. El impacto de cualquier recomendación en un programa existente depende del grado en que el sistema ya se conforma a la convención sugerida.

Estrategia Central

La estrategia central es fundamental para el éxito en el cumplimiento de los resultados requeridos para la programación: productos reales, integración con factores de costo y alcance, credibilidad. Especialmente para grandes proyectos, estos seis conceptos esenciales deben estar en su lugar para mantener la credibilidad y proporcionar una base adecuada para la gestión de proyectos.

• Aplicar el método de la ruta crítica para la programación, incorporando la lógica suficiente para integrar todos los niveles de programación; y restringir las redes solo cuando sea necesario para acomodar los impulsores de programación legítimos.
• Desarrollar niveles jerárquicos de programación desde arriba hacia abajo(preferiblemente con la estructura de desglose del trabajo como base para la integración vertical) y establecer redes de resumen que permitan la integración electrónica. Antes de proceder con cada nivel inferior de desarrollo, validar la red más reciente contra el horario de nivel superior del cual se derivó. Después de desarrollar todos los niveles, reportar el progreso solo en el horario de nivel más bajo y resumir electrónicamente el progreso para cada nivel superior.
• Cargar recursos en el nivel de programación más bajo disponible y prever la resumida de recursos. (Excepción potencial: la carga de recursos de nivel de esfuerzo puede designarse para una red específica únicamente, cuando una jerarquía permite esta limitación. Ver No. 4 a continuación.)
• Desarrollar estructuras de códigos estándar, hacer cumplir su aplicación consistente y asegurarse de que los diccionarios de red estén completamente desarrollados. La disciplina práctica en esta área es la base para la resumida en código. (Por ejemplo, codificar por estructura de desglose del trabajo y resumir para cada nivel. Ver No.1 a continuación.)
• Aplicar el control de configuración para establecer horarios basados como objetivos, limitar el acceso a las líneas base/objetivos y hacer cumplir un proceso de control de cambios en el horario. Considerar un proceso rutinario para el respaldo independiente—controlado por alguien que no sea el programador del proyecto—de los horarios basados, con aprobación y después de las actualizaciones.
• Proceduralizar los procesos de programación, abordando incluso los detalles mecánicos/técnicos que apoyan la ruta crítica y la credibilidad; documentar los procedimientos o instrucciones de escritorio; y asegurar el cumplimiento de ellos.

Un gerente probablemente creerá, a primera vista, que algunas o todas las técnicas centrales forman parte del sistema de programación de proyectos. Sin embargo, si se ha identificado que el sistema necesita mejoras, el primer paso es una revisión sincera de los métodos actuales para confirmar que todos los elementos fundamentales se están llevando a cabo de manera adecuada para mantener el propósito recomendado del sistema. Cualquier proceso elemental que no esté en su lugar o que no cumpla con el propósito debe ser corregido a tiempo para apoyar la implementación posterior de cualquier mejora relacionada con él.

Un destino seguro espera al gerente de proyectos que debe depender de información menos que sólida. Un sistema que no sea confiable o que esté siendo manipulado puede ser peor para la gestión de proyectos que no tener programación en absoluto.

Efectividad de la Programación

La intención dominante para este conjunto de sugerencias es la efectividad de la programación para servir al control del proyecto. Con la estrategia central, la ejecución estructurará la capacidad de programación al estándar reconocido para las aplicaciones de gestión de proyectos. Para algunos proyectos, la primera recomendación—instalar una EDT orientada al producto—puede ser una "mejora" que no es una prerrogativa del sistema de programación. Pero la gestión general del proyecto debería beneficiarse si la EDT está orientada al producto, para facilitar el control del alcance del trabajo y, a su vez, el rendimiento de costos/programación. La identificación del flujo de actividades de programación surge inherentemente si el alcance técnico aprobado se desglosa como trabajo y sus productos; y, típicamente, una EDT orientada al producto implica una lógica de integración previa para la programación de precedencia.

• EDT orientada al producto. Desarrollar y definir una EDT orientada al producto que sea completa en todos los niveles para todo el alcance técnico. Establecer clasificaciones de EDT según el producto final (no organización o función). Aplicar la EDT como el factor para integrar el horario con el costo y el alcance. Tener en cuenta que todo el trabajo debe ser rastreable a través de cada nivel de la EDT y la programación. Ejemplo: El trabajo descrito en el nivel más bajo de la EDT como "verter concreto" puede seguirse a través de los productos finales de nivel superior, como "construir la fundación", "levantar el hangar" y "construir el aeropuerto".
• Base de la programación para la medición del rendimiento. Eliminar la oportunidad de reportar el progreso basado en costos reales y fortalecer el control del proyecto insistiendo en que las redes de programación sean la fuente principal de datos y cálculos de rendimiento, y la fuente de reportes de estado de hitos. Establecer una interfaz electrónica con el sistema de recolección de costos del proyecto para que los costos reales puedan incorporarse a la red para el cálculo de la medición integrada de rendimiento costo/programación, pero asegurar que el estado de la programación se reporte antes de la incorporación de costos reales. Proveer la transferencia electrónica de datos a cualquier otro sistema de seguimiento que requiera reportes de estado.
• Programación centralizada. Centralizar la organización de programación para el control y desarrollo consistente, especialmente para proyectos grandes o múltiples. Generar y establecer como base horarios separados para cada proyecto (o un solo proyecto, basado en grupos, fases u otra división lógica); fusionar estos horarios subordinados en una red de programación integrada; y establecer como base el horario integrado como el horario de rendimiento sujeto al control de cambios.
• Criterios de LOE. Establecer criterios específicos para incorporar actividades de nivel de esfuerzo (LOE) en las redes de programación y codificar las actividades LOE para su exclusión selectiva de gráficos de programación cuando la omisión sea deseable para propósitos de presentación. Cuando tal limitación sea apropiada, designar una sola red de programación para la carga de recursos LOE. Por ejemplo, la actividad de "operaciones" puede impactar un proyecto en general, pero no el horario en sí. La separación de tareas de operaciones puede ser deseable para facilitar el control de recursos y costos a un nivel superior que para los segmentos de trabajo que necesitan monitorear más de cerca el rendimiento de la programación.
• Priorización. Determinar las bases apropiadas para la priorización del alcance del trabajo programado y codificar las actividades de programación para indicar prioridad. Esta técnica apoya las decisiones basadas en escenarios de "qué pasaría si" en los que los cálculos posponen algunas actividades con fechas flexibles mientras mantienen terminaciones tempranas para tareas prioritarias con potencial de impactar la fecha de finalización del horario.
• Análisis/Tendencias. Establecer procesos para análisis regulares de la ruta crítica y el rendimiento costo/programación, basados en informes de redes en todos los niveles de programación. Pedir a los programadores que describan la capacidad del sistema para productos fácilmente obtenidos o desarrollados y aplicarlos como herramientas para acomodar la gestión del proyecto. Proveer para la tendencia del rendimiento manteniendo información histórica de costo/programación fácilmente disponible, o según corresponda, exportar regularmente datos de costo/programación a una base de datos no vinculada a la red.

Eficiencia de la Programación

Estas recomendaciones aumentan aún más la estrategia central y otras sugerencias ya dadas. Se centran en mejoras de procesos que se espera mejoren la capacidad y eficiencia general del programa de programación.

• Garantía de calidad. Establecer procesos y especificar responsabilidades dentro de la organización de programación; esto es para verificaciones de garantía de calidad como revisión por pares, revisión de redes y productos no conformes y verificaciones offline de actualizaciones/cambios/resumidas antes de su presentación a redes maestras. Considerar asignar a un "policía del código" que mantenga una rutina para revisar listas y reportes de redes en busca de códigos no estándar, restricciones, etc.
• Técnicos de programación. Utilizar técnicos de programación como el recurso principal para la entrada de datos, especialmente si los programadores de proyectos están desempeñando tareas que no son rentables con demasiada frecuencia. El uso de técnicos libera a los programadores para realizar otro trabajo de control de proyectos, como el análisis de rendimiento, que sirve mejor al proyecto y al gerente del proyecto.
• ID de actividad. Aplicar un esquema estándar para identificadores únicos de actividad de programación (ID de actividad) que incorpore "inteligencia" para indicar fácilmente información sobre la actividad programada; y asegurar el desarrollo completo de los diccionarios de códigos para apoyar el esquema de ID de actividad. Por ejemplo, ciertos caracteres en el ID de actividad pueden mostrar el proyecto, la responsabilidad o el número de tarea. (Esta sugerencia amplía la cuarta estrategia central para liberar campos de códigos previamente utilizados para información ahora incrustada en ID de actividad más efectivos.)
• Términos/Símbolos estándar. Establecer términos y símbolos estándar y desarrollar un conjunto base de formatos de informes para generarlos consistentemente para diferentes niveles de gestión y múltiples aplicaciones. Aunque a veces es necesario reportar a estándares y necesidades individuales de varios gerentes, se debe desarrollar el potencial de eficiencia. La aplicación inconsistente de gráficos/informes y términos/símbolos a menudo confunde la comparación de datos de rendimiento de un período a otro, o entre proyectos.
• Dólares como recurso. Indicar dólares como un recurso en redes de programación al asignar precios a los recursos para actividades, totalizando el costo de todos los recursos para cada actividad, cargando esa cifra en dólares como un recurso separado en la actividad y resumiendo los recursos en dólares para horarios de nivel superior. Esta técnica es particularmente útil cuando se aplica para revisar horarios de nivel superior que relacionan costos resumidos con actividades resumidas.

Este método proporciona una base para el análisis de "qué pasaría si" impulsado por el presupuesto que facilita la planificación resumida. Cuando la duración de un proyecto se extiende a lo largo de varios años, puede ser ventajoso generar una base de datos de hojas de cálculo a partir de la red de programación. Luego, las cantidades en dólares se resumen para la planificación y presupuestación a largo plazo que está vinculada al horario y a los recursos que incorpora, lo que puede ser preferible a una base de hoja de cálculo solo de presupuesto para la planificación de costos.

¡Hazlo!

¡Uf! ¡Solo leer sobre cómo aumentar un programa de programación ya es un trabajo duro! ¿Cuánto más difícil será la ejecución real? La mejor respuesta es hacer que los ejercicios de aumento sean tan duros como el programa de programación pueda soportar sin afectar negativamente el proyecto. Si la implementación completa no es necesaria o no es práctica, la presentación de ítems individuales facilita la selección de un conjunto compuesto de mejoras.

Cualquiera sea la combinación de mejoras que mejor acomode las necesidades identificadas del sistema de programación, la planificación inicial para la implementación puede comenzar inmediatamente después de las decisiones sobre qué/cómo/cuándo se ejecutan las recomendaciones. El gerente que crea que las técnicas propuestas ya son parte del sistema debe primero determinar si la incorporación es realmente adecuada para cumplir con todas las intenciones sugeridas.

Las recomendaciones presumen dos cosas: que el control del proyecto es la función principal del sistema de programación, y que la credibilidad es su atributo más importante. En el caso gubernamental descrito, varios gerentes entrevistados en cuanto a sus expectativas para su sistema de programación confirmaron estos temas; y la encuesta indicó que los sistemas de referencia están bien fundamentados en su apoyo para ambos contextos. La falta de compromiso con el concepto de credibilidad de la programación como base para el control efectivo del proyecto probablemente limitará la aplicación de los altos estándares y mejores prácticas que caracterizan a los sistemas de mérito.

HAZ UN COMPROMISO PARA AUMENTAR. ¡No te acobardes! La implementación puede ser un desafío que implique un cambio significativo, particularmente para un sistema establecido, pero estos consejos valen la pena debido a los beneficios generales de control del proyecto que tienen. ¡Sin dolor, no hay ganancia! ¡Hazlo! ... porque la gestión de proyectos es vulnerable a una programación débil.

Fuente: Traducción y adaptación del artículo 'Pump up your project scheduling'del PMI.