• Oct 24, 2011
• 1,165 views
• Short URL: rvarg.as/12f/

Urgencia: Un Factor Crítico en el Planeamiento de Proyectos

Resumen

Delante de la natural velocidad y del dinamismo del mundo, la agilidad y el sentido de urgencia se han convertido preponderantes en todos los proyectos. Plazos y presupuestos desafiadores convierten la actividad de dirigir esos proyectos en una actividad de riesgo inminente. Cuanto más los plazos y costos se convierten en desafiadores, más la necesidad de un planeamiento meticuloso y detallado se convierte en fundamental. Por otro lado, la urgencia en el planeamiento de estas actividades en la mayoría de las veces perjudica directamente la calidad de los planes desarrollados.

El artículo tiene por objetivo discutir los costos y beneficios de la velocidad en el desarrollo de un plan de proyecto y propone un proceso básico compuesto de 10 etapas para planear y 10 etapas para acompañar/controlar un proyecto en un corto espacio de tiempo. El proceso propone la priorización y simplificación de los documentos críticos a ser desarrollados de modo que aseguren el propósito, el alcance, los plazos y presupuestos, bien como las restricciones directas del proyecto a ser desarrollado.

Finalmente, el artículo presenta una lista con factores de éxito a ser observados para lidiar y desarrollar rápidamente planes de proyecto efectivos.

Urgencia: los Costos y Beneficios de la Velocidad

Un proyecto es realizado con el objetivo de producir un cambio benéfico en el ambiente con básicamente tres características (TURNER & MULLER, 2003):

• Es único: no existen proyectos anteriores iguales.
• Es nuevo: ningún proyecto anterior usó el mismo abordaje
• Es temporario: tiene un inicio y un fin.

Estas características producen diversas presiones, entre ellas el sentido de urgencia, la incertidumbre y la necesidad de integración. La urgencia está directamente relacionada a la producción de resultados usualmente dentro del menor plazo posible.

Según Betty Sue Flowers (MARCUS, 1998), las personas deben tener un sentido de urgencia a pesar de que la situación parezca en buen estado. El sentido de urgencia no viene de una crisis emergente, pero sí de la necesidad de estar preparado para cualquier situación, inclusive las oportunidades.

Delante de este escenario, es fundamental que el gerente del proyecto responda inmediatamente a las solicitaciones del cliente y de otras partes interesadas con un sentido de urgencia legitimado (KERNION, 1999). Con esto, el gran desafío se convierte en balancear ese sentido de urgencia y la presión con el tiempo para la reflexión, experimentación e innovación que un producto o servicio único requerirá al ser desarrollado (EPPLER & SUKOWSKI, 2000).

Flujo Simplificado del Desarrollo del Plan del Proyecto

Para atender directamente la necesidad, se requiere simplificar el proceso de gestión. La simplificación se da a través del análisis cuidadoso de los procesos que pueden ser considerados fundamentales e indispensables. Es importante resaltar que solamente los procesos considerados cruciales deben ser analizados cuidadosamente, una vez que la prioridad es la velocidad del desarrollo, no significando con esto que otros procesos que no están listados no sean también agregadores de resultados en el planeamiento del proyecto.

La base del flujo propuesto es el PMBOK® Guide (PMI, 2008), con destaque para la secuencia de actividades que componen el proceso, partiendo de una premisa de que ya existe un gerente de proyecto atribuido. A partir de los procesos detallados en la Guía, se elaboró un flujo con 10 procesos, conforme se destaca en la Figura 01 y se detalla a continuación.

Figura 02 – Flujo Simplificado del Desarrollo del Plan del Proyecto

