Ejecución del proyecto

  • José Ramón Rodríguez

    José Ramón Rodríguez

    Es consultor independiente en Dirección de Tecnologías de la Información y Gestión de Proyectos TIC, profesor de Sistemas de información y dirección de las TIC de la UOC y autor de artículos y libros sobre estas materias. A lo largo de su carrera profesional, ha alternado la actividad entre el sector privado y el sector público como directivo y consultor. Ha sido ejecutivo de empresas internacionales de servicios de sistemas de información y gerente de organización y sistemas de información en diferentes servicios públicos. Es licenciado en Filosofía y Letras, PDG del IESE y cuerpo técnico de la Seguridad Social. Su último libro es Gestión de proyectos informáticos: métodos, herramientas y casos, publicado por la editorial UOC.

PID_00215829
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Introducción

Thomas Edison, el famoso inventor y empresario norteamericano, dijo: "Visión sin ejecución es pura alucinación". Esto mismo se puede aplicar a la gestión de proyectos. Todos los pasos anteriores conducen a la ejecución. La ejecución es el trabajo del jefe de proyecto y de su equipo en el día a día. La ejecución es la 'hora de la verdad'. Esto es especialmente claro en el mundo de las TIC, donde normalmente se fabrica, se integra, se instala o se implanta un producto, una realidad física y tangible que funciona o no, que soluciona o no problemas.
En el ciclo de vida de la gestión de proyectos que se está presentando en todo el material, el siguiente paso tras la planificación de un proyecto es la ejecución (figura 1).
Figura 1. Ciclo de vida de un proyecto
En principio, ejecutar es llevar el plan a la realidad, realizar los procesos, actividades y tareas previstos. Sin embargo, como veremos, este camino no es lineal, no basta con aplicar las previsiones del plan o las reglas de un manual. Aplicar las previsiones del plan no garantiza el éxito (aunque sin plan no sería posible la ejecución). Ejecutar es hacer que las cosas se hagan, conocer y controlar el progreso y tomar las medidas de corrección que correspondan. Por eso, ejecución y control (que trataremos en el módulo siguiente) van muy unidos. Durante la ejecución desplegamos un mayor número de recursos y, en muchos proyectos, actuamos sobre la organización del cliente; por ello, los costes y los riesgos aumentan muy rápidamente.
La ejecución representa la gestión del día del proyecto, desde su lanzamiento hasta su finalización, e incluye la producción de los resultados (entregables de producción), el aseguramiento de la calidad, la gestión de la comunicación y las relaciones con las partes interesadas, la gestión de los recursos humanos y técnicos y la administración de compras y contratos.
En los proyectos TIC, y en las metodologías clásicas de producción de proyectos TIC (como las de gestión del ciclo de vida de desarrollo de aplicaciones, por poner un ejemplo), se suele "tomar la parte por el todo" y pensar que si se gestiona la producción ya se maneja el proyecto. Confiamos que a estas alturas el alumno tenga claro que gestionar el proyecto es mucho más que producir unos entregables. Ahora bien, como hemos mostrado en los módulos anteriores, es en el momento de la ejecución donde se integra la mayor parte de las actividades de la producción y, por tanto, de las metodologías específicas de la producción de cada producto o servicio específico, sea informático, de telecomunicaciones, multimedia o híbrido.
En realidad, el trabajo del jefe de proyecto en el día a día es gestionar, gestionar y gestionar, es decir, hacer que las cosas se hagan en colaboración con otros (personal del equipo y personal del cliente), gestionar la comunicación y tomar y hacer que se tomen decisiones, lo que desde Pinto (1999) se llama el "lado humano" de la gestión de proyectos. Tanto es así, que dedicaremos a este aspecto el último módulo de este material.
Y también por esta razón, las metodologías nos ofrecen poca ayuda (el propio PMBOK, como veremos seguidamente, no proporciona un gran repertorio de herramientas) y normalmente es la madurez personal y profesional del jefe o director de proyecto, adquirida con la práctica repetida y la supervisión adecuada, la que termina marcando la diferencia.

Objetivos

Al finalizar el trabajo con este módulo, deberéis ser capaces de conocer y aplicar algunos de los procesos necesarios para la gestión de la ejecución del proyecto y más en concreto:

  1. Cuáles son los componentes y temas clave a tener en cuenta durante la ejecución.

  2. Cuáles son las tareas y actividades generales del director de proyecto relacionadas con la ejecución.

  3. Cómo se realiza el lanzamiento de un proyecto.

  4. Cuáles son las actividades del jefe de proyecto en el día a día.

  5. Cuáles son los procesos de aseguramiento de la calidad propios de la ejecución.

  6. En qué consisten los procesos de gestión de los recursos humanos asignados al proyecto.

  7. Cuáles son los procesos de comunicación, distribución de la información y gestión de interesados.

  8. Cuáles son los procesos de administración de contratos y compras que se realizan durante la ejecución.

  9. Cuáles son los documentos principales que deben completarse durante la ejecución.

Para una mejor comprensión y aprovechamiento de este módulo, recomendamos su estudio conjunto con el módulo "Seguimiento y control del proyecto" y el módulo "El lado humano de la gestión de proyectos".

1.Los componentes y temas clave de la ejecución

