Componentes de la gestión de proyectos: las áreas de conocimiento

  • Pere Mariné Jové

    Pere Mariné Jové

    Ingeniero superior en Informática (UPC), magíster en Gestión pública (UAB), DEA en Sociedad del conocimiento y de la información (UOC) y PMP del Project Management Institut. Es consultor de estrategias tecnológicas de negocio y de metodologías de dirección de proyectos. Ha trabajado como director de SI y director de proyectos en diversas organizaciones, públicas y privadas, tanto grandes como pequeñas, ha sido consultor y formador de metodologías de dirección de proyectos, externalización y calidad en los últimos años, así como colaborador externo desde el año 2001 en la UOC, en las asignaturas de GOPI y MGPI de las ingenierías de Informática, así como de Gestión de proyectos en el máster TIC, y en la UAB.

  • 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_00215828
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

El PMBOK describe la tarea de la gestión (o dirección) de proyectos como la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto con el fin de satisfacer los requisitos del mismo, o sea, alcanzar el éxito del proyecto.
Gestionar un proyecto con éxito quiere decir, pues, dos cosas:
1) Asegurar que los proyectos se completan satisfactoriamente y se alcanzan sus resultados últimos, que no son otros que los beneficios (el valor) que el cliente quiere obtener para su negocio.
2) Hacerlo de manera que se pueda prever y controlar su evolución, involucrar adecuadamente a los interesados o participantes en el proyecto y explicarlo de manera satisfactoria al cliente y al equipo de trabajo.
En definitiva, gestionar el proyecto es hacer lo que se tiene que hacer, pero no sólo eso, sino también comunicarlo adecuadamente.
Para el estudiante y el profesional de las TIC es crucial entender que la gestión de proyectos es, en parte, una disciplina separada y superpuesta al ciclo de producción o despliegue de un producto de telecomunicaciones, informática o multimedia, que tendrá sus metodologías de producción específicas, de la misma manera que, cuando se hace un puente en ingeniería de puentes, no sólo se tiene que saber hacer puentes y ajustar las metodologías, técnicas y herramientas de hacer puentes, sino también saber gestionar un proyecto, que es hacer un puente para un cliente, con unos requisitos, unos estándares de calidad, unos plazos y unos costes determinados.
En el módulo "La gestión de proyectos. Conceptos básicos" hemos presentado de forma introductoria los conceptos fundamentales de este material y también su marco conceptual y metodológico, que se basará principalmente en el Project management body of knowledge (PMBOK), en su última edición (la cuarta, publicada el 31 de diciembre de 2008), y parcialmente, por lo que respecta a los aspectos de comunicación y gestión de los interesados, en el Goal directed project management (Andersen, y otros, 2006). Hemos insistido en que estas metodologías proporcionan una referencia o lenguaje común para la profesión de la gestión de proyectos y un conjunto de "buenas prácticas", pero el profesional experto tiene que reflexionar y adaptarlas a cada situación y proyecto concreto.
En este material, hemos establecido una metodología de gestión de proyectos inspirada principalmente en el PMBOK (el cuerpo de conocimiento en gestión de proyectos), que se ha convertido en un estándar de facto dentro de muchas industrias, con algunas adaptaciones propias inspiradas principalmente en la metodología GDPM (gestión de proyectos orientada a objetivos), en otras fuentes académicas y en la experiencia de los autores en gestión de proyectos TIC. No existe una extensión o adaptación estándar de PMBOK para las industrias TIC, aunque cada vez hay más practicantes que están certificados y muchos de los últimos manuales de gestión de proyectos de tecnologías de la información y de servicios de comunicaciones se inspiran, como estos materiales, en el PMBOK.
El PMBOK se estructura en cinco grupos básicos de procesos para la gestión de cualquier tipo de proyecto (que a menudo coinciden con las fases del ciclo de vida básico de muchos proyectos TIC), nueve áreas o ámbitos de conocimiento (temas o grupos de temas que es necesario articular dentro del proyecto), cuarenta y dos procesos específicos. Cada proceso se compone de unos inputs (documentos, planes, resultados de una fase anterior...), unas herramientas y técnicas (que se aplican para trabajar sobre dichos inputs) y unos outputs (productos resultantes). El resultado es un conjunto de documentos principales, que se podrían llamar básicos o imprescindibles, y muchos otros documentos o instrumentos complementarios.
En este módulo, introduciremos al alumno en el enfoque del PMBOK para la gestión de proyectos.

Objetivos

Después del estudio de este módulo, los estudiantes deberéis tener una visión lo bastante global y completa de los principales componentes y procesos de la gestión de proyectos, de acuerdo con estos referentes metodológicos, y más en concreto:

  1. Entender y ser capaces de desenvolveros con facilidad en lo que respecta a la estructura y los conceptos del método que proponemos para la gestión de proyectos TIC con el fin de poder aplicarlos, bajo la supervisión adecuada, en la vida académica y profesional.

  2. Entender las fases del ciclo de vida (o procesos de gestión, según la terminología del PMBOK) de cualquier proyecto, su objetivo, procesos y resultados.

  3. Entender las áreas o ámbitos de conocimiento que incluye la gestión del proyecto a lo largo de su ciclo de vida, en el conjunto y en cada una de las fases o procesos de gestión.

  4. Entender los procesos de gestión específicos de cada ámbito de conocimiento y su aplicación a lo largo del ciclo de vida.

  5. Entender cuáles de todos estos procesos son absolutamente básicos e imprescindibles para el éxito del proyecto y sus productos resultantes.

Este módulo actúa asimismo como una introducción a los diferentes módulos siguientes, en los que se estudiará con detalle cada fase del ciclo de vida de un proyecto y sus procesos de gestión.

1.Las áreas de conocimiento