1. Desarrollar el Término de Abertura – Este proceso tiene como objetivo desarrollar el documento del Término de Abertura del Proyecto, con el objetivo de documentar las necesidades de negocio que serán atendidas por los proyectos, además de obtener el compromiso de las áreas/personas involucradas y divulgar oficialmente el nacimiento de los proyectos a todas las partes interesadas. El Término de Abertura del Proyecto debe mantenerse inalterable a lo largo del proyecto. Su actualización es realizada en caso de modificación extrema en el proyecto, como por ejemplo, cambio del patrocinador o del gerente del proyecto, alteración sustancial del presupuesto o del cronograma previsto. El Término de Abertura, en este modelo “urgente” del plan, también debe incorporar algunos elementos que tradicionalmente deberían estar en la Declaración del Alcance. En este caso, lo que se propone es la creación de un documento único que aglutine puntos principales de la Declaración de Alcance dentro del Término de Abertura.

2. Elaborar la Estructura Analítica del Proyecto – Proceso que tiene el objetivo de desarrollar la herramienta principal del dimensionamiento del alcance del proyecto. La EAP del proyecto es una estructura visual jerárquica que presenta la descomposición del proyecto en partes menores, más gerenciables, denominadas paquetes de trabajo. Debe ser construida de modo “top-down” y detallada inicialmente en hasta 3 niveles, aproximadamente. Los demás niveles serán actualizados y detallados con el desarrollo de proyectos a través de modelos de planeamiento en ondas sucesivas (GITHENS, 1998).

Figura 03 – Planeamiento en Ondas Sucesivas (GITHENS, 1998)

3. Elaborar el Cronograma – Proceso que atribuye duraciones a los paquetes de trabajo (menor nivel de la EAP) y relaciona las precedencias entre estos paquetes, generando el Diagrama de Redes y el Gráfico de Gantt del proyecto. En esta etapa se determina la duración estimada del proyecto.

4. Estructurar el Presupuesto del Proyecto – El objetivo de este proceso es crear una estimativa de costos de los trabajos del proyecto que, consolidada irá general el presupuesto del proyecto y generar la línea base de costos. El presupuesto del proyecto debe ser elaborado en el nivel de detalle que sea compatible con la efectiva separación de los trabajos y puede/debe ser refinado con las actualizaciones del proyecto.

5. Elaborar la Matriz de Responsabilidades – Proceso que tiene el objetivo de desarrollar la planilla que define a las responsabilidades dentro del proyecto. Relaciona las entregas e/o grandes bloques de la EAP con los recursos humanos responsables por la ejecución y aprobación de los trabajos, bien como las partes interesadas que deben ser informadas y consultadas. Popularmente conocida como matriz RACI (ARMSHAW, 2005).

6. Desarrollar el Plan de Comunicaciones – Proceso que tiene como objetivo desarrollar una planilla simplificada que destaca, quien recibe la información (principales partes interesadas identificadas), lo que será comunicado, cuándo será realizada la comunicación, dónde será recolectada la información, porqué la comunicación está siendo realizada, quién es responsable por la comunicación, cómo será realizada la comunicación y cuánto costará la producción de la información (5W y 2H).

7. Desarrollar el Plan Preliminar de Riesgos – El objetivo de este proceso es identificar los potenciales riesgos del proyecto utilizando un abordaje estructurada para recolectar y documentar los riesgos identificados, tales como la Técnica de Grupo Nominal (NGT), el Delphi y el Brainstorming (ADAMS & MEANS, 2006). Se sugiere que apenas las amenazas sean identificadas, descartándose las oportunidades, para que el proceso sea desarrollado más rápidamente. En seguida, los riesgos identificados son analizados en términos de probabilidad, impacto y urgencia, permitiendo que eventuales Planes de acción sean desarrollados como respuesta a los riesgos con mayor exposición. El plan de riesgos será actualizado a lo largo de la ejecución de los trabajos.

8. Consolidar Informaciones en el Plan de Proyectos – Proceso que agrupa los documentos anteriormente producidos en el Plan de Proyecto. Eventuales presentaciones y documentos de apoyo también pueden ser consolidados en el plan para facilitar el proceso de presentación del proyecto para los responsables por la aprobación.

9. Aprobar los Documentos del Plan del Proyecto – El objetivo de este proceso es garantizar que los responsables por las aprobaciones realicen un análisis de los documentos del plan del proyecto, verificando si todas las entregas previstas están de acuerdo con los objetivos determinados. La aprobación autoriza el inicio de los trabajos y transforma el plan del proyecto aprobado en la línea base de la evaluación de desempeño.