Antes de empezar con la descripción de los procesos y herramientas (por lo demás, no muy desarrolladas) de la ejecución, tal como hemos hecho en los módulos anteriores, nos parece importante hacer algunas reflexiones al alumno sobre cuáles son los elementos y temas clave de la ejecución, en qué consiste en realidad gestionar la ejecución, por encima de las metodologías y herramientas que utilicemos y de los productos o servicios que vayamos a entregar.
Puede decirse que la ejecución se sostiene sobre cuatro pilares (figura 2):
1) Las metodologías y conocimientos técnicos propios de cada tipo de proyecto (de su producción) y, en paralelo, el aseguramiento y control de la calidad de los productos.
2) Las habilidades de liderazgo, comunicación, negociación y gestión del cambio, que trataremos en el módulo "El lado humano de la gestión de proyectos".
3) Las necesidades de control interno y reporte, tanto de los aspectos técnicos como de los progresos en el tiempo y los aspectos económicos, que trataremos en el módulo "Seguimiento y control del proyecto".
4) Habilidades específicas de atención de incidencias, resolución de problemas y toma de decisiones, que trataremos también en el módulo "El lado humano de la gestión de proyectos".
Figura 2. Los cuatro pilares de la ejecución
Fuente: Rodríguez, García, Lamarca (2007)
La ejecución, especialmente en proyectos TIC, es la fase en la que se despliegan las habilidades, conocimientos y metodologías específicas de la profesión y de cada clase de proyectos. Tradicionalmente, ha sido el lugar donde los ingenieros se sienten cómodos, haciendo lo que saben hacer. Sin embargo, a estas alturas ya sabemos que la ejecución es sólo una parte del proyecto, por importante que sea. Y dentro de la ejecución, el despliegue de las capacidades y herramientas de la informática, las telecomunicaciones o los proyectos multimedia es también sólo una parte.
En palabras de Andersen y otros (2003): "La competencia profesional no es suficiente para asegurar el éxito si los aspectos gerenciales no funcionan. Y al contrario, ninguna clase de ayuda administrativa puede asegurar el éxito si falta la competencia profesional. Los dos (gestión y capacidad profesional) son cruciales para el éxito".
Algunos jefes de proyecto se sienten cómodos en el reporting, documentar el progreso, el derroche de actividad y la asignación de recursos en elegantes tablas e informes. El reporting es una parte del control. Sólo reportamos para conocer el estatus del trabajo, el cumplimiento de objetivos y el cumplimiento del plan, y para tomar decisiones. El reporting es sólo una herramienta que nos permite comunicar con el equipo y con el cliente, evaluar y anticipar consecuencias y tomar decisiones. El control es una parte del proyecto tan importante como los conocimientos y metodologías técnicas.
Control no es dirección, es una parte de la dirección. La dirección de proyecto incluye saber organizar y asignar recursos, comunicar y motivar a los equipos, relacionarse con el cliente y con las diferentes partes involucradas, y el resto de las habilidades que analizamos en el capítulo anterior. Dirección tiene que ver con las personas, es como dijimos el 'lado humano' del proyecto.
Control y liderazgo son los requisitos para tomar decisiones: revisar el alcance o el nivel de ambición, reasignar recursos o incorporar nuevos, corregir la planificación y las fechas de entrega, comunicarlo y negociarlo adecuadamente.
La mayor parte de los fallos en la ejecución tienen que ver con un desequilibrio en el peso de estos cuatro componentes o no tener claro su significado. La tabla 1 muestra los fallos más habituales en la práctica de ejecución de proyectos.
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 1
Fallos habituales en la fase de ejecución
Falta de involucración de los usuarios, en cantidad, calidad y a tiempo.
No conseguir que los equipos trabajen juntos de manera productiva.
Uso de jerga o de expresiones incomprensibles para el cliente.
La gente del cliente no trabaja bien con el equipo.
Desatención de los aspectos funcionales, la toma de requisitos y el análisis del problema de negocio.
Gran número de errores en la programación, por bajo nivel del análisis funcional y poca relación con los equipos del cliente.
Maneras diferentes de documentar el trabajo y de reportar.
Diferentes reglas y procedimientos para diferentes miembros del equipo.
Los profesionales de las diferentes disciplinas o empresas van a su aire.
Continuos cambios sin control o demasiada replanificación, que consume energía y crea confusión en los equipos.
Instrucciones contradictorias.
Descuidar los hitos intermedios y todas las oportunidades posibles de mostrar con productos reales (por ejemplo, prototipos) el progreso del trabajo y obtener feedback del cliente.
Falta de pruebas, metodologías y productos de pruebas y de tiempo suficiente para pruebas a todos los niveles, en especial, las pruebas finales con el cliente.
Desatención a la formación y soporte al usuario final y a todos los aspectos de gestión del cambio.
Desequilibrio entre los objetivos de tiempo, coste y calidad.
Equipos técnicos o funcionales que buscan la perfección, sin consideración a los objetivos de tiempo y coste.
Obsesión y ritualización del reporting.
Parálisis por el análisis.
Exceso de carga administrativa en tareas de documentación poco relevantes.
No entender el significado instrumental del reporting, no analizar los elementos significativos para anticipar situaciones futuras y tomar decisiones.
Exceso de optimismo.
Ocultar la dimensión de los problemas, suponer que lo peor ya ha pasado y que todo irá mejor a continuación.
No levantar alarmas y no comunicar los riesgos.
Falta de comunicación formal y estructurada dentro del equipo y, sobre todo, con el cliente.
O un exceso de información que no facilita la comprensión del estatus, señalar los elementos relevantes y provocar decisiones.
Responsabilidad sin autoridad.
Conflictos en la asignación de recursos y prioridades entre el jefe de proyecto y los responsables de línea del cliente o de las empresas subcontratistas.
La literatura reciente de dirección de empresas está insistiendo en el enfoque y habilidades de ejecución como los temas más críticos para conseguir el éxito. Puede disponerse de una estrategia ganadora, una posición competitiva envidiable, productos sin rival, un equipo y una organización preparada, estados financieros sólidos y acceso fácil al capital... Nada de esto sirve de nada si no estás preparado para la ejecución y no ejecutas de forma consistente y sostenida. Lo mismo puede decirse de los proyectos y del trabajo del jefe de proyecto.
Los siete comportamientos del líder de cara a la ejecución
Conoce a tu gente, el negocio del cliente y el proyecto.
Insiste en el realismo: pon objetivos que tu equipo pueda cumplir.
Establece objetivos y prioridades claras y simples.
Sigue las cosas de cerca: asegura quién debería hacer qué, y cuál es el paso siguiente.
Recompensa a los que hacen, los que están enfocados a la ejecución y ejecutan (éstos son los que te salvarán la vida).
Enriquece las capacidades de ejecución de tu gente a través del coaching.
Conócete a ti mismo, tus emociones, estilo de dirección y la influencia que eso tiene sobre los demás.
Fuente: Adaptado de L. Bossidy; R. Charan (2002). Execution: the discipline of getting things done. Nueva York: Crown Business.

2.Los procesos de gestión de la ejecución del proyecto

El Plan de proyecto, con todos los componentes más o menos básicos, más o menos complejos o desarrollados que hayamos establecido según el tipo de trabajo, constituye la "línea base" para la ejecución del plan y, por lo tanto, el documento (o grupo de documentos) de referencia para las actividades diarias de gestión y también para el reporting (o documentación de seguimiento y control).
Como recordatorio, los componentes más importantes del plan, según presentábamos en el módulo "Iniciación del proyecto y trabajos previos", eran los siguientes:

  • La definición detallada del alcance, resultado del análisis de requisitos.

  • La estructura de distribución del trabajo (EDT) y el plan de hitos.

  • El organigrama del proyecto y la matriz de roles y responsabilidades.

  • El calendario o cronograma de proyecto.

  • El presupuesto.

  • El plan de gestión de riesgos.

  • El plan para la gestión de configuraciones y versiones.

  • El plan de calidad.

  • El plan de recursos humanos.

  • El plan de comunicación y gestión de interesados.

  • El plan de administración de compras y contratos.