Tal como hemos visto en el módulo "La gestión de proyectos. Conceptos básicos", el ciclo de gestión de un proyecto se compone de cinco etapas o grupos de procesos, como muestra la figura 1:
Figura 1. Ciclo de gestión de un proyecto TIC
Estas etapas son:
1) Iniciación, en la que se procede a la aprobación del proyecto por parte de los órganos de dirección de la empresa, se define inicialmente su alcance y se identifican los participantes.
2) Planificación, en la que se revisan en detalle los objetivos, alcance y productos a obtener, se establecen los hitos y paquetes de trabajo menores y se descomponen en actividades, a las cuales se asignan recursos, tiempo y costes. La planificación incluye también los planes de calidad, recursos humanos y técnicos, comunicación, gestión de los riesgos y administración económica del proyecto.
3) Ejecución, que representa la gestión del día a día del proyecto desde su lanzamiento hasta el cierre, y en la que se 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 económica.
4) Seguimiento y control, que en realidad es una etapa iterativa y permanente, en la que se revisan todos los planes de acuerdo con la realidad actual del proyecto y se hacen los ajustes o se toman las decisiones que procedan. En especial, en esta fase se tienen que vigilar los cambios en el alcance del proyecto y la evolución de los riesgos.
5) Cierre, en la que, si todo ha ido bien y el proyecto ha acabado satisfactoriamente, se hace la entrega de los productos y el cierre contractual y se realiza una primera evaluación.
El proceso de gestión de proyecto se basa en los principios de gestión de la calidad de Deming, que han sido asumidos por la Asociación Americana para la calidad y otras asociaciones internacionales. Se trata de un ciclo continuo de implantación de los planes establecidos, su revisión y la toma de decisiones correctoras que se incorporan de nuevo al plan. Este ciclo (llamado PDCA) se muestra en la figura 2.
Figura 2. El ciclo de gestión de la calidad de Deming
Dos de los aciertos, entre otros, del enfoque del PMBOK son, en primer lugar, el reconocimiento de que el ciclo de gestión de proyecto es un proceso permanente e iterativo que se repite a lo largo de todo el ciclo de producción y en cada una de las fases; y, en segundo lugar, que la gestión del proyecto incluye un conjunto de procesos, habilidades, herramientas y productos muy diferentes que se utilizan a lo largo de estas etapas.
La pregunta, pues, es: ¿qué hay que gestionar para asegurar el éxito del proyecto? ¿Cuáles son las áreas o los ámbitos de conocimiento que el gestor de proyecto necesita conocer y articular? ¿Cuáles son los componentes de la gestión de proyectos como disciplina separada de conocimiento y de práctica?
Tal como hemos visto en el módulo "La gestión de proyectos. Conceptos básicos", la gestión de proyectos es hoy en día una disciplina muy compleja, que precisa de habilidades y competencias propias de su disciplina (un cuerpo de conocimiento adquirido a partir de la práctica de la profesión), habilidades del área técnica, funcional o sectorial en la que se esté trabajando, conocimientos y experiencia de la gestión de empresas (y organizaciones públicas), habilidades de relación y comunicación, etc.
Dentro de la disciplina propia de la gestión de proyectos, el PMBOK recomienda nueve áreas de conocimiento o aspectos clave de todo proyecto, que el director del proyecto debe tener en cuenta y ha de analizar para adecuarlos a las necesidades del proyecto.
Eso no quiere decir en absoluto que se tengan que utilizar siempre todos los procesos que describiremos a continuación; dependiendo de la organización, su cultura y madurez, del tipo de proyecto (grande, pequeño, innovador, conocido...) harán falta más o menos procesos, y al mismo tiempo, se necesitarán con grados de intensidad diversa. Es, pues, una decisión estratégica para la gestión del proyecto, que se ha de madurar mediante la utilización de criterios objetivos como los que mencionábamos: dimensiones, topología, cliente y otros.
Cómo ya se ha visto en el módulo "La gestión de proyectos. Conceptos básicos", estas áreas son el resultado del trabajo de los colaboradores del PMBOK, expertos y activos directores de proyectos que han llegado a un nivel de consenso sobre lo que se consideran "buenas prácticas" dentro de la profesión. Su contenido ha ido cambiando, como no podía ser de otra manera, a lo largo del tiempo, y la última edición introduce cambios y adiciones, algunas significativas, sobre las ediciones anteriores.
Estos nueve temas o áreas de conocimiento son actualmente los siguientes (tabla 1):
Fuente: PMBOK (2008)
Tabla 1
Las áreas de conocimiento en la gestión de proyectos
1) Gestión de la integración (las tareas directivas y de coordinación del director de proyecto)
2) Gestión del acance
3) Gestión del tiempo
4) Gestión de los costes
5) Gestión de la calidad
6) Gestión de los recursos humanos
7) Gestión de la comunicación
8) Gestión de los riesgos
9) Administración de compras y contratos
A continuación, proporcionamos una definición inicial de cada una de estas áreas, que se complementará en los apartados siguientes con una presentación más extensa:
1) La gestión de la integración del proyecto incluye los procesos y las actividades que son necesarios para identificar, definir, combinar, unificar y coordinar los diferentes procesos y actividades de la dirección de proyectos. Podríamos decir que es lo que hace por excelencia el director o jefe de proyecto, tareas que normalmente no se delegan en otros miembros del equipo. Por lo tanto, son los procesos de toma de decisiones, asignación de recursos, representación ante el cliente o los subcontratistas y la responsabilidad de los documentos o productos que son el resultado final de cada fase del ciclo de gestión.
2) La gestión del alcance es probablemente el aspecto más crítico para la gestión de cualquier proyecto. Incluye todos los procesos y actividades necesarios para asegurar que el proyecto producirá todo lo que es necesario para alcanzar sus objetivos o, dicho de otra manera, lo que se tiene que hacer y lo que no se tiene que hacer. En proyectos TIC, las causas más importantes de desviaciones de tiempo y costes obedecen a un deslizamiento de alcance (scope creep) por razones de negocio (el cliente pide hacer más cosas de las previstas) o de tecnología o prestaciones (el proveedor sugiere incluir prestaciones que mejorarían el producto). La definición del alcance al principio del proyecto y el control de cambios a lo largo del proyecto son los procesos más importantes para garantizar o limitar que eso suceda o, cuando menos, para comunicar y negociar sus consecuencias.
3) La gestión del tiempo del proyecto incluye los procesos necesarios para asegurar que el proyecto en su conjunto y los hitos parciales acordados con el cliente se alcanzan de acuerdo con las restricciones temporales establecidas dentro del plan. La gestión del tiempo tiene dos dimensiones diferentes: la gestión de la duración de las tareas o grupos de tareas que se tienen que ejecutar (análisis del rendimiento o rentabilidad del proyecto y de los recursos asignados) y el control del cronograma o calendario del proyecto y de sus fases (análisis del cumplimiento de hitos). La primera es una dimensión interna y de eficiencia del equipo de trabajo o la empresa contratista; la segunda es una dimensión contractual ante un tercero, el cliente.
4) La gestión de los costes incluye todos los procesos relacionados con la estimación, preparación y control del presupuesto del proyecto, la información sobre el progreso económico, proyecciones y previsiones a lo largo del trabajo, ajustes en la cantidad o calidad de los recursos y el análisis del rendimiento o rentabilidad económica del proyecto. Tiene también las dos dimensiones (interna y externa) de la gestión del tiempo.
5) La gestión de la calidad comprende todos los procesos y actividades que determinan las políticas, objetivos y responsabilidades relacionados con la calidad, entendida ésta principalmente en dos sentidos: conformidad con unas normas y estándares (por ejemplo, la norma ISO/IEC 9126, de calidad del software) y satisfacción del cliente. Actualmente, la gestión de la calidad incluye también los procesos de mejora continua, la responsabilidad de la dirección por la asignación de recursos y otros.
6) La gestión de recursos humanos tendrá que incluir los aspectos de organización y asignación de responsabilidades para los hitos, actividades y tareas, como mínimo, así como, más allá de eso, todos los procesos y actividades para la incorporación, coaching, desarrollo, evaluación y progreso del capital humano asignado al proyecto.
7) La gestión de la comunicación del proyecto es el área de conocimiento que incluye los procesos de generación, recogida, distribución, almacenamiento, recuperación y disposición final de la información del proyecto por las diferentes partes interesadas. Hemos dicho en un apartado anterior, y podría parecer exagerado, que gestionar bien un proyecto no es sólo hacer lo que se tiene que hacer para alcanzar los objetivos sino también saber explicarlo para articular y satisfacer las expectativas del cliente. La última versión del PMBOK incorpora los procesos de gestión de expectativas dentro de esta área de conocimiento.
8) La gestión de los riesgos incluye los procesos necesarios para identificar aquellos acontecimientos potenciales que pueden tener un impacto sobre el proyecto, anticipar su aparición, prever las consecuencias, planificar las respuestas, acciones correctoras y contingencias y tomar las decisiones adecuadas en el momento en que se produzca el riesgo. El riesgo y la incertidumbre son elementos naturales en la gestión de los proyectos TIC, y los hay de todo tipo. Lo que se ha de tener son políticas, procedimientos y métricas que ayuden a tratarlos adecuadamente y personas con la experiencia, sangre fría y determinación para hacer lo que procede hacer.
9) La administración y gestión de compras y contratos del proyecto incluye toda la administración (compras, contratos, facturación, cobros) del proyecto, tanto en nuestra relación con el cliente como en la que tenemos con los subcontratistas. En el ámbito TIC, con el aumento del volumen y la complejidad de los proyectos, esta área no se reduce sólo a un trabajo auxiliar o administrativo, sino que constituye un aspecto cada vez más crítico con consecuencias económicas y legales muy importantes y de alto riesgo.
76527_m2_03.gif
Algunas carencias del PMBOK y otras metodologías
Desde el punto de vista de la gestión de proyectos TIC, y reconociendo los progresos de la última edición, en nuestra opinión, hay algunos elementos susceptibles de mejora y adaptación, como por ejemplo:

  • El cambio que se ha producido en esta versión, al suprimir la definición inicial del alcance de los procesos de iniciación, es contrario a la práctica de los compradores y vendedores de servicios, en la que este proceso se iterativo y de refinamiento progresivo entre la iniciación y la planificación y muchas veces forma parte de las negociaciones de los propios contratos.

  • El hecho de separar la identificación de las partes interesadas (en la fase de iniciación) y la adopción de requisitos (en la fase de planificación) parece también artificial.

  • La visión de la calidad (calidad en la gestión del proyecto) parece reduccionista. En los proyectos TIC no se puede separar racionalmente la calidad del proyecto y la calidad del producto.

  • La obsesión por separar gestión de proyecto y gestión de producto en los proyectos TIC es a menudo artificial, y las empresas de servicios y una parte de la literatura científica la están llevando a un nivel de integración metodológica y práctica, como mínimo para ciertos productos, como el desarrollo estructurado de sistemas de información.

  • En proyectos TIC intensivos en la gestión o provisión de infraestructuras, se echa de menos un área específica de gestión de recursos técnicos.

  • En nuestra opinión, todos los aspectos de organización, dirección y gobierno del proyecto, a los que el PMBOK da cada vez más importancia y que son absolutamente críticos, tendrían que estar mejor integrados dentro de la metodología, posiblemente como un área de conocimiento específica.

  • A pesar del avance en los aspectos de comunicación, que van cobrando un mayor protagonismo en cada edición, lo que en realidad cuenta en muchos proyectos TIC (la causa última del éxito y el fracaso de muchos proyectos) es la gestión global del cambio que se ha de producir en el cliente (cambios en sus estructuras de organización, en sus procesos de negocio, en la cantidad y calidad de sus recursos humanos y en las estructuras de retribución y de las carreras, en las actitudes de las personas...). Nada de eso está suficientemente reconocido dentro del PMBOK y requiere un planteamiento más global y ambicioso.

  • Un problema habitual del personal técnico de las profesiones TIC que asume responsabilidades dentro de la dirección de proyectos es la carencia de habilidades y el desconocimiento de los procesos de gestión y de las técnicas y herramientas de la gestión económica y legal del proyecto globalmente, no sólo de la gestión de los proveedores y subcontratistas. En este contexto, la visión del área de gestión de compras (acquisitions management) que proporciona el PMBOK parece exagerada o reduccionista.

