Control multiproyecto

¿Cuál es la mejor manera de controlar la dirección una serie de proyectos de producción e I+D de diferente duración, valor y complejidad técnica? En este artículo, el autor describe un sistema que lleva seis años en proceso de desarrollo y perfeccionamiento en una gran empresa de electrónica y que se ha implementado en dos de las divisiones de la empresa. El sistema es relativamente sencillo; sin embargo, ha ayudado a los altos ejecutivos de ambas divisiones a gestionar eficazmente el rendimiento de unos 100 proyectos diferentes. En la división que empezó a utilizar el sistema, el número de proyectos con problemas graves se redujo de uno de cada tres a cero en poco más de dos años; en la segunda división, los proyectos en problemas se redujeron de uno de cada tres a uno de cada veinte en un período de dos años, y se prevé una mejora continua. El enfoque descrito utiliza una técnica de reportaje visual muy sencilla. Al mismo tiempo, combina algunos principios reconocidos de la psicología gerencial con algunos principios más nuevos de planificación y control.

Aunque los medios para controlar el progreso de un proyecto individual están bien establecidos, la integración del control de costes, cronogramas y rendimiento en un proyecto aún está en fase de desarrollo. Aún menos desarrollado está el control de gestión de varios proyectos simultáneos de diferente valor, duración y complejidad técnica. Este control es cada vez más importante debido a la explosión de los negocios orientados a la contratación, a la proliferación de la actividad de I+D patrocinada por las empresas, al aumento de la demanda de los clientes de una gama más amplia de opciones de productos en un año determinado y al efecto del crecimiento tecnológico en la necesidad de tener un conjunto de nuevos productos en distintas fases de desarrollo para los próximos años.

Las circunstancias que impulsaron el diseño y la implementación del sistema de control multiproyecto que describiré probablemente no difieran mucho de las que se encuentran en muchas organizaciones. Los ejecutivos de la empresa se vieron influenciados por las siguientes consideraciones:

1. La necesidad de gestionar un gran número de proyectos únicos, incluidos tanto los contratos de defensa financiados por el gobierno como los programas de I+D financiados internamente.

2. La necesidad de abordar proyectos que varían en tamaño, desde unos pocos miles de dólares hasta muchos millones de dólares; en longitud, de un par de meses a varios años; y en complejidad técnica, desde la producción sencilla hasta la I+D avanzada.

3. Falta de un requisito formal de que los costes, el calendario y el estado del rendimiento técnico de un programa determinado se presenten simultáneamente a la alta dirección. (Anteriormente, existía un sistema de contabilidad totalmente desarrollado e informatizado, se registraban las fechas de envío y se realizaban revisiones técnicas del diseño, pero no satisfacían la necesidad.)

4. La existencia de un número no deseado de programas que tenían graves dificultades, algunos porque no cumplían con las especificaciones técnicas, muchos otros porque se retrasaban y aún más porque habían incurrido en graves sobrecostes.

La dirección quería un sistema de control multiproyecto que alentara a los directores de proyectos a asumir más responsabilidad por los resultados de sus proyectos, a fijar objetivos más altos pero realistas y a hacer un mejor uso de las revisiones formales periódicas. La dirección quería un sistema que eliminara las «sorpresas», por ejemplo, los requisitos de costes y tiempo que superaban con creces lo previsto al principio. También se deseaba un sistema que permitiera a los altos ejecutivos sustituirse entre sí en la revisión de los proyectos y en la toma de decisiones y compromisos que afectaran a la obra. Además, por supuesto, la dirección quería un sistema de control que fuera adecuado para dirigir una gran variedad de proyectos.

Básicamente, se esperaba que se pudiera desarrollar un sistema que ayudara a los gerentes, tanto a nivel ejecutivo como de proyectos, a administrar el negocio en lugar de dejarse dirigir por él. El enfoque que evolucionó, en mi opinión, ha hecho realidad sus esperanzas.

Control individual de proyectos

Reconociendo que el alcance de la planificación variará según el tamaño y la complejidad de un proyecto determinado, la dirección exige que cada proyecto tenga un plan de programación escrito preparado por el director del proyecto responsable al principio de la obra. Este plan de programa debe definir explícitamente los objetivos del proyecto, el enfoque que debe adoptarse y los compromisos que asume el gerente.

En el caso de los proyectos con financiación interna, el plan del programa debe aprobarse antes de empezar las obras. En el caso de los proyectos contractuales, el director del proyecto tiene 30 días después de la adjudicación del contrato para obtener dicha aprobación; este requisito se establece porque el proyecto debe empezar si se quiere cumplir los compromisos programados y porque, en el negocio de la defensa, gran parte de la planificación del programa se ha realizado durante el período de preparación de la propuesta.