10. Realizar una Reunión de Lanzamiento del Proyecto – La reunión del lanzamiento del proyecto es un evento de extrema importancia porque tiene el objetivo de divulgar el inicio de las actividades del proyecto y la forma como este debe contribuir para conseguir los objetivos estratégicos de la Organización. Además de constituirse como una oportunidad que busca garantizar el compromiso de la Organización en relación al proyecto, es considerada como la primera reunión de trabajo del equipo principal del proyecto, en el cual se presenta el plan del proyecto, siempre buscando el compromiso de las partes interesadas.

Flujo Simplificado de la Actualización del Plan del Proyecto.

La actualización del plan del proyecto desarrollado según el proceso anteriormente presentado, también puede ser presentada por 10 (diez) procesos simplificados, incluyendo el proceso de aprobación e implementación de cambios. El proceso simplificado de actualización del plan es realizado repetidas veces a cada ciclo de acompañamiento.

La determinación de la duración del ciclo es una función de la duración del proyecto y de parámetros de planeamiento organizacionales (ROSENHEAD, 2008). Usualmente, un proyecto debe tener su ciclo de acompañamiento a cada 10% de la duración proyectada, desde que el intervalo mínimo entre ciclos sea de 1 día y el intervalo máximo entre ciclos sea de 30 días. Como ejemplo, un proyecto de 10 semanas sugiere un intervalo entre ciclos de 1 semana, así un proyecto de 20 semanas sugiere un intervalo entre ciclos de 2 semanas.

En la Figura 04 se presenta el flujo simplificado de actualización del plan de proyecto.

Figura 04 – Flujo Simplificado de Actualización del Plan de Proyecto

Recolectar Informaciones de Desempeño – El objetivo de este proceso es obtener informaciones sobre el desempeño del proyecto junto al equipo de ejecución, proveedores, etc. La recolección puede darse de modo estructurado o a través de adaptaciones y simplificaciones de modelos ágiles, tales como partes del modelo de dinámica de recolección e intercambio de informaciones adoptadas en las reuniones de Daily Scrum del modelo Scrum, por ejemplo (SCHWABER, 2010). Es importante resaltar que el objetivo del proceso es la recolección de la información y no la toma de decisiones.

Actualizar Estructura Analítica del Proyecto – El objetivo de este proceso es actualizar la Estructura Analítica del Proyecto (EAP), para que continúe reflejando todas las entregas efectuadas en el ciclo. El trabajo restante debe ser evaluado, y eventuales detallamientos de las entregas futuras deben ser realizados, en caso necesario. Importante atención debe darse a la diferenciación entre detallamiento y creación de nuevas entregas. La creación de nuevas entregas no previstas es un caso clásico de problema en un proyecto proveniente del crecimiento desordenado del alcance (scope creep) (KUPRENAS & NASR, 2003).

Actualizar Cronograma – Proceso que tiene el objetivo de identificar los trabajos ya realizados y sus respectivos plazos, bien como las actualizaciones en la EAP, buscando actualizar el cronograma y proyectar la duración y el plazo final del proyecto. Las nuevas duraciones y plazos serán comparados con las duraciones y plazos aprobados en el plan (línea base) con el fin de evaluar el desempeño del proyecto.

Actualizar Presupuesto – El objetivo de este proceso es evaluar el desembolso efectuado para la realización del trabajo en el ciclo y actualizar el presupuesto restante. El nuevo presupuesto se comparará con el presupuesto aprobado en el plano (línea de base) para evaluar el desempeño del proyecto.