En realidad, la raíz última de estos problemas está en el origen de la aproximación del PMBOK, tal como la enfocaron o interpretaron sus fundadores, y se basa en diversas suposiciones que pueden ser parcialmente erróneas:
a) La separación entre lo que pasa "dentro del proyecto" (lo que nos pasa a nosotros) y lo que pasa "fuera del proyecto" (lo que le pasa al cliente o a los subcontratistas), antes del proyecto, durante el proyecto o después del proyecto.
b) La separación entre el producto (un resultado real que tiene que producir mejoras en el cliente, hacerle ganar dinero o resolverle problemas) y el proyecto (una entelequia metodológica muchas veces difícil de entender).
c) La separación entre lo que tenemos que hacer nosotros (el proyecto que tenemos contratado) y lo que suponemos que hará el cliente (y que a menudo no hace) para que el proyecto tenga éxito.
Estos problemas, muy prácticos y que frecuentemente determinan el éxito o el fracaso de un proyecto TIC, no están resueltos del todo en el PMBOK ni en otras metodologías. Como dice un dicho anónimo, "el que escribió la metodología no pensaba en el cliente".
Por nuestra parte, hemos intentado, sin complicaros las cosas a los estudiantes, complementar algunas de estas carencias con aproximaciones y consejos procedentes de nuestra práctica, la de algunas empresas de servicios y la de otras metodologías (como, por ejemplo, GDPM en los aspectos de organización, comunicación y gestión del cambio).

2.Relaciones entre los procesos de gestión del ciclo de vida y las áreas de conocimiento, según el PMBOK

Una solución brillante de los autores y consultores del PMBOK ha sido relacionar los procesos de gestión del ciclo de vida (las cinco etapas de iniciación, planificación, ejecución, seguimiento y control, y cierre) con las nueve áreas de conocimiento experto y mapear dentro de una matriz de doble entrada todos los procesos de gestión específicos que se pueden desplegar dentro de un proyecto.
La tabla siguiente muestra este mapeo. Cada actividad o proceso específico se muestra dentro del grupo de procesos en que habitualmente se desarrollan la mayoría de las actividades.
Fuente: PMBOK (2008)
Tabla 2. Correspondencia entre grupos de procesos y áreas de conocimiento, según el PMBOK
Áreas de conocimiento
Grupos de procesos de gestión de proyectos
Procesos de iniciación
Procesos de planificación
Procesos de ejecución
Procesos de seguimiento y control
Procesos de cierre
Gestión de la integración del proyecto
1) Desarrollar el acta de constitución
 
 
 
2) Cerrar proyecto o fase
Gestión del alcance del proyecto
 
1) Recopilar requisitos
2) Definir el alcance
3) Crear la EDT
 
4) Verificar el alcance
5) Realizar el control del alcance
 
Gestión del tiempo del proyecto
 
1) Definir actividades
2) Secuenciar actividades
3) Calcular los recursos de las actividades
4) Calcular la duración de las actividades
5) Desarrollar el cronograma
 
6) Realizar el control del cronograma
 
Gestión del coste del proyecto
 
1) Calcular costes
2) Determinar el presupuesto
 
3) Realizar el control del presupuesto
 
Gestión de la calidad
 
1) Planificar la calidad
2) Realizar el aseguramiento de la calidad
3) Realizar el control de calidad
 
Gestión de los RR. HH.
 
1) Desarrollar el plan de RR. HH.
2) Incorporar el equipo de proyecto
3) Desarrollar el equipo de proyecto
4) Dirigir el equipo de proyecto
 
 
Gestión de las comunicaciones
1) Identificar interesados
2) Planificar las comunicaciones
3) Distribuir la información
4) Gestionar las expectativas de los interesados
5) Informar del rendimiento
 
Gestión de los riesgos
 
1) Planificar la gestión de riesgos
2) Identificar los riesgos
3) Realizar el análisis cualitativo de riesgos
4) Realizar el análisis cuantitativo de riesgos
5) Planificar la respuesta a riesgos
 
6) Hacer seguimiento y controlar los riesgos
 
Gestión de compras y contratos
 
1) Planificar las compras y contratos
2) Realizar compras y contratos
3) Administrar compras y contratos
4) Cerrar compras y contratos
Nota
Tenemos que tener presente que a lo largo de estos materiales hemos introducido modificaciones sobre este esquema básico con el fin de adaptarlo a la dinámica de los proyectos TIC, según la bibliografía académica y nuestra experiencia práctica.

3.Descripción de las áreas de conocimiento

En este apartado proporcionamos una breve descripción de las diferentes áreas de conocimiento y de sus componentes, procesos y resultados, teniendo en cuenta que en los módulos siguientes se examinarán, para cada fase del ciclo de vida, el desarrollo específico de cada una de ellas a lo largo del proyecto.
Nos ha parecido que los aspectos de organización del proyecto (papeles y responsabilidades), habilidades directivas y todos los componentes de gestión de personas, por su importancia, tiene sentido tratarlos separadamente en el módulo que llamaremos "El lado humano de la gestión de proyectos".

3.1.Gestión de la integración del proyecto

El área de conocimiento de gestión de la integración incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diferentes procesos y actividades de la dirección de proyectos. Son unos procesos que podríamos calificar como los más propios del director del proyecto, pues básicamente son tareas de coordinación que, en la inmensa mayoría de los casos, no se delegan en otros miembros del equipo.
Esta integración quiere decir tomar decisiones con respecto a la asignación de recursos, a la concreción de los objetivos, equilibrando su peso; sobre qué procesos de gestión serán necesarias; coordinar la interdependencia entre las diferentes dimensiones del proyecto. Por ejemplo, si en la asignación de recursos a una tarea se detecta que hace falta un proceso previo de formación, habrá que adecuar el cronograma y quizá el presupuesto, y ver cuál será el impacto de dicha falta de formación en la calidad del entregable. Igualmente, dicha integración está relacionada con la documentación y gestión del proyecto, para asegurar la coherencia de todo, y también con la relación del proyecto con la operativa cotidiana del cliente.
A pesar de que a lo largo de los materiales presentaremos los procesos de gestión como nítidamente diferenciados con interfaces claras, en la realidad los procesos se superponen e interactúan entre sí de diversas formas (que no podemos detenernos en detallar aquí); esta complejidad forma parte de las tareas que tiene que llevar a cabo el director del proyecto.
Los procesos que forman parte de la gestión de la integración se muestran en la figura siguiente:
Figura 3. Descripción general de la gestión de la integración del proyecto
Fuente: PMBOK (2008)
El equipo de dirección del proyecto realizará numerosas actividades, pero de forma especial se responsabilizará de:

  • Analizar y comprender el problema que tiene que resolver el proyecto y diseñar una solución adecuada, de acuerdo con los objetivos y el alcance acordados con el cliente. Tendrá que tener en cuenta, a la hora de considerar la mejor opción, las restricciones e hipótesis del proyecto, así como otras influencias relativas a la cultura, organización, tecnología, etc., del cliente y de la organización ejecutante del proyecto.

  • Identificar las informaciones relevantes de cara a transformarlo en unos planes de proyecto que aseguren el éxito.

  • Realizar las actividades que producen el alcance del proyecto.

  • Medir y controlar los rendimientos del proyecto para asegurar el cumplimiento del plan y ejecutar las acciones necesarias para ajustar el plan a las necesidades cambiantes del cliente.