Además de un examen detallado de los requisitos contractuales, cada plan de programa considera los posibles efectos de imprevistos, como las limitaciones de financiación, el incumplimiento de los subcontratistas, los paros laborales y los problemas técnicos inesperados. El plan debe ser completo, pero no detallado; preciso, pero no quisquilloso; y exhaustivo, pero no limitado por un formato riguroso.

Tan pronto como se complete el plan del programa, se presenta a la alta dirección para que lo revise. La aprobación formal del plan por parte de la dirección otorga al director del proyecto la autoridad para ejecutar y controlar su proyecto hasta su finalización.

Por supuesto, la planificación es una función continua y dinámica. La redirección de clientes, los cambios en el alcance y los problemas inesperados pueden requerir una actualización del plan del programa. Pero sea que el plan de un programa necesite o no una revisión, es muy importante que los altos ejecutivos den a conocer su intención de revisar el desempeño periódicamente en función del plan y den la dirección y orientación adecuadas al director del proyecto cuando sea necesario.

Sistema de informes único.

El «corazón» del sistema de control multiproyecto es el informe sobre el estado del programa, que se muestra en el anexo I. Este informe refleja de forma resumida el contenido del plan del programa. Está diseñado para presentar simultáneamente los datos sobre el coste, el calendario y el estado técnico de un proyecto determinado, lo que permite a la dirección evaluar rápidamente el progreso del proyecto y proporciona una base sólida para determinar qué proyectos requieren una atención especial.

Anexo I. Ejemplo de un informe sobre el estado del programa

Parte de la información que proporciona este informe (por ejemplo, la descripción resumida del proyecto, el calendario resumido y las fechas clave del proyecto, la curva de costes acumulados y los datos sobre el personal principal asignado al programa) es similar a la que se proporciona en los informes utilizados por varias organizaciones.1 Sin embargo, la sección titulada «Elemento esencial de la información» es única. (Los triángulos que indican las fechas programadas de inicio y finalización quedan vacíos hasta que se complete el evento, momento en el que se rellenan. Un círculo alrededor de un triángulo indica que se requiere la entrega al cliente.)

Cada director de proyecto debe realizar una evaluación y valoración objetivas para determinar si su proyecto cumple con sus requisitos de rendimiento técnico, se ejecuta según lo previsto, se mantiene dentro del coste previsto y recibe la financiación adecuada. La necesidad de dar una respuesta afirmativa o negativa parece minimizar gran parte de la subjetividad y la editorialización que se obtiene cuando se pregunta: «¿Cómo van las cosas?» Una vez que el director del proyecto haya dado su sí/no respuestas, también se espera que codifique por colores el estado de estos cuatro parámetros críticos. La clave de colores de este y otros informes es:

• La codificación verde se utiliza cuando el rendimiento avanza de acuerdo con los objetivos y normalmente se combina con un sí respuesta.

• El amarillo indica una respuesta cualificada, advierte de posibles problemas graves y sugiere que se justifica una atención cuidadosa.

• El rojo refleja situaciones «fuera de control», como un sobrecoste, un retraso en los plazos o problemas técnicos que influyen en el cumplimiento de las obligaciones contractuales o los objetivos del proyecto (ninguno, en este informe).

Las situaciones amarillas y rojas requieren una explicación en «Lo más destacado del programa». Debe tenerse en cuenta que la selección del código de colores rara vez es un problema cuando se combina con el forzado sí/no respuesta.

Cada director de proyecto actualiza sus informes de estado mensualmente. Si bien los informes se ajustan a un sistema de informes organizacional, el hecho es que la alta dirección tiene una gran cantidad de información que repartir en un intento de asimilarla. Por este motivo, se ha desarrollado un sistema para mostrar visualmente los elementos esenciales de todos los proyectos. Esto permite a un alto ejecutivo eliminar los proyectos que no quiere revisar en detalle y determinar los que requieren su orientación y dirección.

Supervisar muchos proyectos

Todos los proyectos activos se publican cada mes. Cuando se informa de un proyecto por primera vez, se añade al archivo activo y a lo que se llama tablas resumidas del estado del proyecto, como el que se muestra en la prueba II. Cada proyecto se identifica por su nombre, valor, cliente, fecha de inicio y fecha de finalización prevista. La fecha de la aprobación formal del plan del programa aparece en la pizarra resumida con un triángulo negro. Las líneas verticales negras indican el principio y el final (o los finales programados) de los proyectos.

Prueba II. Ejemplo de una junta sobre el estado de un proyecto

Cada mes, los indicadores verdes, amarillos y rojos del estado técnico, de calendario, de costes y de financiación se publican en grandes paneles de resumen permanentes que se encuentran en una sala de gráficos ejecutivos. En el anexo II vemos el historial de ocho proyectos, de los que se informó hasta julio de 1967.