Sin embargo, como hemos señalado en la introducción, gestionar la ejecución de proyecto es mucho más que ejecutar el plan (o, menos aún, controlar su ejecución). Gran parte de las actividades del jefe de proyecto tienen que ver con la gestión del día a día, respuesta a incidencias, negociaciones con personal del cliente, miembros del equipo o proveedores, decisiones o propuestas de decisiones y trabajo administrativo. La gestión de las partes interesadas y la comunicación y distribución de la información son críticos.
Como se ve, poco de todo esto tiene que ver con la producción en sí misma de los entregables, tal o cual servicio o producto de telecomunicaciones, multimedia o informática que, ciertamente, debe funcionar, estar bien construido y ser sostenible, pero cuyas bondades (no nos cansamos de repetirlo) son sólo una parte (por desgracia no muy grande) de la satisfacción del cliente, el cumplimiento de los tiempos, el presupuesto y el alcance, es decir, en definitiva el éxito del trabajo.
Durante la ejecución del proyecto, la realidad puede hacer que se deban cambiar algunos o muchos componentes del plan, por razones diversas: solicitudes de cambios por parte del cliente o del equipo, mayor consumo de recursos para ciertas actividades, cambios en la disponibilidad de las personas o riesgos anticipados o no. Todas estas variaciones sobre el plan obligarán a un análisis detallado y a la formulación de escenarios y propuestas de corrección o replanificación sobre la "línea base".
Los procesos comprendidos en la gestión de la ejecución del proyecto según el PMBOK son los siguientes (tabla 2):
Tabla 2
Los procesos de la ejecución del proyecto de acuerdo con el PMBOK
1) Dirigir y gestionar la ejecución del proyecto.
2) Realizar el aseguramiento de la calidad.
3) Incorporar el equipo de proyecto.
4) Desarrollar el equipo de proyecto.
5) Dirigir el equipo de proyecto.
6) Distribuir la información.
7) Gestionar las expectativas de los interesados.
8) Efectuar las contrataciones.
1) Dirección y gestión integrada del proyecto
Como en las etapas anteriores, se trata del trabajo principalmente del director de proyecto, para asegurar la supervisión del trabajo en el día a día, gestionar e integrar los diferentes componentes de la ejecución, producir los entregables acordados, documentar la información del trabajo realizado y las peticiones de cambios, mantener o actualizar los planes de proyecto y documentos asociados, y actualizar las previsiones. Incluye también todas las tareas de representación del proyecto ante terceros.
2) Aseguramiento de la calidad
Es el proceso de auditar los requisitos de calidad y los resultados de los procesos de seguimiento y control de la calidad que se hayan establecido en el plan, de acuerdo con definiciones estándar, las del cliente o las de la propia compañía proveedora. Frecuentemente, en proyectos grandes, este proceso es asumido por recursos externos especializados.
3) Gestión de recursos humanos
Comprende los procesos de obtener el equipo que actuará efectivamente en el proyecto (y que no siempre coincide con el que se planificó), asignarle sus actividades según el plan de trabajo, y ayudarle en su desarrollo, a través de la retroalimentación (feedback), la evaluación, la formación en el trabajo, la motivación y el manejo de los conflictos. Esto incluye la integración de personas que no están acostumbradas a trabajar juntas y, frecuentemente, a personal de diferentes organizaciones, incluido personal del cliente.
4) Distribución de la información
La información producida en el proyecto (normalmente, los documentos de progreso y seguimiento, y la documentación de las reuniones más o menos formales de trabajo) se distribuyen a las partes interesadas de acuerdo con un plan. Decidir qué se distribuye, a quién, cuándo y a través de qué canales es trabajo del jefe de proyecto.
5) Gestión de las expectativas de los interesados
Los interesados (stakeholders) son cualquier parte de la organización (o a veces partes ajenas a la propia organización) que tiene alguna clase de interés, necesidad o expectativa con relación al proyecto. En las fases anteriores, los habremos identificado, establecido su interés e influencia, analizado sus requisitos y definido una estrategia y un plan proactivo sobre cómo gestionar todo esto. Durante la ejecución ponemos en marcha este plan, pero además respondemos a las situaciones y conflictos del día a día, mediante la comunicación, negociación y toma de decisiones. Además actualizamos el plan de gestión de interesados, que puede ser extraordinariamente cambiante y variable. Una inadecuada o inexistente gestión de interesados puede hacer fracasar el proyecto.
6) Administrar las compras y contratos
Durante la ejecución llevamos a cabo la selección de proveedores, redactamos los contratos, supervisamos su ejecución, atendemos los conflictos y administramos económica y legalmente la relación. Lo mismo hacemos con respecto a la relación, si es externa, entre nuestra compañía y la organización del cliente.

3.Dirección y gestión integrada del proyecto

El grupo de procesos de "dirección y gestión integrada del proyecto" forma parte del área de conocimiento de "integración", según la terminología de PMBOK, e incluye la realización de todas las actividades definidas en el plan de gestión de proyecto o plan de proyecto, necesarias para alcanzar los objetivos del mismo. Las actividades más importantes de este grupo son (PMBOK, 2008):

  • Realizar las actividades y tareas para cumplir los requisitos del proyecto.

  • Crear o producir los entregables (productos o servicios) objeto del proyecto.

  • Asignar, organizar, entrenar y gestionar a los miembros del equipo del proyecto.

  • Implementar los métodos y estándares de trabajo planificados.

  • Establecer y gestionar los canales de comunicación del proyecto, tanto internos (dentro del equipo) como externos (con el cliente y partes interesadas).

  • Generar datos del proyecto (acerca de costes, calendario, progreso técnico y de calidad) para reportar sobre su estatus y realizar previsiones.

  • Documentar las peticiones de cambios y adaptar los cambios aprobados al plan de proyecto o proponer y actualizar los planes.

  • Documentar y resolver las incidencias.

  • Implantar los cambios aprobados, a través de acciones correctivas, preventivas o de reparación de defectos.

  • Gestionar los riesgos e implementar las actividades de respuesta.

  • Gestionar la relación con los contratistas.

  • Recoger y documentar las lecciones aprendidas para el futuro.

Un resumen de los principales componentes de este grupo de procesos se presenta en la figura siguiente.
Figura 3. Componentes principales de la Dirección y Gestión Integrada del Proyecto
PMBOK (2008)
Como hemos venido diciendo, los procesos del área de conocimiento de 'integración' le corresponden normalmente al jefe o director de proyecto, quien también se encarga de la gestión de los documentos que consideramos necesarios en esta etapa. Estos documentos son:

  • El informe de lanzamiento (o kick-off) de proyecto.

  • El informe de incidencias abiertas (u open issues).

  • El documento de petición de cambios.

  • El registro de cambios.

  • Los informes de progreso.

Seguidamente, dedicaremos tres apartados a presentar el lanzamiento del proyecto, la gestión de incidencias y la gestión de cambios. Los informes de progreso son el resultado del seguimiento de las diferentes áreas del proyecto (presupuesto, calidad, tiempo, recursos humanos, etc.) y forman parte del área o grupo de procesos de comunicación y los explicaremos con más detalle en el módulo "Seguimiento y control del proyecto".

3.1.El lanzamiento del proyecto

El lanzamiento supone un momento clave en el proceso de ejecución del proyecto. Aunque seguramente es un poco exagerado, para algunos una buena reunión de lanzamiento (kick-off meeting) es un 90% del éxito del proyecto. Por tanto, vale la pena prepararla con cuidado, conseguir la presencia de los interlocutores clave, dedicarle el tiempo que sea preciso y disponer de buenos contenidos y materiales.
En este momento, el gerente de proyecto asegura la involucración de todos los agentes participantes, completa la definición de los procesos de gestión de proyecto, refina y detalla el plan de proyecto e incorpora a todos los miembros de su equipo. La realización de todas estas actividades asegura la gestión eficaz del proyecto una vez haya empezado.
En la práctica, la reunión de lanzamiento es la primera oportunidad que tiene el director de proyecto para compartir con los representantes de las partes interesadas y los principales miembros del equipo de proyecto los componentes esenciales del trabajo (alcance, tiempo, calidad y costes) y asegurar un proyecto de éxito. Como dicen Snyder y Parth, "es donde el jefe de proyecto establece las expectativas, los miembros del equipo y la cultura para el resto del proyecto. Es también donde los miembros del equipo establecen sus expectativas con relación al jefe de proyecto".
Antes de empezar cualquier proyecto TIC, el gerente debe asegurar que se han cumplido los siguientes hitos:

  • Las expectativas de los agentes involucrados coinciden y se alinean con las del equipo.

  • Confirmar la definición del proyecto y que no hay cambios de última hora.

  • El plan de proyecto, con los principales hitos, responsables y actividades y el calendario con fechas de inicio y finalización, ya ha sido aprobado por los órganos de dirección del proyecto.

  • Los miembros que formarán el equipo de proyecto ya han sido seleccionados e incorporados, conocen los objetivos y el plan del proyecto, disponen de los recursos y la formación requerida, conocen sus roles y responsabilidades, conocen las tareas que tienen asignadas y conocen las normas de comunicación y relación dentro del equipo.

  • Los gestores de línea (directores funcionales, jefes de departamento) ya han aceptado y comprometido su aportación de recursos al trabajo.