No hay una única forma de dirigir un proyecto; diferentes directores de proyecto, en función de su experiencia, cultura y conocimientos, podrán aplicar unos procesos u otros, y con diferentes niveles de intensidad. Lo que sí reconocen la mayoría de los expertos es que hace falta considerar y analizar todos los procesos que comentaremos para ver si hace falta o no implementarlos en el proyecto en curso y, al mismo tiempo, con qué niveles de detalle. Es responsabilidad del director de proyecto y su equipo, y forma parte de esta área de conocimiento, el determinarlos y documentar las decisiones que se tomen con respecto a los procesos seleccionados y los niveles de detalle necesarios.
Los productos principales de esta área son:

  • El acta de constitución del proyecto.

  • El organigrama de gestión del proyecto.

  • El plan integrado de gestión de proyecto.

  • El documento de kick-off o lanzamiento del proyecto.

  • El informe de open issues o incidencias.

  • Los informes de peticiones de cambios.

  • El registro de cambios.

  • El informe de seguimiento y control de cambios.

  • Los informes parciales y finales de cierre.

  • Las actas de aceptación.

  • Las convocatorias y agendas de reunión.

  • Las actas de reunión.

3.2.La gestión del alcance

La gestión del alcance incluye los procesos necesarios para asegurar que el proyecto producirá todo lo que sea necesario para alcanzar el éxito del proyecto, pero sólo lo necesario, o, dicho de otra forma, identificar y producir lo que tiene que estar incluido en el proyecto y lo que no.
En primer lugar, hay que entender claramente qué se entiende por alcance, y hay que entenderlo como la suma de productos, servicios y resultados que se entregarán en un proyecto. Por lo tanto, el alcance no es sólo aquello relacionado con elementos técnicos del proyecto (p. ej., la aplicación web) y con la documentación, también forma parte del alcance cualquier otro elemento de producción o de gestión que haga falta "entregar" para completar el proyecto, como la formación, las pruebas, los estudios técnicos, el plan de proyecto (o una parte del mismo), los informes de seguimiento y otros.
Como hemos dicho, es conveniente diferenciar entre alcance del proyecto y alcance del producto. El primero se asocia al trabajo que hay que efectuar para entregar el producto, servicio o resultado con las funciones y características especificadas en el objetivo del producto. El segundo alcance se centra en las características y funciones que definen un producto, servicio o resultado. La gestión del alcance que veremos aquí se centra en el alcance del proyecto, mientras que las metodologías de producción (p. ej., UML), se centran en el alcance del producto. El alcance del proyecto tiene que quedar suficientemente definido al inicio del proyecto, mientras que el alcance del producto requerirá sucesivos trabajos y refinamientos hasta quedar totalmente definido, siempre antes, obviamente, de los procesos que tengan que producir cada uno de ellos.
El alcance, cono el resto de las dimensiones principales del proyecto (costes, tiempo y calidad), requiere que se concrete en cada momento de forma suficientemente clara y explícita; esta concreción se denomina "línea base del alcance". Hablamos de la línea base del alcance del proyecto como el conjunto de elementos que definen en un momento dado el compromiso hacia el alcance, lo que el proyecto tiene que producir; esta línea base está formada por tres componentes:
1)Enunciado del alcance, detallado y aprobado.
2)EDT (estructura de descomposición del trabajo).
3)Diccionario de la EDT.
El proyecto (o una fase del mismo) se podrá considerar finalizado cuando se haya completado la línea base del alcance, eso querrá decir, en general, una vez producidos, validados, entregados y aceptados todos los entregables del proyecto (o fase), y alcanzados los objetivos definidos en el enunciado del alcance.
Los procesos que forman parte de la gestión del alcance son los siguientes:
Figura 4. Descripción general de la gestión del alcance del proyecto
Fuente: PMBOK (2008)
La correcta definición del alcance constituye el proceso de planificación más importante, ya que todas las demás áreas (costes, riesgos, etc.) dependen de él e interactúan y cambian según esta definición del alcance. Igualmente hay que planificar correctamente el alcance, en previsión de posibles cambios en un futuro, para proteger el proyecto de excesivas modificaciones sobre las previsiones acordadas.
Los productos o documentos principales que soportan la gestión del alcance son los siguientes:

  • La definición (inicial y/o detallada) del alcance.

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

  • El informe de progreso del trabajo comparado con la distribución de EDT e hitos.

3.3.La gestión del tiempo

La gestión del tiempo incluye los procesos necesarios para asegurar que el proyecto se desarrollará de acuerdo con las restricciones temporales e hitos acordados con el cliente. La gestión temporal del proyecto es una de las gestiones que más vinculaciones tiene con el resto de áreas de conocimiento, motivo por el cual hace falta, a menudo, revisar y ajustar el plan temporal debido a decisiones en otras áreas; en este sentido, y tal como ya hemos comentado, los procesos que se presentan suelen repetirse varias veces hasta que se obtiene una propuesta temporal coherente con el resto de las áreas, a la vez que adecuada a las necesidades del proyecto.
En proyectos pequeños es normal que los procesos de planificación temporal no se desarrollen de forma tan marcadamente secuencial, sino que se solapen e interactúen parcialmente entre sí, avanzando de forma paralela para obtener los resultados finales.
Aparte del resultado más relevante de estos procesos, el cronograma o calendario del proyecto convertido en "línea base temporal" o "línea base del cronograma del proyecto", una vez finalizado y aprobado, hace falta tenerlo presente y documentar lo que se denomina el modelo del cronograma o calendario, que incluye los datos que se han utilizado (p. ej., con respecto a las estimaciones temporales), así como los criterios o métodos utilizados (p.ej., la cadena crítica). Para poder entender correctamente un cronograma resulta imprescindible conocer el modelo, y es recomendable que quede perfectamente documentado, si exceptuamos los casos en que tanto una cosa como otra formen parte de políticas estandarizadas de la organización que se han aplicado en el proyecto en curso.
Los procesos que forman parte de la gestión del tiempo son los siguientes:
Figura 5. Descripción general de la gestión del tiempo del proyecto
Fuente: PMBOK (2008)
Los productos o documentos que consideramos principales dentro de esta área son los siguientes:

  • El calendario de proyecto.

  • El informe de progreso del trabajo comparado con el calendario.

3.4.La gestión de costes