Revisar Matriz de Responsabilidades y Plan de Comunicación – El objetivo de este proceso es actualizar la Matriz de Responsabilidades del Proyecto y el Plan de Comunicación. A lo largo de la ejecución del proyecto, además de las propias alteraciones de responsabilidades inherentes a este, es común haber intercambio de papeles, bien como refinamientos en las responsabilidades del proyecto, causando, de este modo, alteraciones en la Matriz de Responsabilidades. Los resultados de la comunicación prevista en el plan de comunicación son evaluados en este proceso con el objetivo de verificar si algún elemento de comunicación requiere ser creado, excluido o alterado de acuerdo con el comportamiento de las partes interesadas. Tiene el objetivo de garantizar que solamente la información válida que soporta la decisión y la necesidad de información sea producida, evitando esfuerzo innecesario en la producción de informaciones dispensables.

Actualizar el Plan de Riesgos y Plan de Respuestas a los Riesgos – El objetivo de este proceso es actualizar la Matriz de Riesgos del Proyecto a través de la identificación de nuevos riesgos y del re-análisis de los riesgos anteriormente identificados. El estatus de los planes de acción existentes y la evaluación de su efectividad también son realizados en este proceso.

Elaborar el Informe de Estatus – El objetivo de este proceso es consolidar todas las informaciones del tipo ejecutivo en un informe simple y directo. El público-objetivo del informe es definido en el Plan de Comunicación y su contenido presenta informaciones resumidas sobre el desempeño del proyecto en el ciclo y recomendaciones de cambios.

Realizar la reunión de control de cambios – El objetivo de este proceso es comunicar el estatus del proyecto en el ciclo, analizar las solicitaciones de cambio propuestos y deliberar sobre sus incorporaciones (o no) a las ejecuciones de los proyectos.

Implementar Cambios Aprobados – Proceso que tiene el objetivo de incorporar los cambios aprobados en el plan del proyecto, incluyendo revisión rápida de los documentos ya desarrollados y la adecuada comunicación de los cambios implementados para las partes interesadas.

Registrar Lecciones Aprendidas – Proceso que tiene el objetivo de consolidar las lecciones aprendidas del proyecto recolectadas durante el último ciclo. Las lecciones aprendidas contienen el registro de las experiencias positivas, tales como las mejorías en procesos y decisiones gerenciales acertadas, además de las experiencias negativas ocurridas y de los puntos de mejoría identificados durante el proyecto.

Premisas y Factores de Éxito

Desarrollar rápidamente planes de proyecto requiere de un ambiente diferente de aquel del planeamiento convencional. Entender algunas premisas y los factores de éxito es crucial para el adecuado entendimiento no solo del proceso como también de los resultados.

Inicialmente, es importante resaltar que los resultados obtenidos con el modelo son menos detallados que los del planeamiento convencional basado en el PMBOK® Guide. El modelo desarrollado presupone una reducción en los procesos existentes a fin de acelerar el proceso de desarrollo, y las áreas del conocimiento relacionadas al alcance, tiempo, costo, riesgos y comunicaciones fueron priorizadas. Esto no significa que las demás áreas sean menos importantes.

Los documentos producidos deben ser simples, directos y objetivos y, en caso existan modelos de documentos en la Organización, apenas los campos imprescindibles deben ser utilizados. Es importante también resaltar que imprescindible es diferente de importante. Campos e informaciones imprescindibles son aquellas informaciones que impiden e inviabilizan el planeamiento en caso no existan o no sean disponibilizadas. Se sugiere también que los documentos sean producidos con software usuales de mercado, tales como planillas electrónicas y procesadores de texto. Sistemas integrados complejos e inter-relacionados aumentan la capacidad de control y tienen innumerables beneficios, sin embargo, pueden no dar la movilidad y la flexibilidad para el desarrollo acelerado del plan.

Se sugiere que el planeamiento del proyecto sea realizado utilizando el concepto de ondas sucesivas (GITHENS, 1998), buscando detallar con precisión el trabajo más inmediato y con menor precisión los trabajos del medio y largo plazo. Estos trabajos de medio y largo plazo serán detallados en ciclos futuros de actualización.