Para el lanzamiento del proyecto, suele ser conveniente un cierto ritual o escenificación. Vale la pena un comité de dirección de lanzamiento y sesiones formales de presentación con las diferentes partes interesadas, en especial aquellos departamentos que tienen que aportar recursos y validar o utilizar los productos finales. Es bueno a veces usar los comités u órganos ordinarios de la empresa para realizar estas presentaciones y no consumir tiempo extra o reuniones específicas.
Vale la pena incluir en esta o estas reuniones a todas las personas que van a verse afectadas por el proyecto (o asegurar que lo trasmiten en los contenidos, forma y canales adecuados a sus colaboradores), para asegurar la comprensión de los objetivos y limitaciones, la aportación que se espera de cada uno y conseguir, en lo posible, su aceptación o "compra". Cuando acabe la reunión de lanzamiento, todos los participantes deben tener una comprensión clara de qué pasará en el proyecto, cuándo pasará y cuál es su papel.
De nuevo, usando palabras de Snyder y Parth (2007): "Cuando la gente entra en la reunión es parte de un grupo. Cuando sale, debe ser parte de un equipo. Esta es la mejor manera de empezar un proyecto".
En la reunión de lanzamiento con el equipo de dirección, las herramientas principales son el plan de hitos y la matriz de responsabilidades con relación a los hitos. Es decir, qué productos se obtendrán y cuándo y qué papel tiene cada uno para su consecución.
A veces, vale la pena hacer una reunión separada de lanzamiento con todos los miembros del equipo de trabajo y, en su caso, reuniones individuales con los miembros, para asegurar que se comprende el proyecto (el qué, el por qué y el cómo); que cada cual comprende su papel y responsabilidades y las tareas que le han sido adjudicadas; para confirmar qué recursos necesitarán, y para concretar qué, cómo y cuándo deben reportar al jefe de proyecto. En la reunión de lanzamiento con el equipo de trabajo, las herramientas principales son el plan de actividades y tareas y la matriz de responsabilidades con relación a las actividades.
Sin embargo, no es sólo un tema de herramientas. La reunión de lanzamiento debe tocar las cabezas y los corazones, debe motivar emocionalmente, crear un sentimiento de que el empeño vale la pena y de lo que cada persona, el grupo y la empresa u organización obtendrá de bueno con el trabajo y de la dimensión del esfuerzo y las dificultades.
Después de la reunión de lanzamiento, debe hacer un informe, de los que hemos considerado "básicos". Una muestra o ejemplo se presenta en la figura 4.
Figura 4. Ejemplo de informe de lanzamiento (kick-off)

3.2.La gestión de incidencias

Llamamos incidencias a los acontecimientos inesperados que aparecen en el proyecto, que le pueden afectar y que requieren la intervención y control del jefe de proyecto. Normalmente, no alcanzan la categoría de riesgos ni requieren que se reporte al cliente; no son cambios en el alcance; tampoco tienen que ver con el seguimiento de las actividades ordinarias, ni con el presupuesto, ni con ninguna de las categorías anteriores. Pero son importantes, requieren de nuestra atención y tienen que manejarse.
Concerns, issues y problems
En inglés se llaman issues. Issue es una palabra muy rica y muy utilizada en la vida y en la gestión de empresas, que no existe en catalán y en castellano. Antes de que algo se convierta en problema, es un issue, algo que requiere nuestra atención y de lo que merece la pena ocuparse.
En inglés, aún existe un matiz anterior. Antes de que algo sea un issue puede ser un concern, una preocupación, que es subjetiva, algo que preocupa a alguien y que puede convertirse en un issue.
En inglés, un problema (a problem) es algo muy serio, que sólo ocurre excepcionalmente y que supera nuestro control, como en la película Apolo: "Houston, tenemos un problema". Esto explica que, en la disciplina de gestión de proyectos, la gestión de los issues sea muy importante, por si acaso un día se convierte en un problema.
Si lo pensamos, es toda una filosofía de la vida: la gente en vez de pre-ocuparse, se ocupa.
Por ejemplo, un miembro del equipo cae enfermo o decide marcharse de la compañía; la empresa que es nuestro cliente decide adquirir otra empresa y eso puede cambiar sus prioridades actuales; suben los precios o las tarifas de nuestro subcontratista y en el contrato nada dice sobre esto; el constructor de un producto de software o hardware con el que estamos trabajando cambia la versión o deja de dar soporte a la versión que estamos utilizando; necesitamos quedarnos el fin de semana en la oficina y el cliente no tiene ningún servicio de seguridad para abrirnos la puerta; nos damos cuenta de que no hemos valorado correctamente una actividad que el proyecto requiere; el cliente nos pide varias copias encuadernadas de los manuales, cosa que no teníamos prevista; uno de los miembros del equipo ha tenido un hijo; el alcalde de la ciudad decide votar electrónicamente en un equipo que no hemos podido probar a tiempo.
Es crítico que el jefe de proyecto tenga "las antenas puestas" en todo momento y sea capaz de inculcar en los miembros del equipo la sensibilidad para identificar, y reportarle muy rápido cualquier tema que pueda afectar al proyecto.
Después de una valoración rápida, el gerente introduce el tema o issue en una lista o documento complementario en el que se describen los issues, el impacto en el proyecto, las acciones para resolverlo, en qué fechas y el estado de resolución. En la jerga de gestión de proyecto se habla de que los issues pueden estar abiertos o cerrados, según se hayan o no resuelto, y es frecuente presentar un formulario de issues abiertos (open issues) en las reuniones de seguimiento, al menos las internas del equipo de proyecto.
Otro término es el de propietario o dueño (issue owner) del issue, es decir, quien tiene a su cargo la resolución.
La figura 5 presenta un ejemplo típico de un informe de issues.
Figura 5

3.3.La gestión de cambios