La gestión de los costes del proyecto incluye los procesos relacionados con la estimación, preparación y control del presupuesto del proyecto, a fin de que éste finalice dentro del presupuesto aprobado.
Como el resto de los procesos de planificación, los de costes, interactúan entre sí de forma que a menudo hace falta revisar y ajustar el presupuesto debido a decisiones adoptadas en otras áreas; en este sentido, y tal como ya hemos comentado, los procesos que se presentan suelen repetirse varias veces hasta que se obtiene una propuesta económica coherente con el resto de áreas, a la vez que adecuada a las necesidades del proyecto.
En proyectos pequeños es normal que los dos procesos de planificación de los costes no se desarrollen de forma tan marcadamente secuencial, sino que se solapen e interactúen parcialmente entre sí, avanzando de forma paralela para obtener los resultados finales.
Incluye los siguientes procesos:
Figura 6. Descripción general de la gestión del coste del proyecto
Fuente: PMBOK (2008)
Por otra parte, cuando se toman decisiones sobre los costes del proyecto hay que tener en cuenta los futuros costes operativos del producto. Algunas decisiones pueden tener consecuencias en los costes recurrentes subsiguientes del producto obtenido y hace falta que todo quede convenientemente documentado y acordado. Es el caso habitual del esfuerzo en las pruebas de un producto de software, a más esfuerzo de pruebas menos incidencias en el producto una vez en explotación. De forma similar hay que considerar los niveles de calidad exigibles en cada una de las tareas como un factor de coste a evaluar.
Los principales productos de esta área de procesos son:

  • El presupuesto de proyecto.

  • El informe de progreso del trabajo con respecto al presupuesto aprobado.

3.5.La gestión de la calidad

Los procesos de gestión de calidad del proyecto incluyen todas las actividades que determinan las políticas, los objetivos y las responsabilidades relativas a la calidad, para conseguir que el proyecto cumpla los objetivos fijados. La calidad tiene dos dimensiones. Una es la que podemos llamar "objetiva" o de conformidad con unos requisitos o estándares. En este sentido, la calidad es "el grado en que un conjunto de características inherentes cumple los requisitos". La otra es la dimensión subjetiva, relativa a la satisfacción del cliente o la conformidad con sus expectativas.
La calidad se refiere tanto al producto (resultados) como al proyecto (cómo se gestiona). En general, la calidad del producto es diferente y requiere técnicas diferentes según el sector de actividad, mientras que la calidad de la gestión es común a la mayoría de los sectores. Para una buena gestión de la calidad, es necesario que las necesidades establecidas o implícitas se transformen en requisitos explícitos mediante los procesos de "recopilar requisitos"; una mala definición de la calidad esperada comporta quejas, malentendidos y, finalmente, insatisfacción. Del mismo modo, un proceso de producción que elabore productos de baja calidad, o sea, que incumpla en alguna medida los requisitos, genera frustración, desmotivación, retrabajo y quejas de los clientes y también del propio equipo de trabajo. En el entorno de las TIC, por desgracia, no hay muchas normativas de calidad, y las que hay a menudo no son suficientemente conocidas, lo cual justifica todavía más lo que hemos comentado en el párrafo anterior.
Finalmente, se tiene que tener presente la necesidad de encontrar un balance razonable entre los procesos de calidad y las dimensiones de tiempo y costes.
Incluye los siguientes procesos:
Figura 7. Descripción general de la gestión de la calidad del proyecto
Fuente: PMBOK (2008)
Los documentos importantes de esta área son:

  • El plan de calidad.

  • Los informes de progreso del plan de calidad.

3.6.La gestión de los recursos humanos

La gestión de los recursos humanos del proyecto es una de las áreas de conocimiento en la que se da una cierta paradoja, en el sentido de que todo el mundo está de acuerdo en su importancia y en la necesidad de esforzarse en gestionar bien las personas, sin que, en cambio, sea habitual encontrar políticas, criterios, normas y todo lo que comportaría un plan de gestión de los RR. HH. Aun así, la gestión de las personas se convierte en una de las tareas que más tiempo ocupa al director del proyecto y en una de las más claramente cruciales tanto para el éxito del proyecto como para la carrera profesional de los miembros del equipo.
Los procesos de la gestión de recursos humanos están orientados a organizar, gestionar y dirigir al equipo.
El equipo de proyecto lo componen las personas a las que se ha asignado un rol y responsabilidades para finalizar el proyecto. La composición del mismo puede ser distinta en los diferentes momentos del proyecto, habida cuenta de los variados tipos de actividades que se tienen que desarrollar en cada momento. Al mismo tiempo, es importante destacar que, siempre que sea posible, puede ayudar en las tareas de planificación y, además, aumenta el grado de compromiso si los recursos se incorporan lo más pronto posible. El director del proyecto tiene que influir sobre las personas del proyecto para asegurar el mejor rendimiento y aportación al proyecto; temas como el ambiente de trabajo, la ubicación física de los trabajadores, la comunicación, las normas de trabajo, los roles y muchos otros "factores humanos" pueden afectar al rendimiento. Por otra parte, también tiene que asegurar el comportamiento profesional y ético del equipo de trabajo.
Las decisiones sobre los recursos humanos del proyecto tienen también importantes impactos en otras áreas y, como éstas, se relacionan e interactúan con procesos de costes, temporales, de riesgos y otros.
Por la importancia que le damos a esta gestión, encontraréis en el módulo "El lado humano de la gestión de proyectos" toda una serie de propuestas, buenas prácticas, técnicas e ideas para afrontar este reto de gestión. También trataremos allí todos los aspectos relacionados con las estructuras de gestión y gobierno del proyecto y los roles y responsabilidades dentro del equipo y en el cliente.
Los procesos que identifica el PMBOK dentro de esta área de conocimiento son los siguientes:
Figura 8. Descripción general de la gestión de los RR. HH.
Fuente: PMBOK (2008)
Los productos que consideramos importantes en esta área son:

  • El plan de gestión de recursos humanos

  • Los informes de progreso de gestión de recursos humanos

3.7.La gestión de la comunicación

La gestión de la comunicación del proyecto es el área de conocimiento que incluye los procesos necesarios para asegurar la generación, recogida, distribución, almacenamiento, recuperación y disposición final de la información del proyecto de forma adecuada y oportuna.
Una parte importante del tiempo de los directores de proyectos se emplea en tareas de comunicación con el cliente, el patrocinador, los miembros de su equipo, los proveedores, el personal de la organización del cliente, y un largo etcétera. Mejorar las comunicaciones reduce el tiempo y hace más eficaces estas tareas a la vez que facilita el funcionamiento general del proyecto. Al mismo tiempo, hay que tener muy presentes las características de las diversas dimensiones en que se pueden realizar los procesos de comunicación: formal o informal, oral o escrita, verbal y no verbal (paraverbal), interna o externa, oficial o no oficial, vertical u horizontal, a quién se envía, de qué forma, etc.; la comunicación es un proceso muy complejo que tiene que ser bien gestionado por el director de proyectos.
Las habilidades de comunicación son comunes a las de dirección general. El arte de las comunicaciones incluye una gran cantidad de conceptos y técnicas que se tratarán en el módulo "El lado humano de la gestión de proyectos" de este material.
El área de gestión de comunicación del proyecto, según el PMBOK, incluye los siguientes procesos:
Figura 9. Descripción general de la gestión de comunicación
Fuente: PMBOK (2008)
La comunicación no es un concepto evanescente dentro de la gestión de proyectos, y las diferentes metodologías, incluido el PMBOK, han ido dándole cada vez más peso con el paso de los años. Comunicar representa identificar los intereses y expectativas de los interesados con relación al proyecto, cuál es su valor esperado y percibido y cómo se tiene que gestionar la relación con ellos a lo largo del proyecto para asegurar su satisfacción que, como se ha dicho antes, es una parte intrínseca de la calidad del proyecto.
Según hemos señalado antes, la gestión de la comunicación es una parte de la gestión del cambio y del lado humano del proyecto al que dedicamos el módulo "El lado humano de la gstión de proyectos" de este material.
En la definición más restringida, los productos o documentos que consideramos básicos para la gestión de esta área de procesos son los siguientes:

  • El plan de comunicación.

  • Toda la estructura de informes de progreso durante la ejecución del proyecto.

3.8.La gestión de los riesgos