Es importante resaltar que el planeamiento rápido presupone un grado de tolerancia a los riesgos mayor del planeamiento convencional (HILSON & MURRAY-WEBSTER, 2005). En la Figura 05 puede observarse que los perfiles que presentan elevado grado de incomodidad delante de la incertidumbre (Paranoico y Averso), tienen mayor dificultad para planear, ejecutar y decidir en un escenario de urgencia debido al elevado grado de incomodidad encontrado en estas ocasiones. Por lo tanto, el proceso propuesto puede no encuadrarse para todas las organizaciones en todos los casos.

Figura 05 – Perfil de Respuesta a la Incertidumbre (HILSON & MURRAY-WEBSTER, 2005)

Finalmente, se sugiere que todo el trabajo de planeamiento sea efectuado en equipo, siguiendo modelos clásicos de co-localización (co-location o war room), en los cuales el equipo de proyecto trabaja la mayor parte de tiempo en el mismo espacio físico y mantiene contacto face-to-face (MEARMAN, 2004). Este tipo de trabajo permite una mejor comunicación, una reducción en los “silos” empresariales, un aumento en la capacidad de compartir conocimiento y, en un escenario de urgencia, hace con que el proceso de decisión sea más ágil y efectivo.

Conclusiones

Planear rápidamente con el objetivo de atender al sentido y a la necesidad permanente de urgencia de las organizaciones es una tendencia evidente en el trabajo con proyectos. Con el objetivo de atender ese sentido crítico de urgencia, muchos proyectos son ejecutados sin cualquier tipo de planeamiento bajo el pretexto de que el planeamiento lleva tiempo y perjudica el sentido común de urgencia pretendido.
El modelo propuesto tiene el objetivo de atender a ese escenario específico y es una simplificación de la realidad del planeamiento y que no tiene el objetivo de proponer la sustitución del modelo convencional de planeamiento de proyectos, en el cual conceptos, método y padrones existentes en el mercado deben ser evaluados y estructurados en el plan del proyecto.

Cuando existe un tiempo mínimo aceptable para el desarrollo de un plan estructurado, ese plan se torna indispensable y debe abordar con mayor detalle las áreas de conocimiento propuestas en el PMBOK® Guide (PMI, 2008), bien como otros conceptos y estándares del mercado. La utilización del modelo propuesto es apenas recomendada cuando no existe ninguna posibilidad de construcción de un plan estructurado para el proyecto.

Referencias Bibliográficas

ADAMS, T & MEANS, J. (2006). The Project Meeting Facilitator. Seattle: PMI Global Congress North America.

ARMSHAW, D. (2005). There has to be a Better way than this! How to get big benefits from Project management basics. Edimburg: PMI Global Congress EMEA.

EPPLER, M. J. & SUKOWSKI, O. (2000). Managing Team Knowledge: Core Processes, Tools and Enabling Factors. London: European Management Journal Vol. 18, No. 3

GITHENS, G D. (1998). Rolling Wave Project Planning. Long Beach: PMI Annual Symposium and Congress.

HILSON, D. & MURRAY-WEBSTER, R. (2005). Understanding and Managing Risk Attitude, Burlington: Gower.

KERNION, D. M. The Project Manager—A Key Player in the Consulting Engineering Firm’s Marketing Plan. Long Beach: PMI Annual Congress and Symposium.

KUPRENAS, J. A. & NASR, E. B. (2003). Controlling Design-Phase Scope Creep. Morgantown: AACE Transactions.

MARCUS, G. (1998). Corporate Futures, Vol. V. Late Editions Series. Chicago: University of Chicago Press.

MEARMAN, M. (2004). Implementation Project Management: Now that You Bought it What Do You Do? Anaheim: PMI Annual Symposium and Congress.

PMI (2008). PMBOK: A Guide to the Project Management Body of Knowledge: Fourth Edition. Newtown Square: Project Management Institute.

ROSENHEAD, R. (2008). Let’s Make Those Project Meetings More Effective. Available at http://www.projectsmart.co.uk/pdf/make-those-project-meetings-more-effective.pdf

SCHWABER, K. (2010). Agile Project Management with Scrum. Redmond: Microsoft Press.

TURNER, J. R. & MÜLLER, R. (2003). On the nature of the project as a temporary organization. Amsterdam: International Journal of Project Management.