Cambio es cualquier cosa que aumenta (casi siempre) o reduce (pocas veces) significativamente el alcance del proyecto o de los entregables, los procesos, planes, requisitos o recursos, y que por tanto, difícilmente no afectará al tiempo, el coste o la calidad del conjunto. Cuanto más tarde se produzcan los cambios, más afectan al coste y lo hacen de una manera más que proporcional, no sólo por el coste directo de cambiar, sino por los costes asociados de valoración, control y gestión del impacto asociado a los cambios. La gestión de los cambios es un coste del proyecto.
Es importante determinar a priori qué quiere decir "significativamente", es decir, qué cambios tienen un impacto suficiente para requerir un tratamiento formal de gestión de cambios (registro, valoración, aprobación, actualización de planes, etc.), que puede a veces ser muy importante.
La gestión de los cambios y la gestión del cambio
Vale la pena tener claro que una cosa es la gestión de los cambios en las dimensiones principales del proyecto, a la que nos referimos aquí, y otra cosa es lo que ahora se conoce como gestión del cambio. En este caso, es la lengua inglesa la que induce a confusión, ya que llama a las dos cosas de la misma manera. La gestión del cambio, a la que nos referiremos también en el módulo "El lado humano de la gestión de proyectos", puede definirse como todas las cosas que tienen que pasar en el cliente para que el proyecto tenga éxito, es decir, los cambios que el cliente tiene que introducir en su organización, los procesos de negocio, los procesos de gestión de personas, las habilidades y competencias... Se refiere también al proceso de intervención y facilitación que desde el proyecto se realiza para que todo esto ocurra, es decir, las técnicas y herramientas que se despliegan en el proyecto para hacer posible los cambios que tienen que ocurrir en el cliente para que el proyecto sea un éxito.
Los cambios en los proyectos TIC suelen provenir de cuatro fuentes (Snyder y Parth, 2008, modificado):

  • Errores en la definición del producto, por una mala comprensión de las necesidades del cliente o de los requisitos de los usuarios.

  • Errores en la definición del proyecto, por una mala valoración del trabajo necesario para la ejecución del producto.

  • Cambios solicitados por el cliente, normalmente una ampliación del alcance inicial (del tipo "pues ya que hacemos esto, podríamos hacer además esto otro"...) o de los calendarios de entrada en producción o de los recursos desplegados, o cambios legales o de oportunidad.

  • Cambios solicitados por el equipo de trabajo, para hacer algo mejor, incluso a veces más rápido o más barato. Normalmente, se trata de cambios en la tecnología o la arquitectura o aumento de las prestaciones. Son también peligrosos.

Como ocurre con otros procesos propios de la ejecución, distinguir la gestión de cambios y el control y seguimiento de cambios (que estudiaremos con el módulo "Seguimiento y control del proyecto") no es evidente. Realmente, en seguimiento y control de proyecto se tendrían que ubicar todos los procesos de control y seguimiento, mientras que en la ejecución, estarían los procedimientos de registro y gestión. O dicho de otro modo, los resultados del control se aplican en la ejecución.
Según hemos dicho, los cambios pueden ser sobre cualquiera de las variables o dimensiones del proyecto, aunque los más importantes y de mayor impacto son siempre los que afectan al alcance.
Según la experiencia y la literatura, una de las causas más importantes del fracaso en proyectos tecnológicos es no saber definir y gestionar correctamente los límites de alcance de un proyecto. Muchas veces, la tendencia natural de un gerente de proyecto es decir sí a todo lo que pide el cliente, ya sea éste interno o externo, aunque sea inasequible. Siempre es incómodo decir no o decir "debemos revisar el alcance" ante estas situaciones, especialmente si quien lo pide es el director, cliente o consejo de administración.
Sin embargo, en la realidad de un proyecto, cualquier cambio de alcance tiene consecuencias inmediatas sobre los entregables, sobre el plan de trabajo y el calendario, sobre los recursos dedicados, sobre el equipo de trabajo y sobre los propios riesgos inherentes a cualquier cambio.
Ejemplo
Una entidad financiera europea de renombre internacional encargó un proyecto de implantación de una solución CRM de gestión de las relaciones con el cliente a una empresa consultora de primer nivel. En la ejecución del proyecto, la gerencia del proyecto, a solicitud de la dirección de la compañía, aceptó incluir de manera adicional y durante muchos meses nuevos contenidos y servicios que no estaban al alcance inicial de los desarrollos contratados. Durante meses, el gerente no valoró ni avisó convenientemente de las consecuencias y el impacto que los nuevos contenidos y funciones podían tener en el tiempo, recursos y coste de desarrollo de la nueva solución. El resultado fue un retraso de meses en el lanzamiento, la dedicación adicional de buena parte del equipo durante este tiempo, y un coste que a la finalización del proyecto doblaba el presupuesto inicial estimado y que para aquel entonces ya nadie, ni el cliente ni el integrador, quería asumir.
Una de las funciones principales del gerente de proyectos es, por lo tanto, la de acordar, mantener y rectificar los límites del alcance de un proyecto.
Con relación al alcance, lo más importante es lo que se hace antes, en particular en el momento de la definición del proyecto (la definición preliminar del alcance) y su plasmación en el contrato. El alcance representa la plasmación concreta de los objetivos del proyecto, el nivel de detalle, en definitiva, el nivel de ambición.
En la fase de planificación, el alcance se debe validar de nuevo y convertirlo en hitos y entregables del trabajo en el documento de definición detallada del alcance. También en esta etapa se deben establecer los procesos de monitorización y ajuste del alcance de un proyecto que servirán de control en su ejecución. Durante la ejecución del proyecto, cualquier cambio en el alcance del proyecto se debe realizar y acordar conforme a estos mecanismos.
Los cambios de alcance deberían ser los menos posibles. O si los hay, deben hacerse conforme a los mecanismos de gestión establecidos y actualizar la planificación para asegurar el cumplimiento de los estándares de calidad, tiempo y coste acordados.
Algunos arguyen que un cambio en el alcance no es importante en sí mismo; lo importante es asumir las consecuencias de los cambios de alcance. Es correcto. Pero también es cierto que los cambios de alcance tienden a alargar y desequilibrar los proyectos, crear confusión e incertidumbre en los equipos, son más complicados de comunicar e influyen sobre el momento y la concentración de los miembros. Muy pocos cambios de alcance son para hacer menos; normalmente son para hacer más, cuestan más dinero y más tiempo.
En la etapa de Ejecución, los documentos que se utilizan para la gestión de cambios son un Informe de petición de cambios y un Registro vivo de cambios, de los cuales presentamos ejemplos en las figuras siguientes.

4.El aseguramiento de la calidad