Un riesgo en un proyecto es un acontecimiento o condición incierta que, si se produce, tiene un efecto positivo o negativo, como mínimo, sobre un objetivo del proyecto, como tiempo, coste, alcance o calidad. Un riesgo puede tener una o más causas, y si se produce, ejercer uno o más impactos. Los acontecimientos positivos a menudo se llaman oportunidades. Los riesgos son problemas u oportunidades potenciales que pueden aparecer en el futuro del proyecto y tienen que ver con la incertidumbre de algunos elementos vinculados al proyecto, como pueden ser hipótesis, requisitos, disponibilidad de recursos, incumplimiento de acuerdos de terceros, tecnología disponible, etc.
Todos los proyectos están expuestos a sufrir uno o más riesgos y es necesario estar preparados. Los objetivos de la gestión de los riesgos del proyecto son aumentar la probabilidad y el impacto de los acontecimientos positivos, y disminuir la probabilidad y el impacto de los acontecimientos adversos para el proyecto.
Dado el carácter subjetivo que a menudo adopta la gestión de riesgos en muchos proyectos, es necesario añadir que la tolerancia al riesgo es distinta para organizaciones y personas diferentes; es recomendable que las organizaciones tengan normas, políticas, procedimientos y métricas que ayuden a los directores de proyectos en el tratamiento más adecuado de los riesgos y eviten en lo posible la subjetividad propia de cada persona. Hay que disponer de políticas proactivas frente a los riesgos. No identificar un riesgo potencial puede tener consecuencias catastróficas para el proyecto, pero identificar más riesgos de los necesarios puede aumentar los costes de gestión e incluso complicar las tareas de producción. Por este mismo motivo, la planificación de los riesgos pasa por tres etapas claramente diferenciadas: identificación, evaluación y aplicación de respuestas para combatirlos. En este proceso se considerará fundamentalmente el equilibrio entre los perjuicios/beneficios de los riesgos frente a los costes de las respuestas. Hay que considerar también los casos en que se asumen voluntariamente riesgos que pueden aportar beneficios potenciales al proyecto; esta decisión también formará parte de la gestión de riesgos; por ejemplo, se puede decidir hacer fast-traking, solapar dos fases o actividades, porque ello reducirá considerablemente el cronograma del proyecto.
El área de gestión de los riesgos del proyecto incluye, según el PMBOK, los siguientes procesos:
Figura 10. Descripción general de la administración de los riesgos del proyecto
Fuente: PMBOK (2008)
Ya lo hemos comentado en otras áreas, pero en el caso de los riesgos es mucho más relevante; estos procesos interactúan con los de otras áreas de forma que a menudo hace falta revisar y ajustar el presupuesto, los recursos, el cronograma y otros elementos debido a decisiones en la gestión de los riesgos. Igualmente, los procesos que se presentan aquí suelen repetirse varias veces hasta que se obtiene una propuesta de riesgos coherente con el resto de áreas y a la vez adecuada a las necesidades del proyecto.
Hablaremos de riesgos conocidos o desconocidos. Los primeros han sido identificados y analizados y se ha decidido planificar respuestas para hacerles frente, pero para los desconocidos no ha sido posible, y hará falta, cuando aparezcan, que el equipo del proyecto los aborde mediante respuestas de contingencia; en este sentido es habitual disponer de un margen de gestión que pueda permitir absorber dichos riesgos desconocidos (tanto económicos como temporales).
Los documentos o productos que consideramos básicos dentro de esta área de procesos son los siguientes:

  • El plan de gestión de riesgos.

  • Los informes de evolución de los riesgos de proyecto.

3.9.Administración de compras y contratos

La administración de compras y contratos del proyecto incluye todos los procesos y actividades que regulan las compras y los contratos, tanto entre el proveedor del proyecto y el cliente como entre el proveedor y los diferentes socios y contratistas de producto, servicios o resultados parciales fuera del equipo de proyecto.
La organización ejecutante puede ser la compradora o la vendedora; en cualquier caso, estos procesos incluirán la gestión del contrato y de los cambios necesarios para desarrollar y administrar el contrato o las órdenes de compra de miembros del equipo. Incluyendo la administración de cualquier tipo de relación contractual de terceros y de la propia organización ejecutante si ésta está vinculada al cliente por un contrato.
Esta área incluye, según el PMBOK, los siguientes procesos:
Figura 11. Descripción general de la administración de compras y contratos del proyecto
Fuente: PMBOK (2008)
En estos procesos aparecen los contratos, que son documentos legales que establecen acuerdos vinculantes entre un comprador y un vendedor. Dichos acuerdos pueden ser sencillos o altamente complejos en función de las características de los entregables que se suministrarán. En cualquier caso, de la misma forma que hemos hablado de la importancia de una completa y correcta definición del alcance para el éxito del proyecto, eso mismo es aplicable a los contratos con terceros, en los que la definición clara del alcance es una factor fundamental. Además, el contrato puede recoger otras limitaciones o restricciones, así como también hipótesis o supuestos.
Hará falta que el director del proyecto se asegure de que los contratos encajan perfectamente con las necesidades del proyecto, a la vez que cumplen las normas, políticas y recomendaciones de la organización; a menudo, una parte del proceso de adquisiciones la realizará un departamento o área especializada, aunque eso no reduce la responsabilidad del director de proyecto en lo referente a la exactitud de los contenidos del contrato. En estos casos puede quedar resuelta una parte importante del proceso que tenga que ver con el lenguaje legal y los términos contractuales, que pueden quedar fuera del conocimiento del equipo de proyecto, eso hace conveniente que, en estos casos, además de las validaciones o aprobaciones, como las de cualquier documento o propuesta del proyecto, haya una aprobación explícita de los expertos legales de la organización.
Como ocurre en otros procesos (en especial los de planificación), los de administración de compras y contratos interactúan entre sí de forma que a menudo hace falta revisarlos y ajustarlos debido a decisiones en otras áreas; en este sentido, y tal como ya hemos comentado, los procesos que se presentan suelen repetirse varias veces hasta que se obtiene una propuesta de adquisiciones coherente con el resto de áreas y a la vez adecuada a las necesidades del proyecto. Una correcta, cuidadosa y completa definición de la relación con terceros puede tener una gran importancia para reducir riesgos o para facilitar las estimaciones de tiempo y costes; en la medida en que así se haga, ello impactará positivamente en aquellas áreas.
Los documentos que consideramos básicos en esta área de procesos son:

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

  • Los informes de progreso durante la ejecución.

4.Productos y documentos principales para la gestión de proyectos

La base del método de gestión de proyectos es la de cualquier sistema, es decir:

  • El proceso o conjunto de actividades de transformación de unos inputs (entradas) en unos resultados (outputs) mediante la utilización de un conjunto de conocimientos, técnicas y herramientas.

  • Normalmente, cada resultado (output) es al mismo tiempo una entrada (input) para un proceso posterior, excepto cuando se trate de resultados finales del proyecto.

Este proceso de transformación se representa en un diagrama de flujo (figura 12.):
Figura 12. Diagrama de flujo básico de cualquier proceso dentro del método de gestión de proyectos (ejemplo)
Fuente: PMBOK (2008)
A diferencia de las metodologías estructuradas propias de las profesiones TIC (informática, telecomunicaciones, multimedia), en la metodología de gestión de proyectos no aspiramos a recogerlo todo y con el máximo detalle, sino sólo aquellos aspectos que sean relevantes para la gestión del proyecto. Tampoco se trata, como hemos dicho repetidamente, de utilizar sistemáticamente todos los procesos de gestión, herramientas y técnicas, sino de distinguir al principio cuáles serán realmente útiles y pertinentes para el trabajo que se tiene que hacer.

4.1.Procesos y documentos básicos