Si el director del proyecto responsable celebra una reunión de revisión del programa, ese hecho aparece en forma de «viñeta» negra en la columna de tiempo correspondiente. No existen requisitos rígidos para las reuniones de revisión del programa en cuanto a su frecuencia o contenido; sin embargo, un resultado común de las reuniones es la actualización de los planes del programa. Algunos proyectos se revisan formalmente cada pocos meses, otros casi todos los días. Algunos directivos guardan abundantes actas de sus reuniones de revisión; otros guardan pocas. La alta dirección de la empresa quiere que los directores de proyectos decidan por sí mismos lo que se necesita. Pero si hace tiempo que no se celebra una reunión de revisión del programa, la dirección analiza detenidamente la ejecución del proyecto. Si los altos ejecutivos están lo suficientemente preocupados por un proyecto, tal vez quieran asistir a la próxima reunión de revisión del programa programada.

Lo que hacen las juntas de estado resumido es: (a) identificar todos los proyectos activos; (b) mostrar cuándo comenzó cada uno y cuándo está previsto que se complete; (c) indicar si se ha aprobado un plan de programa y, de ser así, cuándo; (d) decir si se están realizando revisiones del programa y, por último, (e) presentar una evaluación cronológica del estado técnico, programático, de coste y de financiación mensual de cada proyecto.

Método de implementación.

Cuando se probó el nuevo sistema por primera vez, la dirección puso todo su empeño en garantizar que se presentaba un informe mensual sobre el estado del programa para cada proyecto en curso. La dirección consideró que, si bien muchos directores de proyectos no tenían planes de programas escritos formalmente, estaban trabajando para lograr algunos objetivos definidos, aunque en el reverso de un sobre o en la cabeza. Si se pudiera inducir a los directores del proyecto a informar de manera objetiva y estándar «cómo les va», la atención de la alta dirección podría centrarse más fácilmente en las áreas en las que sería más beneficioso.

Durante los primeros meses, varios directores de proyectos expresaron su hostilidad hacia el enfoque, pero sus sentimientos disminuyeron cuando se hizo evidente que el apoyo y la asistencia de la alta dirección eran cada vez más eficaces y que, en general, se apreciaban mejor los problemas a los que se enfrentaba. Después de varios meses, todos los directores del proyecto dijeron a la alta dirección su posición en términos de los «elementos esenciales».

Durante las primeras fases de la implementación, entonces, se hizo hincapié en la notificación y las medidas correctivas, no en la prevención. Pero la dirección también reconoció la necesidad de planificar los programas a largo plazo. En consecuencia, cuando el número de proyectos en graves dificultades se redujo a un nivel más aceptable, después de unos ocho meses, la planificación del programa se convirtió en un requisito para todos los programas nuevos y para todos los programas existentes que tenían previsto funcionar cinco meses más o más.

Éxito en la práctica.

El sistema de control multiproyecto se implementó por primera vez en una división en 1962. En 1966, una segunda división probó el sistema. Las circunstancias en torno a la implementación en las dos organizaciones eran muy similares; además, el método de implementación era el mismo en cada caso. El hecho de que los resultados que se han obtenido también sean muy similares nos da la confianza de que el sistema se puede aplicar en general con éxito.

El anexo III muestra los resultados obtenidos en las dos divisiones; en ambos casos, una reducción notable del porcentaje de proyectos rojos y amarillos. Un proyecto en su conjunto se considera rojo si alguno de los cuatro indicadores es rojo; amarillo, si ninguno de los indicadores es rojo, pero uno o más son amarillos; y verde, solo si todos los indicadores son verdes.

Prueba III. Análisis del estado del proyecto

La primera vez que se introdujo el sistema, 33% de todos los proyectos eran rojos, 30% amarillo y 37% verde en el primer mes de presentación de informes completos. Durante los siguientes ocho meses, se hizo hincapié en corregir los problemas más graves del proyecto y en reducir los proyectos rojos, de 33% a 11%—tenía experiencia. Sin embargo, no se produjo ningún cambio significativo en el porcentaje de proyectos ecológicos y, en esencia, la reducción de los proyectos rojos se vio compensada por el aumento de los proyectos amarillos. La criticidad de la situación se había reducido, pero la organización seguía en un terreno inestable.

En junio de 1963, se introdujo el requisito de planificación de programas. Se necesitaron varios meses para implementar plenamente la planificación. El efecto entonces fue sorprendente; el porcentaje de proyectos rojos siguió cayendo, mientras que el porcentaje de proyectos ecológicos aumentó considerablemente. Para septiembre de 1964, 77% de los proyectos denunciados eran ecológicos, 23% eran amarillas y ninguna era roja.