Según vimos en la etapa de planificación, el plan de proyecto puede o no contar con un plan de calidad, aunque nuestra recomendación es que lo haya, a poco complejo que sea el producto o el proyecto. También vimos entonces que debe distinguirse entre la calidad del producto (su adecuación a unos determinados estándares de la industria) y la calidad de los procesos de gestión del proyecto.
En proyectos TIC, es frecuente que cada vez se cuide más la calidad de los productos y acaso se descuide la calidad de los procesos de gestión de proyecto, tanto por parte del equipo como parte del jefe de proyecto, más interesados ambos en los aspectos técnicos y en la calidad de los entregables de producción. Por eso en grandes organizaciones proveedoras de servicios TIC se crean departamentos separados o se contratan auditores externos que vigilan el cumplimiento de los estándares de calidad de los procesos de gestión.
Los componentes principales del grupo de procesos de aseguramiento de la calidad se muestran en la figura 8.
Figura 8. Componentes principales del aseguramiento de la calidad
Fuente: PMBOK (2008)
Como en otros procesos del grupo de ejecución, no es evidente la separación entre los procesos de control y seguimiento de la calidad y los propiamente de ejecución. Para simplificar, podríamos decir que los de ejecución se aprovechan de los resultados del control para implantar medidas de corrección y mejora.
Efectivamente, cada vez más, el aseguramiento de la calidad forma parte de un programa general de mejora continua de los procesos o de la calidad, en línea con las propuestas de escuelas como las de Deming, Juran y otras. Esta clase de aproximación facilita también que los empleados (normalmente miembros de los equipos de trabajo de muchos proyectos) identifiquen problemas y oportunidades de mejora y formulen propuestas para simplificar, corregir, automatizar o eliminar procesos o implantar nuevas técnicas y herramientas.
Las auditorías de calidad son, en cambio, revisiones independientes para determinar si las actividades realizadas en el proyecto cumplen con las políticas, procesos y procedimientos definidos en el plan de calidad (o las de la organización proveedora, el cliente, etc., según sea la definición). Normalmente, se revisa una muestra de los procesos y documentos de gestión del proyecto con el objetivo de (PMBOK, 2008):

  • Identificar si se están implementando buenas prácticas de gestión.

  • Identificar los gaps o deficiencias.

  • Compartir las buenas prácticas que se hayan implantado en proyectos similares.

  • Ofrecer ayuda para su implementación.

  • Contribuir a la creación de un repositorio de buenas prácticas y lecciones aprendidas en la gestión de proyectos.

Por ejemplo, una auditoría de calidad puede detectar si un jefe de proyecto ha iniciado un trabajo sin la firma de un contrato por parte del cliente, si se han sometido al comité de cambios o al comité de dirección cambios relevantes que afectan al alcance, si se ha chequeado con el usuario el documento de toma de requisito, si se han realizado las pruebas acordadas, si se están llevando a cabo las acciones para asegurar el cobro de las facturas en los plazos pactados o si el equipo de proyecto está trabajando en las condiciones y con los medios adecuados.
Eventualmente, los resultados de una auditoría de calidad pueden utilizarse para la evaluación profesional del jefe de proyecto y, si se detectan casos de mala práctica o conductas deshonestas, para la apertura de expedientes disciplinarios o acciones legales. La gestión de proyectos es una cosa seria. En algunas profesiones, como la ingeniería de telecomunicaciones, la empresa y el jefe de proyecto tienen responsabilidades jurídicas.

5.La gestión de recursos humanos del proyecto

Comprende los procesos de obtener el equipo que actuará efectivamente en el proyecto (y que no siempre coincide con el que se planificó), asignarle sus actividades según el plan de trabajo, y ayudarle en su desarrollo, a través de la retroalimentación (feedback), la evaluación, la formación en el trabajo, la motivación y el manejo de los conflictos.
Esto incluye la integración de personas que no están acostumbradas a trabajar juntas y, frecuentemente, personal de diferentes organizaciones, incluido personal del cliente y de contratistas externos.
En la mayor parte de los proyectos TIC, el grueso del coste y del valor añadido es el trabajo de personas altamente cualificadas que ponen sus capacidades al servicio de un empeño común. La gestión de las personas, su organización e interacción formal e informal es por tanto clave para el éxito del trabajo. Consecuentemente, también lo son para el jefe de proyecto las competencias de gestión de las personas, como el liderazgo, el trabajo en equipo, la comunicación, la negociación, la motivación o la resolución de conflictos.
Por este motivo, en estos materiales, hemos optado por tratar con más profundidad los temas de personas de la gestión de proyectos en el módulo final de este material, que llamamos "El lado humano de la gestión de proyectos". En este apartado, para no romper la estructura de la metodología, presentaremos los procesos y componentes de gestión en un enunciado breve y remitimos al alumno a su estudio conjunto con los materiales del módulo "El lado humano de la gestión de proyectos".

5.1.Conseguir el equipo de proyecto

Consiste en el proceso de confirmar la disponibilidad de los recursos planificados y obtener el equipo que trabajará efectivamente en el trabajo.
Si no están disponibles, lo que ocurre con frecuencia, debe configurarse un equipo con recursos de experiencia y cualificación equivalente o esperar a su disponibilidad.
El jefe de proyecto frecuentemente no es responsable de la selección o contratación de los recursos o de la negociación con los contratistas, que queda en manos de otro departamento central, pero es necesario que participe e influya tanto como pueda en este proceso, en especial cuando se trata de recursos más experimentados o especialistas en determinadas materias.
Seguidamente, los calendarios y presupuestos deben revisarse para adecuarlos a las condiciones del equipo con el que se contará efectivamente.
Los componentes de este grupo de procesos se muestran en la figura 9.
Figura 9. Componentes del proceso de conseguir el equipo de proyecto
Fuente: PMBOK (2008).

5.2.Desarrollar el equipo

Como se dijo antes, lo que hace diferente al grupo de personas que apenas se conocían antes de empezar el proyecto, del que ahora trabaja con nosotros es que son o tienen que ser y comportarse como un equipo para conseguir un objetivo común.
Crear un ambiente que facilite el trabajo en equipo y que permita el desarrollo individual y colectivo de sus miembros y la mejora del rendimiento del trabajo es uno de los retos del jefe de proyecto.
Como veremos extensamente en el módulo "El lado humano de la gestión de proyectos", para conseguir esto el jefe de proyecto tiene que desarrollar capacidades y habilidades personales diversas de construcción de equipos (team building). Pero tan importante o más que eso es que la organización u organizaciones en las que los miembros del equipo desempeñan su trabajo dispongan de los mecanismos y procesos de gestión de recursos humanos cualificados, como son la asignación, desarrollo profesional, recompensa, retribución, formación, etc. Difícilmente, puede el gerente de proyecto tener éxito con herramientas "blandas" (soft) si los instrumentos y procesos "duros" (hard) no existen o no funcionan. El resultado será contraproducente.
La figura 10 muestra los principales componentes del proceso de desarrollo del equipo.
Figura 10. Componentes del proceso ''Desarrollar el equipo''
Fuente: PMBOK (2008).
Como puede verse, el principal resultado es la evaluación del rendimiento del equipo. Esta evaluación debe medirse con indicadores que son normalmente de dos clases. Por un lado, medimos la efectividad del equipo en términos de la consecución de los objetivos del proyecto, de su capacidad de ejecutar en tiempo, coste y calidad. Por otro, medimos la efectividad de sus miembros y del jefe de proyecto en cuanto a sus competencias profesionales y su capacidad de trabajar en equipo.

5.3.Gestionar el equipo

Es un grupo de procesos muy cercano y complementario al anterior y que también trataremos más extensamente en el módulo "El lado humano de la gestión de proyectos".
Se trata teóricamente de que el jefe de proyecto observa el comportamiento del equipo y evalúa su rendimiento y funcionamiento en el día a día, proporciona retroalimentación (feedback) a los miembros o al equipo en conjunto, resuelve las incidencias y gestiona conflictos.
Aquí son las habilidades de liderazgo, comunicación, negociación y gestión de conflictos las que se ponen en juego, y también los estilos de dirección de cada jefe de proyecto (y los de trabajo en equipo de sus componentes).
Desde el punto de vista de las personas, el resultado influye en las evaluaciones individuales y en las recomendaciones sobre desarrollo, formación y recompensas. Desde el punto de vista del proyecto, el resultado puede producir cambios en las asignaciones de tareas o responsabilidades o eventualmente cambios en algunos recursos y revisiones del calendario o presupuesto.