Dentro del conjunto de procesos específicos de gestión de un proyecto TIC (y de sus outputs o productos resultantes), hay un reducido grupo de procesos que se pueden considerar imprescindibles para el éxito del proyecto, sin los cuales consideramos, y considera la profesión, que el proyecto se expone a un elevado riesgo de fracaso. Los productos resultantes tienen que estar preparados o, al menos, supervisados, por el director de proyecto. Algunos de ellos son sólo básicos en proyectos de determinada dimensión y características, y los hemos llamado aquí "recomendados" o "recomendables". Estos procesos y productos, que se desarrollarán en los módulos siguientes son los siguientes:
1) En la etapa de iniciación:
a) Desarrollar el mandato del proyecto (también denominado acta de constitución del proyecto). El "mandato" representa la aprobación formal por la dirección de la empresa (o la persona en la que aquélla haya delegado, muy a menudo el director de organización y sistemas) del proyecto en cuestión. Tiene que explicar POR QUÉ se hace el proyecto, recogiendo de forma muy breve los antecedentes y el contexto, los objetivos que se quieren alcanzar o los problemas de negocio que se pretende resolver, los objetivos de alto nivel del proyecto para la empresa, el patrocinador o líder interno del trabajo y un presupuesto o duración aproximada. Consideramos que éste es un proceso básico.
b) Definir el alcance inicial del proyecto. El alcance está constituido por cualquier elemento de producción o de gestión que habrá que entregar para completar el proyecto; por lo tanto, normalmente se compone de un resultado de producción (p. ej., una aplicación web), unos resultados complementarios (formación, pruebas, garantías...) y unos resultados de gestión (planes, actas, informes...). El alcance determina el QUÉ del proyecto, lo que se hará y lo que no se hará. Se tiene que decir que, en este momento, no siempre tenemos todos los elementos para definir con el suficiente detalle y claridad el alcance definitivo, que elaboraremos en la etapa de planificación. Muy a menudo, esta definición inicial se incorpora directamente al mandato o acta de constitución, por lo que consideramos que éste es un proceso recomendable, pero no básico, que, obviamente, forma parte de los procesos de gestión del alcance.
c) Establecer el registro de interesados, es decir, las personas del cliente que tienen interés o influencia en el proyecto, cuantificarlos y calificarlos. Es un proceso del área de comunicación, recomendable en función del tipo y tamaño del proyecto.
d) Establecer el organigrama del proyecto, es decir, los órganos colegiados o individuales de gestión del proyecto y sus responsabilidades a un alto nivel. Es un proceso del área de integración y lo consideramos básico. Puede estar incluido dentro del acta de constitución.
2) En la etapa de planificación:
a) Definir el alcance detallado del proyecto, lo cual estaremos en condiciones de hacer una vez hayamos podido recoger los requisitos por parte de los interesados. Ahora sí que éste es un proceso que consideramos básico.
b) Establecer la estructura de distribución del trabajo. Dentro de la definición de alcance, muchos consideran básico, especialmente en proyectos grandes y muy grandes, descomponer los objetivos y el alcance del proyecto en paquetes o unidades más pequeñas, cuya planificación y seguimiento son más fáciles y que permiten visualizar el contenido del entregable por el cliente y por el equipo. Por ejemplo, un entregable "análisis funcional" puede tener dos paquetes de trabajo, un documento de análisis funcional y una maqueta. La culminación o cierre de estos paquetes (u otros elementos significativos en el curso del proyecto) lo llamaremos hito. Con la creación de las EDT, estableceremos el plan de hitos y las responsabilidades (dentro de nuestro equipo y del cliente) de la culminación de cada hito. El plan de hitos (milestones plan, según GDPM) establece la relación entre los diferentes objetivos o paquetes de trabajo y determina para cada uno cuándo se considera que se ha alcanzado y las condiciones de verificación de que se ha alcanzado y que permiten pasar al siguiente. Por ejemplo, un hito sería la disponibilidad del entorno a pruebas ("cuando el entorno a pruebas esté disponible"), que es lo que nos permite hacer las pruebas. Éste es un nivel también estratégico dentro de la planificación. Los documentos que se producen están dentro de los procesos de gestión del alcance y los consideramos básicos.
c) Definir el plan de gestión de proyecto. Éste es el documento que define cómo se ejecuta, revisa, controla y cierra el proyecto. Incluye también todas las actividades para definir, integrar y coordinar los planes "subsidiarios", tales como los de gestión del alcance, el tiempo, costes, riesgos, comunicaciones, recursos, etc. Es la "hoja de ruta" básica para controlar el proyecto a lo largo de la ejecución. Los profesionales expertos recomiendan hacer una reflexión seria al principio del proyecto sobre cuál será el enfoque de la propia gestión del plan, cuán detallado será, qué tipo de herramientas y técnicas y procesos se utilizarán. Es un documento estratégico y de aprobación formal, no un "corta y pega" de planes anteriores que sirvan para todo. El plan define el CÓMO se hará el proyecto. Dentro del plan de gestión, consideramos básicos los siguientes contenidos:

  • El calendario o cronograma (schedule), que se tiene que hacer y presentar en dos ámbitos, el de los hitos y paquetes de trabajo (EDT), que es el más útil para la dirección, y el de las actividades y tareas por EDT, que es el más útil para el equipo de trabajo. GDPM propone herramientas para integrar el plan de hitos, la matriz de roles y el cronograma en el mismo documento. Forma parte del proceso de gestión del tiempo y lo consideramos básico.

  • El presupuesto, que resume todo el ejercicio de descomposición del proyecto en actividades, ponerlas en secuencia, calcular los recursos humanos y técnicos adecuados para hacer el trabajo y costearlos según las políticas de la compañía. Forma parte de los procesos de gestión del coste y lo consideramos básico.

  • El plan de gestión de riesgos. Muchos o pocos, grandes o pequeños, consideramos que el plan de riesgos, que contiene unas previsiones y una reserva económica de contingencias, es un proceso y un producto básico.

  • Pueden ser recomendables el plan de calidad (especialmente, muy ligado al plan de calidad del producto) y los de recursos humanos, comunicación y administración de compras.

3) En la etapa de ejecución:
a) El informe de Kick-Off, que se hace en la reunión de lanzamiento del proyecto, es un documento que consideramos básico y forma parte de los procesos de integración.
b) El informe de "open issues", que incluye todo tipo de incidencias o temas que se tienen que resolver sobre la marcha en el día a día del proyecto o, si fuera el caso, trasladarlos, por su importancia, al órgano de gobierno del proyecto que corresponda. También lo consideramos básico y parte de los procesos de integración.
c) El documento de petición de cambios, sean funcionales o de otro tipo, dentro del proyecto. Es un documento básico y parte de los procesos de integración.
d) El registro de cambios, donde se recogen los cambios solicitados y su valoración inicial, resolución o decisión de elevarlos al nivel que los tiene que aprobar. Es básico, dentro de los procesos de integración.
e) Los informes de progreso, que surgen de los procesos de seguimiento y control, aunque pertenecen al proceso de gestión de comunicación. Son básicos.
4) En la etapa o grupo de procesos de seguimiento y control, los documentos más importantes son los informes de progreso que se elaboran comparando la evolución del proyecto con los planes establecidos. Salen de las siguientes fuentes:
a) El informe de control del alcance, que compara la situación de las EDT y los hitos con el plan. Lo consideramos básico, dentro de los procesos de alcance.
b) El informe de control del cronograma, que compara la evolución temporal. Lo consideramos básico, dentro de los procesos de gestión del tiempo.
c) El informe de control del presupuesto, que compara la evolución económica. Lo consideramos básico, dentro de los procesos de gestión de los costes.
d) El informe de control de los riesgos, que compara la evolución del plan inicial, los riesgos residuales y los nuevos añadidos. Lo consideramos básico, dentro de los procesos de gestión de riesgos.
e) El informe de control de cambios, que es preceptivo para la aprobación de los cambios que tengan una influencia significativa sobre el alcance de cada EDT, sus costes o tiempo de duración. Lo consideramos básico, dentro de los procesos de gestión de integración. Se trata de comparar el plan con los cambios (fortuitos o deliberados) que se hayan producido en el proyecto, valorar o proyectar sus consecuencias y pedir su aprobación, en su caso. De todos los cambios, los más importantes y de mayor impacto en el proyecto son los de alcance (qué se tiene que hacer), los originados por razones de negocio (demandas del cliente) o de producto (nuevas prestaciones que el proveedor considera interesante introducir o complejidad añadida por su construcción o integración). También se tienen que explicar y autorizar los deslizamientos en tiempo y dinero y decidir quién los asume.
5) En la etapa de cierre se producen dos documentos fundamentales, que son básicos, dentro de los procesos de integración:
a) El informe de cierre, que da cuenta de la finalización de todas las actividades y procesos en curso para completar formalmente el proyecto. Los productos entregados se tienen que comparar con el plan inicial y asegurar su validación y aceptación por el cliente, así como preparar la documentación y formación que asegure la transferencia de conocimiento al cliente.
b) Las actas de aceptación del producto, parciales y definitivas, por parte del cliente.
Aunque parezca mentira, dentro de nuestra experiencia hay dos tipos de documentos básicos y generalistas que no se hacen o no tienen la calidad, oportunidad y utilidad que tendrían que tener, pero que son fundamentales para la gestión de los proyectos, y por tanto los añadimos a los anteriores como básicos y dentro de los procesos de integración:

  • Las convocatorias y agendas de reuniones, ya sean las importantes o de dirección o de seguimiento, ya las de trabajo ordinario con usuarios o las del equipo, que tendrían que centrar el objetivo de la reunión (qué se quiere sacar de ella), los temas relevantes a tratar y a decidir, los participantes (y por qué están allí), la duración...

  • Las actas de reuniones, que tendrían que documentar especialmente los participantes, los puntos relevantes de discusión, las decisiones tomadas, y las acciones y los pasos siguientes.