Cuando se introdujo el sistema en la segunda división de la empresa, surgió un patrón similar. Los primeros siete meses, cuando se hizo hincapié en la presentación mensual de informes de estado y en las medidas correctivas, se redujo el número de proyectos rojos de 32% a 13%. Pero cuando se instituyó la planificación de los programas, el porcentaje de proyectos rojos siguió bajando y la proporción de proyectos ecológicos aumentó considerablemente. Hasta finales de 1967, 67% de los proyectos eran ecológicos, 28% amarillo y 5% rojo. Se prevé que la mejora continua se produzca en el futuro.

Mayor comprensión.

Como resultado de la experiencia de las dos divisiones, creo que se pueden aprender varias lecciones:

• Los directores aceptarán la responsabilidad de sus proyectos cuando la autoridad para gestionarlos esté claramente delegada. Con el nuevo sistema, no hay duda de quién es el director del proyecto responsable. Tiene que preparar el plan del programa, tiene que informar mensualmente del progreso del proyecto y tiene que responder por los resultados finales generales del proyecto. Los directores de proyectos se enorgullecen de poder informar que sus proyectos estaban «en verde».

• Un objetivo inicial del sistema era llegar al punto en que todos los proyectos estuvieran «en verde». La dirección ahora opina de otra manera y considera que es un objetivo indeseable. Lograrlo indicaría que las normas no son lo suficientemente estrictas. Los negocios de la empresa requieren un lápiz muy afilado. Es muy poco realista suponer, entonces, que todos los proyectos se pueden completar dentro del coste, según lo previsto y según las últimas especificaciones técnicas. Aunque no parece haber ninguna forma de determinar la combinación óptima de proyectos, ahora se considera que aproximadamente 5% debería ser rojo y 20% amarillo, en un momento determinado.

• Los diferentes directivos presionan el «botón de pánico» en diferentes momentos para buscar ayuda. Los directores de proyecto también difieren en su tendencia a ser «alcistas» o «bajistas» con respecto al progreso de sus operaciones. Estas tendencias quedan claras para los ejecutivos cuando comparan el historial periodístico de los gerentes con los resultados de sus proyectos. Algunos directivos prefieren seguir clasificando un proyecto como amarillo o rojo a lo largo de su vida y presentarlo como verde solo cuando está terminado; en el otro extremo, algunos hombres siguen denunciando sus proyectos como «verdes» y no dejan que el rojo se vea (si es que lo hace) hasta el último día. El sistema no pretende eliminar las diferencias en las formas de evaluar los proyectos, sino eliminar el exceso de optimismo y pesimismo. Un gerente puede hacer el ridículo cuando clasifica repetidamente un proyecto como problemático, y la revisión por parte de la dirección resulta en una anulación de la evaluación y, por supuesto, las consecuencias son más graves para un gerente demasiado optimista.

• La dirección ha aprendido que, en el proceso de control de gestión, la planificación formal no tiene por qué anteponerse a los aspectos de presentación de informes y control del sistema. Este parece ser el caso especialmente en una situación actual en la que el gerente tiene algún tipo de plan en el que está trabajando, aunque solo esté en su cabeza. El sistema de informes lo obliga a evaluar su progreso de forma explícita en función de su plan e indicar a los altos ejecutivos las áreas problemáticas para que puedan ayudarlo a superarlos. El plan del programa, cuando se presenta, permite a la alta dirección dar su orientación al principio del proyecto y también hacer su propia evaluación del progreso con respecto al plan.

Conclusión

Un número cada vez mayor de empresas se preocupan por el problema de controlar un gran número de proyectos diversos. El enfoque descrito en este artículo se utiliza desde hace seis años. No es un sistema muy complicado, no está informatizado y su funcionamiento no cuesta mucho dinero. En lugar de intimidar a los directores de varios proyectos, el sistema los alienta a aceptar toda la responsabilidad por el resultado de sus respectivos proyectos. En lugar de mantener a los directores de proyectos en la oscuridad en cuanto a lo que la alta dirección quiere saber sobre sus operaciones, este enfoque no deja ninguna duda en la mente de los directores sobre lo que se espera. Además, la alta dirección ahora es capaz de revisar rápidamente un gran número de proyectos y dedicar su energía a los programas que más necesitan atención.

En resumen, tanto la dirección del proyecto como la alta dirección han considerado que el sistema es muy valioso. Las organizaciones que lo han probado se han beneficiado de ello.

1. Véase, por ejemplo, L.S. Hill, Planificación y control de la gestión de proyectos de investigación y tecnología, Santa Mónica, California, The RAND Corp., RM-4291-PR, junio de 1966.