6.Distribución de la información

Según vamos viendo, gran parte del trabajo de gestión de la ejecución tiene que ver con tomar decisiones y acciones de prevención y corrección, a partir de la observación, de la interacción con el cliente y el equipo de trabajo, y de la información que se recibe de los procesos formales de seguimiento y control. La otra parte tiene que ver con la comunicación y gestión de las personas, dentro y fuera del equipo de trabajo. La distribución de la información del proyecto es uno de los procesos formales más importantes de la comunicación.
La información producida en el proyecto (normalmente, los documentos de progreso y seguimiento, y la documentación de las reuniones más o menos formales de trabajo) se distribuyen a las partes interesadas de acuerdo con un plan. Decidir qué se distribuye, a quién, cuándo y a través de qué canales es trabajo del jefe de proyecto, que es quien normalmente actuará como portavoz del proyecto. Pueden surgir también demandas inesperadas de información a las que hay que responder (o no) de acuerdo con políticas y principios claros.
Los componentes del proceso de distribución de la información de acuerdo con PMBOK son los siguientes (figura 11):
Figura 11. Componentes del proceso de distribución de la información
Fuente: PMBOK (2008)
El jefe de proyecto debe recibir un entrenamiento y ejercitarse en la práctica de identificar los modelos y barreras que facilitan o dificultan la comunicación en situaciones específicas, elegir los medios más adecuados, el estilo tanto oral como escrito y técnicas de presentación, facilitación y gestión de reuniones.
Suele ser una buena práctica buscar la comunicación directa, oral y persona a persona en situaciones de conflicto, real o potencial, o en momentos críticos para el proyecto, para manejar las expectativas y preocupaciones de los interesados con mayor influencia en el proyecto. Es bueno llegar a las reuniones de dirección con los temas bien trabajados con las personas clave que participarán en la reunión, y distribuir la información por anticipado.
Los resultados de las reuniones de seguimiento del proyecto tienen frecuentemente una naturaleza no sólo informativa, sino de compromiso y aprobación del trabajo realizado, las previsiones y la participación de cada miembro y sus equipos. Por lo tanto, pueden usarse eventualmente en situaciones de conflicto, incluso legalmente.
El documento o producto más habitual del proceso de distribuir la información en la fase de ejecución es el Informe de progreso o Informe de seguimiento, que reúne los resultados del reporting con relación al plan, las previsiones y los documentos de cambios. Un ejemplo de formulario se presenta en la figura 12.
Como hemos dicho, ejecución y control son actividades solapadas y a veces la diferencia parece artificial. Según PMBOK, estrictamente, la preparación del contenido de los informes se hace en la etapa de control y seguimiento. Aquí, en la etapa de ejecución, sólo se hace la distribución.
Figura 12. Formulario de Informe de progreso

7.Gestión de las expectativas de los interesados

Los interesados (stakeholders) son cualquier parte de la organización (o a veces partes ajenas a la propia organización) que tiene alguna clase de interés, necesidad o expectativa con relación al proyecto.
En las etapas anteriores, los habremos identificado, establecido su interés e influencia, analizado sus requisitos y definido una estrategia y un plan proactivo sobre cómo gestionar todo esto. Durante la ejecución ponemos en marcha este plan, pero además respondemos a las situaciones y conflictos del día a día, mediante la comunicación, negociación y toma de decisiones. Además actualizamos el plan de gestión de interesados, que puede ser extraordinariamente cambiante y variable. Una inadecuada o inexistente gestión de interesados puede hacer fracasar el proyecto.
La gestión de las expectativas de los interesados, según PMBOK
Gestionar las expectativas de los interesados incluye actividades dirigidas hacia las partes interesadas en el proyecto para influir en sus expectativas, atender sus preocupaciones y resolver incidencias (issues), tales como:

  • Manejar activamente las expectativas de los interesados para aumentar la probabilidad de aceptación del proyecto, negociando e influyendo sobre sus deseos para conseguir y mantener los objetivos del proyecto,

  • Atender sus preocupaciones (concerns), que todavía no se han convertido en incidencias (issues), para anticipar problemas futuros. Estas preocupaciones necesitan ser puestas encima de la mesa y discutidas, examinando los riesgos,

  • Clarificar y resolver las incidencias (issues) que han sido identificadas. La resolución puede derivar en una petición de cambios o puede ser atendida fuera del proyecto, en otra fase o en otra instancia de la organización.

Fuente: PMBOK, 4.ª ed. (2008), pág. 261
Los componentes principales de la gestión de expectativas se muestran en la figura 13.
Figura 13. Componentes del proceso de gestión de expectativas
Fuente: PMBOK (2008).
Conviene dejar claro que gestionar las expectativas no es una especie de manipulación del cliente y los usuarios. La mejor manera de gestionar las expectativas es no prometer lo que no se puede cumplir y cumplir lo prometido. Lo cierto es que vale la pena obtener y, en especial, mantener (sobre todo a lo largo de los ciclos y vaivenes del proyecto) la comprensión y confianza del equipo y del cliente sobre los beneficios, riesgos y dificultades que tiene el trabajo, y que conviene anticipar y responder a sus reacciones a través de acciones preventivas y correctivas.
Muchos de los comentarios que hacíamos en el apartado anterior sobre la comunicación y distribución de la información son aplicables también a la gestión de interesados.
Ved también
Vale la pena también complementar el estudio de esta parte con el repaso de los módulos "Iniciación del proyecto y trabajos previos" y "Planificación del proyecto", en los apartados que hacen referencia a la identificación y planificación de la gestión de interesados, y el módulo "El lado humano de la gestión de proyectos", en el que nos referiremos brevemente a la gestión del cambio.

8.Administración de compras y contratos

Durante la ejecución llevamos a cabo la selección de proveedores, redactamos los contratos, supervisamos su ejecución, atendemos los conflictos y administramos económica y legalmente la relación. Lo mismo hacemos en la relación, si es externa, entre nuestra compañía y la organización cliente.
Los principales componentes del proceso de administración de compras y contratos se muestran en la figura 14.
Figura 14. Componentes del proceso de administración de compras y contratos
Fuente: PMBOK (2008)
No nos extenderemos aquí en esta disciplina, que actualmente está bastante especializada en los departamentos de compras, financieros y jurídicos, respectivamente. Sí que vale la pena recordar, en todo caso, que la responsabilidad última del resultado del proyecto la tendrá el director o jefe de proyecto y que por tanto, le conviene influenciar y supervisar las decisiones que se tomen en este terreno tanto como le sea posible. También es suya la responsabilidad global de la gestión económica del proyecto, y por tanto, de los costes en los que se incurra por las compras y subcontratación y de los costes y riesgos financieros de no cobrar a tiempo.

9.La gestión del proyecto en el día a día