En la tabla 3 se presenta un resumen de los productos o "entregables" principales correspondientes a los diferentes procesos de gestión.
Tabla 3. Procesos de gestión y documentos principales que se generan

5.Resumen

Tal como hemos visto en el módulo "La gestión de proyectos. Conceptos básicos", la gestión de proyectos es hoy en día una disciplina muy compleja, que precisa de habilidades y competencias propias de su disciplina (un cuerpo de conocimiento adquirido a partir de la práctica de la profesión), habilidades del área técnica, funcional o sectorial donde se esté trabajando, conocimientos y experiencia de la gestión de empresas (y organizaciones públicas), habilidades de relación y comunicación...
Dentro de la disciplina propia de la gestión de proyectos, el PMBOK recomienda nueve áreas de conocimiento o aspectos clave de todo proyecto que hace falta que el director del proyecto tenga en cuenta y analice para adecuarlos a las necesidades del proyecto. Eso no quiere decir en absoluto que siempre se tengan que utilizar todos los procesos que describiremos a continuación; dependiendo de la organización, su cultura y madurez, del tipo de proyecto (grande, pequeño, innovador, conocido...) harán falta más o menos procesos, y al mismo tiempo, pueden hacer falta con grados de intensidad diversos. Es, pues, una decisión estratégica para la gestión del proyecto, dependiendo de aspectos como el tamaño, la tipología, los procesos y costumbres del propio cliente, las exigencias de la empresa de servicios, etc.
Estas áreas son, actualmente (4.ª edición, 2008), las siguientes:

  • Gestión de la integración (las tareas más integradas y directivas del director de proyecto).

  • Gestión del alcance.

  • Gestión del tiempo.

  • Gestión de los costes.

  • Gestión de la calidad.

  • Gestión de los recursos humanos.

  • Gestión de la comunicación.

  • Gestión de los riesgos.

  • Administración de compras y contratos.

Para cada una de estas áreas o grupos de procesos, el PMBOK propone un sistema bastante integrado, en el que unas entradas (inputs) se transforman en unas salidas, productos, documentos o entregables (outputs) mediante el uso de un conjunto de técnicas y herramientas. Estos outputs son al mismo tiempo entradas de procesos posteriores.
La gestión de la integración del proyecto incluye los procesos y las actividades que son necesarios para identificar, definir, combinar, unificar y coordinar los diferentes procesos y actividades de la dirección de proyectos. Podríamos decir que es lo que hace por excelencia el director o jefe de proyecto, tareas que normalmente no se delegan en otros miembros del equipo. Por lo tanto, son los procesos de toma de decisiones, asignación de recursos, representación ante el cliente o los subcontratistas y la responsabilidad de los documentos o productos que son el resultado final de cada fase del ciclo de vida.
La gestión del alcance es probablemente el aspecto más crítico para la gestión de cualquier proyecto. Incluye todos los procesos y actividades necesarios para asegurar que el proyecto producirá todo lo que es necesario para alcanzar sus objetivos o, dicho de otro manera, lo que se tiene que hacer y lo que no se tiene que hacer. En proyectos TIC, las causas más importantes de desviaciones de tiempo y de costes obedecen a un deslizamiento de alcance (scope creep) por razones de negocio (el cliente pide hacer más cosas de las previstas) o de tecnología o prestaciones (el proveedor sugiere incluir prestaciones que mejorarían el producto). La definición del alcance al principio del proyecto y el control de cambios a lo largo del proyecto son los procesos más importantes para garantizar o limitar que eso ocurra o, cuando menos, para comunicar y negociar sus consecuencias.
La gestión del tiempo del proyecto incluye los procesos necesarios para asegurar que el proyecto en su conjunto y los hitos parciales acordados con el cliente se alcanzan de acuerdo con las restricciones temporales establecidas dentro del plan. La gestión del tiempo tiene dos dimensiones diferentes: la gestión de la duración de las tareas o grupos de tareas que se tienen que hacer (el análisis del rendimiento o rentabilidad del proyecto y de los recursos asignados) y el control del cronograma o calendario de proyecto y sus fases (el análisis de cumplimiento de hitos). La primera es una dimensión interna y de eficiencia del equipo de trabajo o la empresa contratista; la segunda es una dimensión contractual ante un tercero, el cliente.
La gestión de los costes incluye todos los procesos relacionados con la estimación, preparación y control del presupuesto del proyecto, la información sobre el progreso económico, proyecciones y previsiones a lo largo del trabajo, ajustes en la cantidad o calidad de los recursos y el análisis del rendimiento o rentabilidad económica del proyecto. Tiene también las dos dimensiones (interna y externa) de la gestión del tiempo.
La gestión de la calidad comprende todos los procesos y actividades que determinan las políticas, objetivos y responsabilidades relacionados con la calidad, entendida ésta principalmente en dos sentidos: conformidad con unas normas y estándares (por ejemplo, la norma ISO/IEC 9126, de calidad del software) y satisfacción del cliente. Actualmente, la gestión de la calidad incluye también los procesos de mejora continua, la responsabilidad de la dirección por la asignación de recursos y otros.
La gestión de recursos humanos tendría que incluir los aspectos de organización y asignación de responsabilidades para los hitos, actividades y tareas, como mínimo, así como, más allá de eso, todos los procesos y actividades para la incorporación, coaching, desarrollo, evaluación y progreso del capital humano asignado al proyecto. Por desgracia, muy a menudo no es así y la mayor oportunidad de aprendizaje y crecimiento que tienen los profesionales TIC (que normalmente trabajan para proyectos) queda desperdiciada.
La gestión de la comunicación del proyecto es el área de conocimiento que incluye los procesos de generación, recogida, distribución, almacenamiento, recuperación y disposición final de la información del proyecto por las diferentes partes interesadas. Dijimos en un apartado anterior, y quizá podía parecer exagerado, que gestionar bien un proyecto no es sólo hacer lo que se tiene que hacer para alcanzar los objetivos sino también saberlo explicar para articular y satisfacer las expectativas del cliente. La ultima versión del PMBOK ha incorporado los procesos de gestión de expectativas dentro de esta área de conocimiento.
La gestión de los riesgos incluye los procesos necesarios para identificar aquellos acontecimientos potenciales que pueden tener un impacto sobre el proyecto, anticipar su aparición, prever las consecuencias, planificar las respuestas, acciones correctoras y contingencias y tomar las decisiones adecuadas en el momento en que se produzca el riesgo. El riesgo y la incertidumbre son elementos naturales en la gestión de los proyectos TIC y son de todo tipo. Lo que se tiene que tener son políticas, procedimientos y métricas que ayuden a tratarlos adecuadamente y personas con la experiencia, sangre fría y determinación para hacer lo que procede hacer.
La administración y gestión de compras y contratos del proyecto incluye toda la administración (compras, contratos, facturación, cobros) del proyecto, tanto en nuestra relación con el cliente como en la que tenemos con los subcontratistas. En el ámbito TIC, con el aumento del volumen y la complejidad de los proyectos, éste no es sólo un trabajo auxiliar o administrativo, sino un aspecto cada vez más crítico con consecuencias económicas y legales muy importantes y de alto riesgo.
En este módulo hemos presentado también los productos o documentos principales para la gestión de proyectos, los que consideramos básicos para cualquier tipo de proyectos y otros que recomendamos para proyectos de cierta dimensión y complejidad.