Los anglosajones lo llaman hands-on, algo parecido a "manos a la obra" o "arremangarse". La gestión de proyecto es un trabajo de este tipo. No se puede estar lejos, despegado. Hay que conocer en detalle el estatus del proyecto, qué incidencias o problemas se han producido, cómo afectarán al curso del trabajo y si pueden resolverse fácilmente o no. Conocer también las situaciones que se están produciendo en los procesos del cliente y, aún más, del equipo: cómo se siente la gente, cuál es el clima de trabajo, las relaciones internas y la motivación. Y hay que dejar hacer (activa y deliberadamente) o actuar, si toca y cuando toca (casi siempre, lo antes posible). Todo esto no se conoce ni se puede hacer en el despacho o delante de los papeles o la pantalla con el plan y los documentos de reporting. Se hace con el cliente y con los equipos, en el sitio y hands-on.
Dependiendo del tamaño del proyecto, el gerente puede tener asignadas además determinadas actividades o tareas técnicas relacionadas con los productos o bien actividades staff, como el control de calidad o la documentación. En muchos proyectos, suficientemente grandes y complejos, el jefe de proyecto está asignado a tiempo completo a las tareas de supervisión. En todo caso, es importante entender que el trabajo del gerente no es hacer todo el trabajo, sino asegurar que el trabajo se hace.
El gerente o jefe de proyecto debe planificar y gestionar su tiempo en el día a día, con especial atención a la identificación y resolución de problemas y la gestión de cambios y riesgos. Además debe entrevistarse con las personas del cliente y con los miembros del equipo, formal e informalmente. Por último, debe efectivamente preparar y analizar los informes de control, reuniones de trabajo y presentaciones.
El plan de cada día
Vuestro trabajo es estar seguro de que todo lo que tiene que ocurrir para que el proyecto avance hacia el resultado final, ocurre. En un proyecto puede ocurrir cualquier cosa y por tanto deberíais empezar cada día pensando:

  • ¿Qué cosas están causando ahora mayores dificultades en el proyecto?

  • ¿Qué cosas es más probable que causen problemas en el proyecto en el futuro?

  • ¿Qué acciones son de mi responsabilidad?

  • ¿Qué es lo más importante que debo hacer hoy?

Fuente: Richard Newton (2006). Project Management Step by Step. How to plan & manage a highly successful project. Harlow: Prentice Hall Business.
La jornada de un jefe de proyecto tiene una parte planificada o programada y una parte de imprevistos. La vida de un proyecto es muy dinámica y presenta retos continuos. El trabajo del jefe de proyecto es estructurar lo más posible ese potencial caos y convertir lo imprevisible en previsible. El jefe de proyecto no es un bombero. Pero para dirigir un proyecto se requiere una dosis importante de flexibilidad y creatividad, proporcional a la novedad y desestructuración del problema o del entorno.
Suele ser bueno tener una sesión de trabajo corta y diaria con las personas más experimentadas del proyecto o que llevan la supervisión de algunos ámbitos o subproyectos y también con la persona responsable del día a día del trabajo por parte del cliente. Si el proyecto está en una fase crítica o se están resolviendo dificultades o desviaciones importantes o estamos cerca de la fecha límite o existen incertidumbres mayores, puede ser conveniente tener una reunión del equipo de seguimiento ordinario del trabajo cada día, pero eso no debería ser lo normal.
Las reuniones de equipo de proyecto pueden ser normalmente semanales.
Si se establece un equipo de seguimiento operativo del proyecto por debajo del comité de dirección, las reuniones pueden ser semanales o quincenales.
El comité de dirección se reúne normalmente con periodicidad mensual o en el momento de finalización y entrega de los hitos.
En los días anteriores y posteriores a todas estas sesiones, el jefe de proyecto dedica un tiempo a su preparación y análisis.
Gestionar transversal e integralmente
En su último libro, Managing (2009), Henry Mintzberg, probablemente el más importante gurú vivo de la gestión de empresas, señala que la forma de organizarse propia del proyecto se opone al control remoto y a distancia.
Un proyecto requiere una mezcla equilibrada de diferentes sombreros (los roles) que desempeña un directivo, aunque los más destacados serían los roles de hacer (doing), negociar (dealing) y comunicar (communicating).
Y todo eso lo tiene que hacer transversalmente, hacia dentro de su organización, de la organización del cliente y en relación con otros proyectos.
Eso hace que en su opinión, la gestión de proyectos se parezca más a un oficio artesano (craft), que a una ciencia o una profesión.
Gestionar, dice Mintzberg, es hacer que las cosas se hagan en colaboración con un equipo de personas, que normalmente no lo pueden hacer solas.
Fuente: H. Mintzberg (2009). Managing. Londres: FT/Prentice Hall

10.Resumen

El plan de proyecto o plan de gestión de proyecto, con todos sus componentes, es la "línea de base" o el "mapa de ruta" para gestionar la ejecución del proyecto. Pero el director, gerente o jefe de proyecto tiene que manejar el día a día para asegurar que todo va según lo previsto, para atender situaciones imprevistas y para anticipar posibles problemas. Una gran parte de su trabajo es tomar acciones y decisiones de prevención o corrección.
El día a día del proyecto incluye la gestión de las actividades del plan, el seguimiento de tiempos, costes y recursos y el aseguramiento de la calidad. Todo esto se hace con los miembros del equipo y con el personal del cliente. La comunicación continuada es clave y consume mucho tiempo.
La comunicación y distribución de la información es también crítica para la gestión de las expectativas de los interesados. Esta se realiza a través de los órganos y canales establecidos formalmente y de otros.
El lanzamiento del proyecto y una reunión efectiva de lanzamiento es muy importante para el éxito del mismo.
La gestión de los procesos formales de gestión de la ejecución es, como en el resto de la gestión del proyecto, importante. Pero durante la ejecución son tan o más importantes las habilidades interpersonales de liderazgo, motivación, comunicación, negociación, trabajo en equipo y gestión de conflictos.
Los procesos de gestión de la ejecución son los siguientes:
1)Dirección y gestión integrada del proyecto.
2)Aseguramiento de la calidad.
3)Gestión de los recursos humanos.
4)Distribución de la información.
5)Gestión de las expectativas de los interesados.
6)Administración de compras y contratos.
Dentro de los procesos de dirección y gestión integrada, destaca la gestión de los cambios sobre cualquiera de las dimensiones críticas del proyecto. Los más usuales y críticos son los cambios sobre el alcance del proyecto, debidos a errores en la definición del producto o del proyecto, peticiones del cliente o del equipo o causas externas. Es importante poner en acción un proceso proactivo de gestión de cambios para, en la medida de lo posible, evitarlos o mitigar su impacto. Los cambios son la mayor causa de desviación en tiempo y coste. El coste de realizar cambios crece más que proporcionalmente a medida que avanza el proyecto.
La gestión de proyectos es un oficio que requiere estar encima de las cosas y de la gente, ponerse manos a la obra, arremangarse. Los anglosajones lo llaman hands on. No se puede estar lejos, desvinculado.
Los principales documentos de gestión de proyecto que se producen en esta etapa son los siguientes:

  • Informe de lanzamiento (kick-off) del proyecto.

  • Informe de incidencias (open issues).

  • Documento de petición de cambios.

  • Registro de cambios.

  • Informe de progreso.