Navegando Por La Guía Del PMBOK

3 Navegando
por la Guía del

PMBOK®
3.1. Grupo de Procesos de Inicio ................................................................................................................85
3.2. Grupo de Procesos de Planificación..................................................................................................87
3.3. Grupo de Procesos de Ejecución ..................................................................................................... 103
3.4. Grupo de Procesos de Monitorización y Control ..................................................................... 110
3.5. Grupo de Procesos de Cierre ............................................................................................................ 117

3. Navegando por la Guía del PMBOK®
Para cada uno de los 47 procesos, la Guía del PMBOK® describe una serie de entradas, salidas, herramientas y
1
técnicas. En total, se contabilizan 409 entradas y salidas y 209 herramientas y técnicas . Por otra parte, los 47
procesos tienen muchas relaciones y son interdependientes (algunas herramientas y técnicas se reúsan en varios
procesos, y las salidas de algunos son entradas de otros). Esto supone mucha complejidad y dificulta el estudio,
sobre todo cuando quiere seguirse el flujo lógico de las actividades de gestión a lo largo del ciclo de vida del
proyecto, desde que el proyecto comienza hasta que termina.
Con el fin de facilitar el seguimiento de los contenidos de este libro, se utilizará un método de representación
basado en el estándar IDEF0. IDEF0 es un método sencillo de especificación formal de procesos, que permite la
descomposición de procesos a través de un análisis descendente (top-down).
El estándar IDEF0 se ha adaptado en este libro con los siguientes convenios de representación:
 Las cajas representan los procesos elementales (nivel más bajo de detalle, con una marca en la esquina
superior izquierda) y también los grupos de procesos que tenga sentido agrupar a este nivel, y que serán
detallados en niveles inferiores.
 Las flechas entrantes a las cajas por el lado izquierdo representan las entradas (documentos, información,
eventos, etc.). Las flechas salientes por el lado derecho representan las salidas.
 En IDEF0, las flechas entrantes por arriba son flechas de control, en nuestro caso representan las técnicas.
2
Las flechas entrantes por abajo (flechas de mecanismo en IDEF0) representan las herramientas .
 Todas las flechas entrantes o salientes a una caja aparecen en su nivel de descomposición inferior. Para
favorecer la simplicidad de la representación, a veces las flechas aparecen en la descomposición y no en el
diagrama superior (esto se marca con un paréntesis sobre la flecha, o túnel). También por simplicidad en la
representación, si una flecha se usa en todas las cajas, se representa sin entrar en ninguna de ellas.
La forma de representar los procesos basada en el estándar de modelado de procesos IDEF0 permite obtener una
visión dinámica de los procesos, sus detalles y sus dependencias. En el enlace http://goo.gl/5bKXzl puede
descargar un fichero PDF titulado “Navegador de la Guía del PMBOK®”. Pulsando en las cajas de los diagramas,
que representan procesos o grupos de procesos, podrá navegar por las 10 áreas de conocimiento y los 47
procesos. También podrá acceder a ciertos ejercicios sobre los procesos representados en cada diagrama.
1 Véase el anexo II con la enumeración completa de entradas, salidas, herramientas y técnicas para cada proceso.
2 La Guía del PMBOK® no distingue entre herramientas y técnicas. En los diagramas se han ubicado como herramientas las que pueden ser
automatizadas. Por ejemplo: “observaciones” podría ser una técnica, o bien una herramienta si se automatizan con grabaciones por vídeo.
El Director de Proyectos a Examen | 81

De esta manera, una visión de alto nivel de la gestión de proyectos puede representarse de esta forma:
 La organización patrocinadora, a través de un patrocinador o bien un iniciador externo al proyecto,

solicita la realización de un proyecto, sobre la base de un caso de negocio, un enunciado del trabajo o un
acuerdo (que muchas veces es de tipo contractual).
 Si la organización ejecutora aprueba el proyecto, finalmente se observará que se entrega formalmente un
producto, servicio o resultado final a la organización solicitante, para que lo utilicen los usuarios finales.
Otro resultado que puede observarse “desde fuera” es que se generan una serie de documentos fruto del
trabajo del proyecto.
 Desde que el proyecto se solicita hasta que se entrega, tienen lugar una serie de esfuerzos que se supone
debe dirigir el director del proyecto. La Guía del PMBOK® es precisamente una serie de buenas prácticas
perfectamente estructuradas que el director del proyecto debe conocer y dominar para no reinventar la
rueda: “Todo lo que puede necesitar un director de proyectos ya está inventado”. Sin embargo, lo primero que
debe considerar el director del proyecto es que ese proyecto “no ocurre aisladamente”, sino que tiene lugar
dentro del contexto de una organización ejecutora y por tanto ha de tener en cuenta los factores de
contorno (factores ambientales de empresa) y los artefactos de gestión escritos o normativa obligada
(activos de procesos de la organización).
 El equipo de dirección del proyecto comienza generalmente por identificar a los interesados y documentar
los requisitos de la organización solicitante.
 Cuando la organización ejecutora no realiza todo el alcance el proyecto, sino que subcontrata una o varias
partes a proveedores, estos presentarán sus mejores propuestas. Y la organización ejecutora determinará
los proveedores seleccionados. La relación con estos proveedores durante el proyecto se administrará
generalmente a través los correspondientes contratos.
82 | El Director de Proyectos a Examen

Si se baja a un nivel mayor de detalle, puede apreciarse cómo se resuelven las entradas y salidas a través de los
3
cinco grupos de procesos :
 Inicio: A partir de la información de contexto sobre el caso de negocio, el acuerdo y/o el enunciado del
trabajo, si se aprueba el proyecto, se genera el acta de constitución del proyecto, documento que
sirve para autorizar oficialmente el proyecto dentro de la organización ejecutora, nombrando al
director de proyectos, y otorgándole el nivel de autoridad para utilizar los recursos de la
organización. La otra actividad inicial no menos importante es la obtención de la información
relevante sobre los distintos interesados. Es buena práctica recomendada que el director del
proyecto esté presente antes de la aprobación del proyecto para que ayude a integrar toda la
información generada en el debate que ha mantenido la organización sobre si hacer o no el
proyecto, y para que ayude a elaborar el acta de constitución, destacando la información clave para
justificar el proyecto y reclamando por escrito su nivel de autoridad.
 Planifica- A partir del acta de constitución del proyecto y el registro de interesados, siguiendo los 24
ción: procesos de planificación, se acaba produciendo el documento maestro para la ejecución y el control
del proyecto: el plan para la dirección del proyecto. Entre otra mucha documentación importante,
también se puede generar, si el proyecto requiere la concurrencia de proveedores externos a la
organización ejecutora, la documentación necesaria para efectuar las adquisiciones. En este grupo
de procesos el director de proyectos debe usar su potente imaginación, como si fuera un oráculo, o
un adivino con su bola de cristal, para visualizar el futuro del proyecto: qué habrá que hacer y qué no,
cuánto durará, cuánto costará, cómo generar un producto que logre la satisfacción del cliente o la
organización solicitante, quién deberá formar parte del equipo, qué comunicar a quién, cuándo y en
qué forma, cómo anticiparse a los problemas, qué hay que adquirir a terceros y qué estrategia hay
que seguir con los principales interesados.
3 Obsérvese que el gráfico 3-3 de la página 53 de la Guía del PMBOK® contiene básicamente la misma información.

 Ejecu- El director del proyecto dirige el trabajo definido en el plan del proyecto y la implementación de las
ción: solicitudes de cambio aprobadas para obtener los entregables planificados, manteniendo
continuamente actualizados los documentos del proyecto y registrando las comunicaciones, los
incidentes y los datos de desempeño para su posterior análisis. Su objetivo es “hacer que las cosas
se hagan”, buscando más la eficiencia que la eficacia, coordinando el trabajo que deben hacer los
miembros del equipo. Podemos decir que aquí se parece a un director de orquesta que sigue la
partitura del plan del proyecto (y de los cambios aprobados) para que suene “la melodía del
proyecto”. Cuando algo no ocurre como esperaba (p.ej., un violinista desafina) no se para la música,
simplemente se emite una solicitud de cambio para su posterior evaluación y análisis.
 Monito- El equipo del proyecto verifica que los entregables son correctos y el director del proyecto gestiona
rización la entrega y persigue la aceptación por parte del cliente o la organización solicitante. A partir de los
y datos de desempeño del trabajo, se juzga si el proyecto progresa adecuadamente, en fecha, en
Control: coste y si no es así se solicitan cambios para volver a las líneas base. Con ayuda de su equipo núcleo
y del comité de control de cambios, el director del proyecto gestiona integradamente los cambios
(que se solicitan en la ejecución o como resultado de la monitorización y control) para procesarlos en
bloque y atendiendo a su prioridad relativa. En este grupo de procesos, podríamos decir que el
director de proyectos se parece al médico que vigila el estado de salud del proyecto, evalúa los
progresos y propone acciones para conseguir que se cumplan los objetivos.
 Cierre: Una vez los interesados han satisfecho o superado sus expectativas y se han aprobado los
entregables, se procede al cierre ordenado del proyecto y a la transferencia formal del producto,
servicio o resultado final fruto del proyecto o la fase. Por lo que respecta a los contratos que se
gestionan durante el proyecto, cada vez que un proveedor cierra su proyecto, la organización
ejecutora debe cerrar formalmente el contrato y así concluye la relación contractual y la
responsabilidad legal de ambas partes.
Lo que viene a continuación es una descripción de los procesos de gestión de un proyecto, desde su inicio hasta
su cierre, a través de los cinco grupos de procesos, navegando por la Guía del PMBOK®.

3.1. Grupo de Procesos de Inicio

En cualquier organización, ya sea orientada a proyectos, matricial o funcional, la decisión
de lanzar un proyecto no debe tomarse a la ligera. Antes de comprometer recursos y
presupuesto, es preciso un análisis sobre si el proyecto está justificado en ese momento.
Por otra parte, cuando el proyecto se aprueba, debe quedar constancia escrita, al menos,
del patrocinador y del director del proyecto asignado. Cuando un gran proyecto se
subdivide en varias fases, reactivar los procesos de inicio al comienzo de cada nueva fase
permitirá:
 mantener el proyecto centrado en la necesidad de negocio,
 verificar los criterios de éxito,
 revisar la influencia y los objetivos de los interesados.
De esta manera, se puede tomar una decisión fundada sobre la necesidad de continuar, posponer o cancelar el
proyecto.
El equipo de dirección del proyecto realiza, entre otras, las siguientes actividades de inicio:
 Estudio de viabilidad: Realizar la valoración del proyecto sobre la base de la información disponible y
reuniones con el patrocinador, el cliente o la organización solicitante, y otros expertos en la materia, para
evaluar la viabilidad de nuevos productos o servicios considerando los supuestos y restricciones.
 Alcance de alto nivel: Definir el alcance de alto nivel del proyecto a partir de los requisitos del negocio y
de cumplimiento, para cumplir las expectativas del cliente o la organización solicitante del proyecto.
 Análisis de interesados clave: Realizar el análisis de los interesados clave usando tormenta de ideas,
entrevistas y otras técnicas de recopilación de información, para asegurar el alineamiento con las
expectativas y ganar apoyo para el proyecto.
 Riesgos de alto nivel: Identificar y documentar los riesgos de alto nivel, supuestos y restricciones a partir
del entorno actual, información histórica y juicio de expertos, para identificar las limitaciones del proyecto y
proponer un enfoque de implementación.
 Acta de constitución del proyecto: Desarrollar el acta de constitución del proyecto analizando con mayor
profundidad los requisitos de los interesados para cumplir el alcance del proyecto, hitos y entregables.
Obtener la aprobación del acta de constitución del proyecto por parte de la organización patrocinadora y la
organización solicitante (si es necesario), para formalizar la autoridad asignada al director del proyecto y
conseguir el compromiso y la aceptación del proyecto.

En la figura pueden apreciarse las principales entradas, salidas, herramientas y técnicas, del grupo de procesos de
inicio:
A partir de la información de contexto sobre la necesidad del proyecto, se genera el acta de constitución del
proyecto. La otra actividad inicial no menos importante es la elaboración de un registro de interesados con la
información relevante sobre su posición respecto al proyecto, poder, interés, conocimiento, accesibilidad, etc.
Durante el inicio del proyecto, hay que contemplar a la vez dos áreas de conocimiento: La gestión de la
integración (para resumir todo el debate organizativo de la alta dirección, expertos en la materia, estudios de
viabilidad, planes de negocio, etc. en un documento llamado acta de constitución del proyecto) y la gestión de
los interesados (para identificar a los mismos).
Así es como define los procesos de inicio la Guía del PMBOK®:

 4.1 Desarrollar el Acta de Constitución del Proyecto: Desarrollar un documento que autoriza
formalmente la existencia de un proyecto y confiere al director del proyecto la autoridad para asignar los
recursos de la organización ejecutora a las actividades del proyecto.
 13.1 Identificar a los Interesados: Identificar a las personas, grupos u organizaciones que podrían ejercer
o recibir el impacto de una decisión, actividad o resultado del proyecto, así como de analizar y documentar
información relevante relativa a sus intereses, participación, interdependencias, influencia y posible impacto
en el éxito del proyecto.

3.2. Grupo de Procesos de Planificación

En su día a día, el director de proyectos debe ser un especialista en visualizar su
proyecto. Los proyectos se crean dos veces: primero se hacen reales en su mente
(los crea en su bola de cristal); finalmente acabarán siendo una realidad para los
interesados. Antes de que se produzcan los entregables, el director del proyecto ya
los ha imaginado. Antes de que los miembros del equipo sigan los procesos, el
director del proyecto “ya ha estado allí”. Empezar con un fin en la mente, en
gestión de proyectos, significa algo muy concreto: planificar. Una buena
planificación es clave para el éxito de cualquier proyecto (como se dice en inglés,
“fail to plan is plan to fail”, que podría traducirse como: fracasar planificando es
planificar el fracaso). Cuando observamos que alguien gestiona un proyecto
haciendo solo lo que le manda el cliente, reaccionando a los problemas y crisis que
surgen en el día a día, ¿de verdad podemos llamar a eso gestionar un proyecto? Un director de proyectos que no
tiene el hábito de planificar causa muy mala impresión. No está haciendo bien su trabajo. Que no diga que está
gestionando un proyecto, está gestionando otra cosa. Es normal que se ruborice cuando en una reunión de
seguimiento un interesado clave le acusa de improvisar constantemente. ¿Qué imagen proyecta si no sabe mejor
que nadie lo que hay que hacer a partir de hoy? Una vez superada la fase de inicio habiendo decidido lanzar el
proyecto, hay que tratar de estimar, a partir de la información disponible y con un margen de error aceptable,
aspectos tan importantes como qué hay que hacer y qué no, cuánto esfuerzo supondrá el proyecto, cuánto
costará, cuándo terminará, cómo se sabrá si el producto final es bueno o malo, qué tipo de recursos se
necesitarán, cuántos y cuándo, quién debe comunicarse con quién y cómo, cuáles son los potenciales problemas
que pueden ocurrir, qué partes habrá que contratar a proveedores, etc.
El grupo de procesos de planificación es sin duda el más importante de la Guía del PMBOK®, como lo demuestra
el hecho de que, de los 47 procesos, 24 pertenecen a este grupo. Simplificando mucho, podríamos decir que un
director de proyectos es un especialista en planificar líneas base, para después controlar las desviaciones durante
la ejecución (y el resto son habilidades interpersonales). Si algo distingue a los proyectos de las operaciones, en
cuanto al grado de gestión que requiere un proyecto, es la necesidad de ceñirse a un calendario, a un
presupuesto y a un alcance predeterminados, y todo esto ha de planificarse meticulosamente.
A partir del acta de constitución del proyecto y del registro de

interesados, siguiendo los 24 procesos de planificación, se acaba
produciendo un documento maestro para la ejecución y el control del
proyecto, denominado plan para la dirección del proyecto. En la
mayoría de los proyectos, este importante documento se mantiene
actualizado hasta que se cierra el proyecto, es decir: no se produce una
vez, sino que se versiona sucesivamente, por iteraciones incrementales, a
medida que se va obteniendo mejor información. Entonces se dice que se practica una “planificación gradual”. En
cualquier caso, la re-planificación está presente cuando se decide aprobar cambios que afectan al plan (nótese la
flecha de realimentación desde control a planificación del diagrama IPECC). También hay realimentación de
control a planificación cuando se producen actualizaciones en los documentos del proyecto o se aprueban
cambios.

El equipo de dirección del proyecto realiza, entre otras, las siguientes actividades de planificación:
 Requisitos: Evaluar detalladamente con los interesados requisitos, restricciones y supuestos a partir del
acta de constitución del proyecto, lecciones aprendidas de proyectos previos y el uso de técnicas de
recopilación de requisitos, para determinar los entregables del proyecto.
 EDT: Crear una EDT con el equipo, descomponiendo el alcance para su mejor gestión.
 Presupuesto: Desarrollar un presupuesto a partir del alcance del proyecto usando técnicas de estimación.
 Cronograma: Desarrollar un cronograma del proyecto a partir de los plazos marcados, el alcance y los
recursos, para gestionar la conclusión en plazo del proyecto.
 Recursos Humanos: Desarrollar un plan de gestión de recursos humanos definiendo los roles y
responsabilidades del los miembros del equipo del proyecto para crear una estructura organizativa efectiva
y dirigir la utilización y la gestión de los recursos.
 Comunicación: Desarrollar un plan de comunicación a partir de la estructura organizativa del proyecto y los
requisitos de los interesados externos, para gestionar el flujo de información del proyecto.
 Adquisiciones: Desarrollar un plan de adquisiciones a partir del alcance y el cronograma, para asegurar que
los recursos requeridos estarán disponibles.
 Calidad: Desarrollar un plan de gestión de calidad a partir del alcance y los requisitos, para prevenir
defectos y reducir el coste de la calidad.
 Cambios: Desarrollar un plan de gestión de cambios definiendo cómo los cambios serán gestionados
asegurando su trazabilidad.
 Riesgos: Planificar la gestión de riesgos identificando, analizando y priorizando los riesgos para gestionar la
incertidumbre a lo largo del ciclo de vida del proyecto.
 Plan del Proyecto: Presentar el plan del proyecto a los interesados (si es necesario) para obtener la
aprobación para ejecutar el proyecto.
 Kick-off: Realizar una reunión de lanzamiento para anunciar el comienzo del proyecto, comunicar los hitos
y compartir la información relevante.

En la figura pueden apreciarse los principales subgrupos de planificación:
Los 24 procesos de planificación pueden agruparse en tres subgrupos: 1) procesos obligatorios; 2) procesos
opcionales; y 3) procesos para cerrar la planificación.
 El primer subgrupo contiene la planificación del alcance (qué hay que hacer y qué no, y cómo se
descompone el esfuerzo del proyecto), los recursos humanos (quién debe hacerlo y cómo hay que
organizar el equipo), los interesados (para quién será el producto del proyecto y cómo hay que gestionar
sus expectativas y su participación), las comunicaciones (quién debe comunicarse con quién, cómo y
cuándo) y los tiempos (cuándo hay que empezar y terminar qué actividades).
 El segundo subgrupo contiene las áreas que a veces no se planifican: A veces no se planifican los riesgos o
la calidad, y muchas veces se presta poca atención a las adquisiciones cuando se subcontratan ciertas
partes del proyecto.
 En el tercer subgrupo tenemos esa “segunda vuelta” que hay que darle a las actividades para cerrar el
cronograma alineado con los objetivos de tiempo, presupuesto y financiación. También tenemos la
planificación de los costes (cuánto costará el proyecto y cuándo se irá consumiendo el presupuesto). Y por
último, hay que compilarlo todo en el documento plan para la dirección del proyecto.

El segundo bloque está colocado, a propósito, en el centro. Estos procesos están en el corazón de la planificación
porque muchos proyectos fracasan por planificar incorrectamente los riesgos (qué tenemos “derecho a creer” y
qué no), las adquisiciones (cómo hay que administrar el contrato que rige los trabajos de un tercero en nuestro
proyecto) y la calidad (qué hay que hacer para que lo que entreguemos sea aceptado como bueno por el cliente
o la organización solicitante).
Si profundizamos en este segundo bloque, como puede apreciarse en la figura, planificar los riesgos se resume en
obtener el registro de riesgos, un documento en el cual se detallan los resultados del análisis de riesgos y de la
planificación de la respuesta a los mismos. El resultado principal de planificar la calidad es el plan para la gestión
de la calidad, que describe cómo se implementarán las políticas de calidad para garantizar que se trabajará
correctamente y para controlar que los resultados que se obtendrán serán correctos. De planificar las
adquisiciones resulta el plan para la gestión de las adquisiciones, que describe cómo el equipo de proyecto
adquirirá bienes y servicios desde fuera de la organización ejecutora.

En el Corazón de la Planificación: Riesgos, Calidad y Adquisiciones

A veces los proyectos acaban en fracaso porque terminan muy tarde, con mucho sobrecoste, mala calidad, etc.
Otras veces se cancelan antes de terminar porque las desviaciones han llegado a tal punto que tanto la
organización solicitante como la organización ejecutora deciden que no se puede continuar, llegando a veces al
extremo de tener que ir a juicio. En los proyectos, los fracasos son muy transparentes y observables. Cualquier
persona puede constatar que el proyecto ha fracasado, por ejemplo, porque debería haber terminado en quince
meses y dura más de veinte, porque acumula unas pérdidas netas de cientos de miles de euros, o porque el
cliente no acepta las entregas y por tanto no paga.
Cuando se hace un análisis post-mortem de un proyecto que ha fracasado, muchas veces descubrimos que la
causa principal se originó “aguas arriba”, al realizar planificación. Cuando un proyecto fracasa estrepitosamente
por razones de planificación, generalmente no es por haber programado erróneamente el cronograma o
estimado incorrectamente los costes: “no somos tan malos estimando”. Tampoco hay que buscar la causa en
planificar erróneamente las comunicaciones o la gestión de recursos humanos: estas áreas son muy
importantes, pero su papel es decisivo durante la ejecución, más que en la planificación.
Siendo también muy importante planificar bien el alcance, es decir, qué debe hacerse en el proyecto y qué no
debe hacerse) tampoco suele ser la principal causa de fracaso si se planifica incorrectamente, por dos razones:
 La primera es que en todo proyecto siempre dedicamos tiempo y esfuerzo, lo queramos o no, a averiguar
qué quieren los interesados y qué hay que hacer en el proyecto.
 La segunda razón y más importante es que, aunque no se haga bien, esto es: no gestionemos bien los
requisitos, no documentemos bien las inclusiones, exclusiones, la descripción de los paquetes de trabajo,
etc., cuando el proyecto fracasa gravemente por temas de alcance suele ser porque aparecen trabajos
inesperados que hay que incluir, debido a graves problemas que surgen y no los hemos visto venir y se
producen crisis. Esto se explica mejor desde una perspectiva de la gestión del riesgo. Otras veces hay que
asumir una gran cantidad de retrabajo para que la organización solicitante acepte los entregables. Esto se
explica mejor desde la perspectiva de gestión de la calidad.
En general, podemos decir que un proyecto fracasa desde la planificación cuando se planifican mal estas tres
áreas de conocimiento: riesgos, calidad y adquisiciones. Podríamos decir: “Fail to Plan Risk, Quality and
Procurement is Plan to Fail”.

Planificar incorrectamente los Riesgos

Muchos proyectos fracasan porque, de repente, ocurre un problema inesperado que lleva al proyecto a su
cancelación. Nos convencemos a nosotros mismos de que estamos gestionando riesgos porque tenemos una lista
de riesgos y la vamos repasando en cada reunión de seguimiento, pero no pensamos en los riesgos importantes,
esos que si ocurren hacen que el proyecto ya no se justifique. En palabras de Tom DeMarco: “Muchas veces nos
ocupamos de no tropezar con los raíles, pero no vemos el tren que se acerca.”
Algunos casos que ilustran esos riesgos del tipo “tren que se acerca”:
 Un proyecto de consultoría de ayuda al desarrollo de pequeñas y medianas empresas de Egipto financiado
por el gobierno, tuvo que cancelarse en marzo de 2011, después de las revueltas que derrocaron a Hosni
Mubarak. Los miembros del comité de dirección de Madrid se vieron sorprendidos por la cancelación.
 Un proyecto de desarrollo software en Chile acabó siendo un fracaso financiero porque el contratista
principal nos hizo responsables de fallos funcionales. Esto sorprendió al equipo de dirección del proyecto,
que siempre asumió que nuestra responsabilidad quedaba restringida al plano técnico.
 Otro caso, todo un clásico en gestión de riesgos, es el caso del aeropuerto de Denver, que tuvo que esperar
15 meses para empezar a operar (lo que supuso unas pérdidas de 500 M$) debido al retraso inesperado en
la entrega del sistema software que gestionaba el equipaje de los viajeros.
Lo contrario a gestión de crisis se llama gestión de riesgos. La peor imagen

que puede proyectar un director de proyectos es cuando ocurre un desastre y él
no lo tenía previsto, y se le ve nervioso, improvisando, alarmando a todos,
pulsando el botón de “crisis”. Un director de proyectos quiere problemas, no
sorpresas. Quiere ver los problemas venir, y tener preparada una respuesta que
aplicar cuando los problemas ocurren. No quiere improvisar. Debe tener en
cuenta que se le va a juzgar muy mal si ocurre un problema importante que no
tenía previsto. Para no llegar a dar nunca esta mala imagen, lo que debe hacer es
anticiparse, registrar los riesgos con detalle mientras son abstracciones. Y sobre
todo, debe comunicarlos bien. Un director de proyectos no comunica las
incertidumbres empleando un tono de “queja”, o bien para asustar al grupo de
interesados, sino que comunica con madurez y objetividad. Suele emplear frases
como: ¿Tenemos derecho a creer que esto va a ocurrir como estamos esperando? Si no es así, tendríamos que
anticiparnos con estas actividades. Si finalmente ocurre el problema, tendríamos que prepararnos para ejecutar estas
otras actividades de forma eficaz. La frase ¿tenemos derecho a creer? es la llave para abordar con madurez la
gestión de riesgos.

Planificar adecuadamente los Riesgos

La gestión de riesgos del proyecto consiste en identificar, analizar, planificar las
respuestas y controlar las incertidumbres del proyecto. Ha de realizarse de
manera continua e iterativa durante la ejecución del proyecto, pues los factores
que definen y afectan a los riesgos cambian continuamente. Fundamentalmente
hay que monitorizar los indicadores de transición, o disparadores, pero además
es necesario que el proceso de identificación continúe, por si aparecen nuevos
riesgos (lo que requerirá replanificación), y también hay que monitorizar cuándo
expiran.
Los tres grandes pasos para planificar los riesgos son: 11.1 Planificar la Gestión de los Riesgos (definir cómo
realizar las actividades de gestión de riesgos de un proyecto), analizar los riesgos (lo que produce un registro de
riesgos con toda la información de los riesgos identificados y analizados) y por último 11.5 Planificar la
Respuesta a los Riesgos (desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas
que afecten a los objetivos del proyecto). Las salidas principales de los procesos de planificación de los riesgos del
Proyecto son el plan de gestión de los riesgos y el registro de riesgos.

A continuación se detalla el bloque central de planificar los riesgos: analizar los riesgos:
 11.2 Identificar los Riesgos: Determinar los riesgos que pueden afectar al proyecto y documentar sus
características.
 11.3 Realizar el Análisis Cualitativo de Riesgos: Priorizar los riesgos para análisis o acción posterior,
evaluando y combinando la probabilidad de ocurrencia e impacto de dichos riesgos.
 11.4 Realizar el Análisis Cuantitativo de Riesgos: Analizar numéricamente el efecto de los riesgos
identificados sobre los objetivos generales del proyecto.

Planificar incorrectamente las Adquisiciones

A un director de proyectos normalmente le causa intranquilidad que una parte importante de su proyecto haya
que subcontratarla a un tercero, ya que es algo que escapa de su zona de control. Lo mejor para él sería tener un
equipo completo, bien formado, que asumiera todas las actividades, pero si esto no es posible, ya sea por razones
de menor coste o plazo, mejor capacitación, de transferencia de riesgos, etc., a veces no hay más remedio que
contratar como servicio un proyecto que hacen otros, para integrar sus resultados en nuestro proyecto.
En esta situación, el director de proyectos no controla los trabajos, sino que

administra el contrato. Actúa desde la parte cliente y espera los entregables
para aceptarlos, cuando quizá ya es demasiado tarde para influir. Cuando hay
conflictos, no tiene una posición de mucho poder para negociar,
generalmente debe acudir a la dirección de su empresa, al departamento
legal, etc. En el peor de los casos, cuando el proyecto fracasa y el contrato hay
que resolverlo en los tribunales, tiene que ir a juicio y prestar declaración
representando a su empresa.
Planificar incorrectamente la Calidad

El efecto de satisfacción final del cliente no se improvisa, hay que sembrarlo y
trabajarlo continuamente. Cuando decimos que “la calidad se planifica”, esto
significa que hay que imaginar los criterios de aceptación, y hay que diseñar
los procesos de aseguramiento y control de calidad que para que sea más
probable que dichos criterios de aceptación se satisfagan. Sin embargo, es
muy frecuente que los clientes no firmen los requisitos. ¿Qué se puede hacer
entonces para gestionar las expectativas del cliente?
Imagine que dirige un proyecto de desarrollo de software. Recopila los requisitos el primer mes. Trabaja con su
equipo en sus instalaciones durante seis meses, terminan y entregan. Han sido muy eficientes, por supuesto, pero
¿habrán sido igualmente eficaces?
El cliente verá el producto por vez primera el mes siete. Muy probablemente, no coincidirá con su idea inicial y
rechazará la mayor parte de la funcionalidad. Las sucesivas iteraciones de prueba y reparación no lograrán niveles
aceptables de calidad percibida. El día de la puesta en producción será imposible reducir los defectos a un nivel
aceptable para el cliente. Si se pudiera medir el riesgo del proyecto, comprobaríamos que se acumula mucha
exposición hasta el día de la entrega. En la fase de pruebas se reduce el nivel de riesgo. Por otra parte, hasta que
se produce la entrega, la calidad percibida es nula. Cuando se ve el producto, comienza a subir la percepción de
calidad, pero no hasta llegar al nivel de superar los criterios de aceptación.

Planificar adecuadamente las Adquisiciones y la Calidad
La gestión de las adquisiciones del proyecto consiste en comprar o adquirir los

productos, servicios o resultados requeridos a terceros ajenos a la organización.
El proceso 12.1 Planificar la Gestión de Adquisiciones del Proyecto consiste en

documentar las decisiones de adquisiciones del proyecto, especificar el enfoque e
identificar a los proveedores potenciales. La salida más importante de este proceso
es el plan de gestión de las adquisiciones.
Cuando un director de proyectos ha sufrido una mala relación contractual y le asignan a otro proyecto en el que
hay que subcontratar, se vuelve muy paranoico: Guarda todos los correos, todas las evidencias sobre mal
desempeño, sobre fechas de entrega, pagos, cumplimiento de hitos, etc. Pero sobre todo esto, tiene muy en
cuenta lo siguiente: “Si no está escrito en el contrato, el proveedor se puede negar a hacerlo”. Sabe que debe leer
todo el contrato, todas las cláusulas, y le preocupa mucho que los trabajos que necesita el proyecto queden
especificados lo mejor posible.
Cuando le dejan influir sobre el tipo de contrato, no quiere un contrato por tiempo y materiales porque para esa
forma de trabajar prefiere a su propio equipo, y además si algo sale mal, el proveedor se lava las manos y la culpa
es del director de proyectos. Prefiere un contrato a precio cerrado, bien especificado el alcance, eso sí, y si es
posible con incentivos por buen desempeño.

La gestión de la calidad del proyecto consiste en determinar

responsabilidades, objetivos y políticas de calidad a fin de que el proyecto
satisfaga las necesidades para las que se lleva a cabo. Algo es de buena calidad
cuando es conforme con los requisitos del cliente. Tradicionalmente, la calidad
se inspeccionaba. En el enfoque moderno, la calidad se planifica: Primero se
determinan los requisitos de calidad o criterios de aceptación del cliente.
Después se planifica la calidad (estándares y métodos aplicables), y a
continuación, con el proyecto en marcha, se asegura que el proceso cumple los
estándares y se controla que los productos tienen los niveles de calidad
prefijados. El proceso 8.1 Planificar la Gestión de Calidad consiste en identificar los requisitos y/o estándares de
calidad para el proyecto y sus entregables, así como de documentar la manera en que el proyecto probará el
cumplimiento con los requisitos de calidad. La salida más importante de este proceso es el plan de gestión de la
calidad.
Tomemos de nuevo el ejemplo del proyecto de desarrollo de software en el que no se producía ninguna entrega
hasta el mes siete. Imagine ahora que practica un modelo de ciclo de vida iterativo-incremental. Observe cómo
mejora la gestión de expectativas del cliente.
En cada iteración se construye algo que se puede probar, reparar y enseñar al cliente. La calidad percibida va
creciendo desde el principio, y los niveles de riesgo se mantienen controlados. En la quinta iteración se hace una
entrega formal y una parte del sistema que ya puede usar. En la figura puede observarse que hay previstas cuatro
entregas más: la última entrega parcial servirá para cerrar el proyecto.
Cada vez que se produce una entrega, el cliente va modelando su propia imagen del producto y da
realimentación. Es muy probable que reformule algunos requisitos, que diga “eso está bien, pero…” y a
continuación una serie de elementos que quiere cambiar. Cuando en la siguiente entrega el equipo entregue lo
que había pedido, esto ya no lo va a discutir. Discutirá otras cosas, cada vez menos.
En proyectos con mucha incertidumbre, es eficaz gestionar la calidad con iteraciones incrementales. En un
esquema de despliegue iterativo-incremental, se ordenan las entregas: primero lo más importante, más complejo,
de más riesgo, o valor. Se deja para el final la funcionalidad secundaria. De esta manera, si el proyecto se cancela,
o se adelanta la fecha límite, pueden entregarse partes con valor para el cliente. Desde las primeras entregas
(prototipos, pruebas de concepto, subsistemas funcionales, etc.) los usuarios ofrecen su realimentación positiva o
negativa. Poco a poco, el sistema se va pareciendo, por aproximaciones sucesivas, a lo que realmente necesitan. El
valor del proyecto se aprecia continuamente.

Desarrollar la Línea Base de Alcance

La gestión del alcance del proyecto incluye los procesos necesarios para garantizar que el proyecto incluye todo
el trabajo requerido y únicamente el trabajo requerido para completarlo con éxito. El alcance del proyecto es el
trabajo que debe hacerse para entregar un producto, servicio o resultado con las características y funciones
especificadas. La gestión del alcance se refiere a los trabajos del proyecto (qué hay que hacer y qué no) y también
al producto (qué características y funciones debe incorporar y cuáles no). La validación del alcance del producto
se mide contra los requisitos. La validación del alcance del proyecto se mide contra la línea base del alcance.
Una buena planificación del alcance servirá para orientar al director del proyecto en la toma de decisiones a la
hora de decidir añadir o quitar trabajos, y al controlar qué está incluido y qué no, tanto en el proyecto como en el
producto. La planificación del alcance comprende los siguientes procesos:
 5.1 Planificar la Gestión del Alcance: Crear un plan para la
gestión del alcance que documente cómo se va a definir,
validar y controlar el alcance del proyecto.
 5.2 Recopilar Requisitos: Determinar, documentar y
gestionar las necesidades y los requisitos de los interesados
para cumplir con los objetivos del proyecto.
 5.3 Definir el Alcance: Desarrollar una descripción detallada
del proyecto y del producto (qué hay que hacer y qué no hay que hacer).
 5.4 Crear la Estructura de Desglose de Trabajo (EDT): Subdividir los entregables y el trabajo del proyecto
en componentes más pequeños y fáciles de manejar.
La línea base del alcance es la versión aprobada del enunciado del alcance, la EDT, y el diccionario de la EDT. La
línea base del alcance se utiliza como base de comparación entre el trabajo que se está ejecutando realmente y lo
que se debería ejecutar. Sólo puede cambiarse a través de procedimientos formales de control de cambios.

Planificar Recursos Humanos, Comunicaciones e Interesados
 La gestión de los recursos humanos del proyecto incluye los procesos

necesarios para organizar, gestionar y liderar al equipo del proyecto. El
equipo del proyecto está compuesto por las personas a las que se han
asignado roles y responsabilidades para completar el proyecto. El proceso
9.1 Planificar la Gestión de Recursos Humanos consiste en identificar y
documentar los roles dentro de un proyecto, las responsabilidades, las
habilidades requeridas y las relaciones de comunicación, así como de crear
un plan para la administración de personal.
 La gestión de las comunicaciones del proyecto incluye los procesos necesarios para
garantizar la oportuna y adecuada recopilación, creación, distribución, almacenamiento,
recuperación, gestión, control, monitorización y disposición final de la información del
proyecto. El proceso 10.1 Planificar la Gestión de las Comunicaciones consiste en
desarrollar un enfoque y un plan adecuados para las comunicaciones del proyecto sobre la
base de las necesidades y requisitos de información de los interesados y de los activos de la
organización disponibles.
 La gestión de los interesados del proyecto incluye los procesos
necesarios para identificar a todas las personas u organizaciones
impactadas por el proyecto, analizar sus expectativas y su impacto en el
proyecto, y desarrollar estrategias de gestión adecuadas para lograr la
participación eficaz de los interesados en las decisiones y en la ejecución
del proyecto. El proceso 13.2 Planificar la Gestión de los Interesados
consiste en identificar a las personas, grupos u organizaciones que podrían
ejercer o recibir el impacto de una decisión, actividad o resultado del proyecto, así como de analizar y
documentar información relevante relativa a sus intereses, participación, interdependencias, influencia y
posible impacto en el éxito del proyecto.

Planificar las Actividades
La gestión del tiempo del proyecto incluye los procesos necesarios para gestionar la conclusión en plazo del
proyecto. La planificación del tiempo comprende los siguientes procesos:
 6.1 Planificar la Gestión del Cronograma: Establecer las políticas, los
procedimientos y la documentación necesarios para planificar, desarrollar,
gestionar, ejecutar y controlar el cronograma del proyecto.
 6.2 Definir las Actividades: Identificar y documentar las acciones específicas
que se deben realizar para generar los entregables del proyecto.
 6.3 Secuenciar las Actividades: Identificar y documentar las relaciones
existentes entre las actividades del proyecto.
 6.4 Estimar los Recursos de las Actividades: Estimar el tipo y las cantidades
de materiales, recursos humanos, equipos o suministros requeridos para ejecutar cada una de las
actividades.
 6.5 Estimar la Duración de las Actividades: Estimar la cantidad de periodos de trabajo necesarios para
finalizar las actividades individuales con los recursos estimados.
 6.6 Desarrollar el Cronograma: Analizar secuencias de actividades, duraciones, requisitos de recursos y
restricciones del cronograma para crear el modelo de programación del proyecto.
Como puede apreciarse, los procesos del 6.2 al 6.5 se refieren a las actividades individualmente, mientras que en
el proceso 6.6 Desarrollar el Cronograma se integrará toda la información de las actividades para elaborar un
cronograma ajustado a los objetivos del proyecto.

Desarrollar la Línea Base de Costes
La gestión de los costes del proyecto incluye los procesos necesarios para planificar, estimar, presupuestar,
financiar, obtener financiamiento, gestionar, y controlar los costes de modo que se complete el proyecto dentro
del presupuesto aprobado. La planificación de los costes comprende los siguientes procesos:
 7.1 Planificar la Gestión de Costes: Establecer las políticas, los

procedimientos y la documentación necesarios para planificar, gestionar,
ejecutar el gasto y controlar los costes del proyecto.
 7.2 Estimar los Costes: Desarrollar una aproximación de los recursos

financieros necesarios para completar las actividades del proyecto.
 7.3 Determinar el Presupuesto: Sumar los costes estimados de las actividades individuales o de los
paquetes de trabajo para establecer una línea base de coste autorizada.

Desarrollar el Plan para la Dirección del Proyecto
El último proceso de planificación del tiempo es el proceso 6.6. Desarrollar el Cronograma. Consiste en analizar
secuencias de actividades, duraciones, requisitos de recursos y restricciones del cronograma para crear el modelo
de programación del proyecto. Al alimentar el cronograma con la duración de las actividades es muy probable
que se obtenga un plazo superior a la fecha límite. Tras aplicar una serie de alternativas y técnicas de compresión
(o de renegociar las restricciones, por ejemplo aumentando el presupuesto) se consigue ajustar el cronograma a
las necesidades del proyecto. Es sensato que la línea base de cronograma se desarrolle como colofón a las
actividades de planificación, justo cuando ya está clara la línea base de costes y hay que integrar toda la
información para crear el plan para la dirección del proyecto, de lo cual se ocupa el proceso 4.2 Desarrollar el
Plan para la Dirección del Proyecto, del área de integración.
La gestión de la integración del proyecto incluye los procesos necesarios para

identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades
de dirección del proyecto.
El proceso 4.2 Desarrollar el Plan para la Dirección del Proyecto consiste en

definir, preparar y coordinar todos los planes secundarios e incorporarlos en un plan
integral para la dirección del proyecto. Las líneas base y planes secundarios
integrados del proyecto se incluyen en el plan para la dirección del proyecto.

3.3. Grupo de Procesos de Ejecución

El objetivo básico del grupo de procesos de ejecución
es ser eficiente, hacer que las cosas se hagan. El reto de
los proyectos consiste en que el trabajo no lo hace del
director de proyectos, sino el equipo, y el director del
proyecto debe coordinar ese trabajo que hacen otros.
Como si se tratara de un director de orquesta, el director
del proyecto no toca los instrumentos, sino que sigue la
partitura del plan para la dirección del proyecto, donde
está escrito cuándo comienzan y terminan las
actividades, cuándo hay que adquirir y emplear los recursos, cómo hay que efectuar las adquisiciones, adquirir y
desarrollar al equipo, comunicar, etc. Por otra parte, también tiene que dirigir y gestionar el trabajo derivado de
implementar los cambios aprobados. Realmente sigue dos partituras, la del plan y la de los cambios aprobados.
Para ser eficiente, además de “no improvisar”, también es muy importante "no parar". Cuando ocurre algún
incidente, o algo no es como se esperaba, se lleva un registro y se solicita un cambio, pero no se aprueba en ese
momento, normalmente. Ya se decidirá en monitorización y
control el curso de acción más apropiado. Y no será el director
del proyecto el único involucrado en esta decisión. No es buena
práctica reaccionar ante los problemas improvisando cambios en
ejecución, pues entonces el alcance cambiaría continuamente y
no habría un plan que seguir (tendríamos lo que se denomina
scope creep -corrupción del alcance). Como se verá en el grupo
de control, es importante que todos los cambios sigan el circuito
del control integrado de cambios. Es importante recordar que a
un director de proyectos no le gusta cambiar la rueda con el coche en marcha. La mejor práctica es involucrar a los
demás y buscar juntos la solución. Si el problema es verdaderamente urgente e importante, entonces sí hay que
reaccionar e improvisar, por supuesto, pero aun debemos registrar el cambio y seguir el sistema integrado de
control de cambios, aunque sea a posteriori.
El resultado más destacable de la ejecución son los entregables. Mientras no hay entregables, lo único que hay es
comunicación. El director del proyecto dedica gran parte de su tiempo a comunicar y a gestionar expectativas de
interesados. Pero de vez en cuando, el equipo completa los trabajos previstos en una entrega parcial. Todavía no
se entrega al cliente, ya se verá si la entrega pasa el control de calidad y después se preparará para que el cliente
o la organización solicitante pueda validarla y expresar su aceptación, pero esto son tareas de control, no de
ejecución. En cualquier caso, el hecho de que una entrega ya esté preparada para su revisión es muy relevante.
Siguiendo el símil de la orquesta, algún músico haría sonar los platillos.
El diagrama IPECC nos permite simplificar las grandes entradas y salidas

del grupo de ejecución. Obsérvese que hay una flecha desde planificación
a ejecución (el plan), otra flecha desde ejecución a control (los entregables
y los datos de desempeño) y otra desde control a ejecución (los cambios
aprobados).

El equipo de dirección del proyecto realiza, entre otras, las siguientes actividades de ejecución:
 Adquirir los recursos: Obtener y gestionar los recursos del proyecto, incluyendo los externos siguiendo el
plan de adquisiciones.
 Ejecutar las actividades según se definió en el plan del proyecto, para producir los entregables dentro de
plazo y presupuesto.
 Aseguramiento de calidad: Implementar el plan de gestión de calidad usando las herramientas y técnicas
apropiadas, para asegurar que el trabajo se realiza de acuerdo con los estándares de calidad exigidos.
 Implementar los cambios aprobados de acuerdo al plan de gestión de cambios, para cumplir los
requisitos del proyecto.
 Implementar las acciones aprobadas para dar respuesta a los riesgos: Poner en práctica las medidas
aprobadas y las soluciones necesarias para minimizar el impacto de los riesgos del proyecto.
 Desarrollo del equipo: Maximizar el desempeño del equipo a través de liderazgo, mentoring, formación y
gestión del equipo.
 Gestionar la participación de los interesados: Comunicarse y trabajar con los interesados para satisfacer
sus necesidades/expectativas, abordar los incidentes en el momento en que ocurren y fomentar su
adecuada participación.
En la figura pueden apreciarse los principales subgrupos de ejecución:
La actividad principal de ejecución que desarrolla el director del proyecto junto con su equipo de gestión está
representada por el proceso 4.3 Dirigir y Gestionar el Trabajo del Proyecto, que consiste en liderar y llevar a
cabo el trabajo definido en el plan para la dirección del proyecto, así como de implementar los cambios
aprobados, con el fin de alcanzar los objetivos del proyecto. Siendo muy importante, esta actividad no es la parte
central de la ejecución. El buen desempeño depende del trabajo que haga el equipo: si no son buenos o no
trabajan bien en equipo, por mucho que se empeñe el director del proyecto, el proyecto será un fracaso. En la
ejecución tampoco es lo más importante asegurar la calidad y efectuar las adquisiciones, pues el éxito de estas
actividades viene determinado por una buena planificación. ¿Qué tiene más importancia en la ejecución?
Comunicar. Liderar.

En el Corazón de la Ejecución: Comunicar el 90% del tiempo

Los directores de proyectos conceden mucha importancia a la comunicación. PMI nos
recuerda que “más de un 90% del tiempo hay que dedicarlo a comunicar”. Es decir, casi
todo el tiempo, un Director de proyectos debe dedicarse a redactar e-mails, informes,
memorandos y otros documentos, revisar, distribuir y almacenar dicha documentación, etc.
Pero hay que tener en cuenta que la comunicación no es sólo por escrito: el mayor
porcentaje del tiempo se invierte en llamadas, chats, videoconferencias, presentaciones,
reuniones con el equipo, con la organización solicitante, con los jefes y resto de
interesados, con cada miembro del equipo para orientarle y darle realimentación, por no
mencionar la comunicación informal que tiene lugar en los pasillos, en el comedor, frente a
la máquina del café, etc.
Los seres humanos nos distinguimos de los animales en muchos aspectos, por supuesto, pero quizá sea uno de
los más relevantes nuestra necesidad de comunicarnos, sobre todo cuando hay algo que nos inquieta
especialmente porque lo vemos como un peligro, o un cambio sustancial. Para los interesados, un proyecto recae
en esta categoría de elementos preocupantes y desestabilizadores: Cuando tenemos “hambre de información”,
nos ponemos en lo peor, pensamos que algo va mal. Nunca faltan las propias experiencias pasadas, rumores y
malentendidos, para alimentar nuestras expectativas negativas y peores temores. La información es poder, pero
no es ético (ni eficaz) ocultar información para evitarnos problemas. Tampoco hay que tener miedo a dar malas
noticias. Ningún interesado opinará que somos eficaces si nuestra comunicación no es clara, concisa, completa,
oportuna, relevante, concluyente, predecible, fiable, confidencial, etc.
En los proyectos, es bueno imaginar al grupo de interesados como si fueran “bocas que alimentar”. Hasta que el
equipo no genere algún entregable, lo único que hay para ofrecerles, es comunicación. Los interesados son
"informívoros", necesitan “comer información”, pero sus necesidades varían: La PMO necesitará informes
semanales muy completos, el departamento de producción necesitará informes mensuales sobre costes
incurridos, desviaciones, pronósticos, etc. En cualquier caso, cuando sentamos a un “informívoro” (interesado) en
una mesa de nuestro restaurante (nuestro proyecto), hay que satisfacer sus necesidades únicas:
 Hay que preguntarles qué desean tomar, o lo que es lo mismo: acordar con ellos sus requisitos de
comunicación, qué necesitan saber del proyecto y en qué formato.
 Hay que decirles cuándo tendrán que esperar, y tomar esto como una promesa firme que cumplir. En los
proyectos, hay que planificar la comunicación indicando, por ejemplo, que habrá un informe de
seguimiento semanal que se comunicará por e-mail. No hay nada más frustrante para los interesados que
la comunicación sea esporádica e impredecible. Seguir el plan de comunicación es eficaz porque ahorramos
que nos hagan muchas preguntas (ya saben que las respuestas vendrán cuando se ha prometido).
 Si queremos que vuelvan, tenemos que preguntarles si la comida les ha gustado, esto es, obtener
realimentación regular de los interesados sobre el proceso de comunicación.

Los procesos relacionados con “ejecutar la comunicación” pertenecen a dos áreas de conocimiento: gestión de las
comunicaciones y gestión de los interesados:
 10.2 Gestionar las Comunicaciones: Crear, recopilar, distribuir, almacenar, recuperar y realizar la
disposición final de la información del proyecto de acuerdo con el plan de gestión de las comunicaciones.
 13.3 Gestionar la Participación de los Interesados: Comunicarse y trabajar con los interesados para
satisfacer sus necesidades/expectativas, abordar los incidentes en el momento en que ocurren y fomentar la
participación adecuada de los interesados en las actividades del proyecto a lo largo del ciclo de vida del
mismo.

En el Corazón de la Ejecución: Liderar al Equipo

Como director de proyectos, usted debe saber que depende totalmente de
su equipo. Usted no debe hacer el trabajo, sino dirigir el trabajo, se parece a
un director de orquesta. Es el equipo quien realmente hace el trabajo del
proyecto, usted dice quién debe hacer qué y cuándo. Al principio, quizá
deba realizar algunas tareas, orientar estrechamente a su gente, pero la
aspiración es que al final se consolide un equipo sinérgico y autosuficiente
en el que pueda delegar todos los trabajos para centrarse en la pura
gestión.
Que aparezca un equipo sinérgico es algo que no se puede garantizar. Usted no hace que ocurra, más bien deja
que ocurra. Es algo que depende de ellos. Como director de proyectos, usted no puede hacer proactivamente que
un equipo se forme. No deberíamos usar la expresión “team building”: no es como poner ladrillos y finalmente se
"construye" un equipo. Más adecuada sería la expresión “team growing”: podemos regar la planta, es decir,
proporcionarles la visión sobre los objetivos del proyecto, quitar impedimentos, mejorar sus condiciones de
trabajo, coubicarles en una sala bien equipada, evitarles interrupciones y distracciones innecesarias, etc. Haciendo
todo esto, usted solo puede "esperar" que el equipo se forme, pero también podría ocurrir que no encajen,
depende solo de ellos. Usted podrá minimizar las probabilidades en contra, pero no podrá hacer positivamente
que el equipo se forme. El proceso es tan frágil que no puede ser controlado.
Por supuesto, si un miembro del equipo no encaja, usted deberá reemplazarle por otro. Pero una vez que usted
decide que no habrá más cambios, que ese es su equipo de proyecto, su mejor táctica es confiar en ellos. Como
director de proyectos, debe saber que no puede protegerse ante la incompetencia de su propio equipo. Es decir,
si los miembros del equipo no tienen la suficiente preparación, o no están orientados a resultados, o simplemente
no se entienden o no se llevan bien, entonces tenga la seguridad de que no se conseguirán los objetivos, y en
consecuencia el proyecto será un fracaso haga lo que haga usted. El director de proyectos no es nada sin su
equipo, pero si su equipo no está capacitado para realizar el proyecto, inevitablemente fracasará.
¿Qué es lo único que se puede hacer para sembrar equipo, aparte de cruzar los dedos? Aplicar un liderazgo basado
4
en principios. Un líder eficaz debería ejercer los cuatro roles del liderazgo :
 Modelar: Ser un modelo de integridad, una referencia para los demás, inspirar confianza.
 Buscar caminos: No imponer la forma de hacer las cosas, sino considerar las sugerencias y
recomendaciones de los demás, encontrar terceras vías con ellos para que se identifiquen emocionalmente.
 Alinear: Implantar procesos, estructuras, sistemas, con el fin de homogeneizar los trabajos a nivel
organizativo.
 Facultar: Delegar los trabajos en las personas, conforme a sus capacidades, para permitirles madurar
profesionalmente y que encuentren su propia voz.
4 El Liderazgo Centrado en Principios, Stephen R. Covey, Ed. Paidós Ibérica, 1993.

El liderazgo de equipos es un área tan amplia que no puede desarrollarse completamente en la Guía del
PMBOK®. Aun así, el director de proyectos puede encontrar una buena orientación sobre las principales
actividades en los procesos de ejecución de recursos humanos.
 9.2 Adquirir el Equipo del Proyecto: Confirmar la disponibilidad de los recursos humanos y conseguir el
equipo necesario para completar las actividades del proyecto.
 9.3 Desarrollar el Equipo del Proyecto: Mejorar las competencias, la interacción entre los miembros del
equipo y el ambiente general del equipo para lograr un mejor desempeño del proyecto.
 9.4 Dirigir el Equipo del Proyecto: Realizar el seguimiento del desempeño de los miembros del equipo,
proporcionar realimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del
proyecto.
Simplificando mucho, las actividades de ejecución que tienen que ver con los
recursos humanos del proyecto consisten en incorporar a las personas necesarias
para trabajar en el equipo del proyecto (9.2), facilitar en la medida de lo posible que
se formen como equipo proporcionándoles formación, infraestructura, visión, etc.
(9.3) y finalmente gestionar conflictos y corregir el mal desempeño (9.4). El proceso
9.2 es quizá uno de los más importantes para el director del proyecto, pues aún
queda en su zona de control proponer, exigir, o negociar que las personas idóneas
formen parte del equipo. A partir de entonces depende de ellos que acaben siendo
un equipo sinérgico y cohesionado. Desde fuera solo podemos estimular, facilitar,
orientar, guiar (9.3) o bien que corregir el mal desempeño ejerciendo nuestra
autoridad. En el peor de los casos, a veces podemos tener que prescindir de alguna
persona que no encaje (solicitamos un cambio para prescindir o reemplazar a un
miembro del equipo).

Ejecutar la Calidad y las Adquisiciones
 8.2 Realizar el Aseguramiento de Calidad: Auditar los requisitos de calidad y los resultados de las
mediciones de control de calidad, para asegurar que se utilicen las normas de calidad y las definiciones
operacionales adecuadas.
 12.2 Efectuar las Adquisiciones: Obtener respuestas de los vendedores, seleccionarlos y adjudicarles un
contrato.

3.4. Grupo de Procesos de Monitorización y Control

El hábito de conseguir que las cosas se hagan (Getting Things Done),
en gestión de proyectos significa hacer cumplir la planificación. Esta
planificación, a su vez cambiante, hay que mantenerla actualizada.
Hay muchos elementos de la planificación que no se pueden medir
cuantitativamente, pero en lo que podemos medir, nuestra
responsabilidad es cuantificar la distancia entre lo que debería ocurrir
y lo que está ocurriendo. En nuestra profesión, la expresión
cuantitativa de lo que debería ocurrir se denomina línea base. Hay
muchas formas de medir cuantitativamente el desempeño de un
proyecto, pero medir no es lo mismo que controlar.
Controlar significa limitar la distancia entre lo que debería estar ocurriendo y lo que
realmente está ocurriendo. La Guía del PMBOK® nos dice que esto se consigue
solicitando cambios, que si se aprueban supondrán implementar acciones correctivas,
preventivas, de reparación de defectos o de mejora de procesos. Utilicemos el sistema
integrado de control de cambios para lo que debe quedar por escrito, pero muchas
veces es más importante lo que no da tiempo a escribir, o no hace falta dejar por
escrito. Hacer que las cosas se hagan en los proyectos se consigue tomando la
iniciativa. Generalmente hay una zona que cae dentro del ámbito de influencia del
director de proyectos, lo que cae fuera está en su ámbito de preocupación. En nuestra
profesión, la frontera entre una zona y otra no está perfectamente delimitada en la mayoría de los casos. En
muchas ocasiones, los interesados, en beneficio del proyecto, toleran que esos límites se cuestionen y se rebasen.
Muchas veces, el director del proyecto prefiere pedir perdón a pedir permiso.
El diagrama IPECC nos permite simplificar las grandes entradas y salidas

del grupo de monitorización y control. Obsérvese que hay una flecha
desde control a ejecución (los cambios aprobados), otra flecha desde
control a planificación (las actualizaciones al plan) y otra desde control a
cierre (los entregables aceptados). Esta última flecha es muy importante,
ya que cuando todos los entregables han sido aceptados, comienza ser
posible plantear el cierre.

El equipo de dirección del proyecto realiza, entre otras, las siguientes actividades de monitorización y control:
 Medición del desempeño: Medir el desempeño del proyecto utilizando herramientas y técnicas adecuadas
para identificar y cuantificar cualquier desviación para proponer las acciones correctivas necesarias.
 Gestión de cambios: Gestionar los cambios en el alcance, cronograma y costes actualizando el plan del
proyecto y comunicando los cambios aprobados al equipo, para asegurar que los objetivos revisados se
cumplen.
 Control de calidad: Asegurar de que los entregables del proyecto se ajustan a las normas de calidad
establecidas en el plan de calidad del proyecto, para satisfacer los requisitos de la organización solicitante.
 Control de riesgos: Actualizar el registro de riesgos y el plan de respuesta a los riesgos identificando
nuevos riesgos, reevaluando los ya identificados, y determinando e implementando las estrategias de
respuesta apropiadas, para gestionar el impacto de los riesgos en el proyecto.
 Control de incidentes: Evaluar acciones correctivas en el registro de incidentes y determinar los próximos
pasos para resolver incidentes usando herramientas y técnicas apropiadas para minimizar el impacto en
plazo, coste y recursos.
 Controlar la participación de los interesados: Comunicar el estado del proyecto a los interesados para
obtener su realimentación, con el fin de asegurar que el proyecto esté alineado con sus necesidades de
negocio.
En la figura pueden apreciarse los principales subgrupos de monitorización y control:
En la figura, el subgrupo de la izquierda, controlar las líneas base, sirve para aplicar una serie de técnicas bien
conocidas que permiten calcular desviaciones y pronósticos. El subgrupo de la derecha, controlar los riesgos, la
calidad y las adquisiciones, permite mantener actualizados los riesgos, verificar la calidad de los entregables y
administrar los contratos, tareas muy importantes sin duda, pero más o menos mecánicas, al fin y al cabo. En la
parte central de la figura tenemos el subgrupo de controlar la comunicación la participación, los trabajos y los
cambios. Este subgrupo sí resulta determinante para el éxito o fracaso de los proyectos.

Controlando la Comunicación, la Participación, los Trabajos y los Cambios

Decimos que un proyecto está controlado cuando sigue unos procesos planificados y se van consiguiendo
resultados predecibles. Se va demostrando un progreso continuo en las sucesivas reuniones de seguimiento, se
van aceptando progresivamente los entregables, y cumpliendo los hitos. El equipo de dirección del proyecto
comunica adecuadamente y transmite una sensación de confianza y credibilidad al grupo de interesados sobre la
consecución final de los objetivos de alcance, plazo, coste y calidad. Por supuesto, ocurren problemas (si no, ¡no
sería un proyecto!) pero la mayoría de esos problemas se van viendo venir y hay respuestas aprobadas de
antemano por el equipo de gestión o el comité de seguimiento de alto nivel. También hay sorpresas e incidentes
imprevistos, pero son pocos y manejables.
Lo contrario a un proyecto controlado tiene muchas variantes, todos hemos vivido estas situaciones que por
desgracia son muy frecuentes, como cuando se improvisa continuamente, se avanza a salto de mata,
solucionando los problemas de forma reactiva, de crisis en crisis. A veces, el equipo de dirección del proyecto
puede resolver esta situación con un golpe de timón y el proyecto vuelve al camino. Cuando no hay una
planificación actualizada y realista, o el alcance cambia continuamente a capricho de ciertos interesados, entonces
ocurre lo que se denomina en inglés scope creep (corrupción del alcance): el peor sitio para estar si eres director de
proyectos.
Los siguientes procesos ayudan a que el proyecto comience, se mantenga y finalice bajo control:
 10.3 Controlar las Comunicaciones: Monitorizar y controlar las comunicaciones a lo largo de todo el ciclo
de vida del proyecto para asegurar que se satisfagan las necesidades de información de los interesados del
proyecto.
 13.4 Controlar la Participación de los Interesados: Monitorizar las relaciones generales de los interesados
del proyecto en general y ajustar las estrategias y los planes para involucrar a los interesados.
 4.4 Monitorizar y Controlar el Trabajo del Proyecto: Dar seguimiento, revisar e informar del avance del
proyecto con respecto a los objetivos de desempeño definidos en el plan para la dirección del proyecto.
 4.5 Realizar el Control Integrado de Cambios: Analizar todas las solicitudes de cambios; aprobar y
gestionar los cambios a los entregables, activos de los procesos de la organización, documentos del
proyecto y plan para la dirección del proyecto; y comunicar las decisiones correspondientes.

Lo que está ocurriendo en el proyecto, los hechos relevantes de la ejecución, son datos de desempeño del
trabajo que generalmente no son significativos por sí mismos, sin analizarlos no sirven para tomar decisiones.
Hay que procesar esos datos para transformar la información en bruto en información elaborada que sirva para
tomar decisiones. Si se trata de información relativa a interesados, se procesa en 13.4 Controlar la Participación
de los Interesados. El resto de información sobre comunicaciones, incidentes y hechos de desempeño, se procesa
en 10.3 Controlar las Comunicaciones. El resultado de ambos procesos es la información sobre el desempeño
del trabajo, que sirve para juzgar el estado del proyecto en 4.4 Monitorizar y Controlar el Trabajo del
Proyecto, y solicitudes de cambios que se tratarán, como el resto de cambios, en 4.5 Realizar el Control
Integrado de Cambios.
Es importante recordar cómo funcionan los dos procesos de integración en el grupo de control. En el proceso 4.4
Monitorizar y Controlar el Trabajo del Proyecto, la imagen a recordar es la del doctor que diagnostica la salud
del enfermo. Para ser eficiente, un médico no podría realizar todas las pruebas clínicas en misma consulta, sino
que necesita los resultados (análisis de sangre, bronquios, etc.) para decidir el tratamiento (medicación, cambio de
hábitos, etc.). De igual forma, en la reunión de seguimiento sobre de un determinado proyecto no es el momento
de analizar los datos del desempeño del trabajo que vienen de ejecución. Esos “datos en bruto” hay que
procesarlos, elaborarlos, prepararlos para su análisis ejecutivo, en forma de “información sobre el desempeño del
trabajo”, que se analiza en este proceso para comprobar que el proyecto está controlado o bien hay que solicitar
cambios. Por otra parte, en el proceso 4.5 Realizar el Control Integrado de Cambios se tratan
centralizadamente todos los cambios y se aprueban o rechazan.
El control de un proyecto no es una actividad individual exclusiva del director del proyecto. Hay que recordar
siempre que el director del proyecto no está solo: debe involucrar a los demás en los problemas y buscar con ellos
las soluciones. Como mínimo, el director del proyecto debe compartir la carga del control con su equipo de
gestión. Sin bien lo más efectivo es que en el proyecto se celebren reuniones periódicas de seguimiento, invitando
a los interesados clave que componen el comité de seguimiento. Estas reuniones de seguimiento tendrán una
determinada frecuencia y seguirán una agenda que hay que se diseña de antemano en el plan de comunicación y
depende de cada proyecto, pero suele ser muy habitual una agenda de tres puntos: 1) tratar logros y desviaciones
del periodo anterior; 2) cambios propuestos para corregir desviaciones, tendencias o defectos; y 3) plan de acción
para el periodo siguiente. Esta “ceremonia” se representa siguiendo el proceso 4.4 Monitorizar y Controlar el
Trabajo del Proyecto.
¿Cómo evitar el scope creep? Lo primero es que los cambios no se pidan de cualquier manera, como cuando nos
asaltan por el pasillo. Si decimos que sí a todo entonces ya no es proyecto, es otra cosa. Hay que hacer que los
interesados sigan un procedimiento planificado para solicitar los cambios y después es labor del equipo de
gestión analizarlos y priorizarlos y después se aceptan o se rechazan. En algunos casos, el director del proyecto
tendrá autoridad suficiente para aceptar o rechazar ciertas solicitudes de cambios, en otros casos será más
efectivo que los cambios se procesen por lotes, en la reunión con el comité de control de cambios.

Controlar las Líneas Base

Según la Guía del PMBOK®, una línea base es una versión aprobada de un producto de trabajo que sólo puede
cambiarse mediante procedimientos formales de control de cambios y que se usa como base de comparación. En
otras palabras, podríamos decir que la expresión cuantitativa de lo que debería ocurrir se denomina línea base. En
todo proyecto hay 3 líneas base. Línea base de alcance: ¿vamos haciendo lo que había que hacer? Línea base del
cronograma: ¿vamos en fecha, retrasados, adelantados? Línea base de costes: ¿vamos en coste, con sobrecoste, por
debajo de coste?
Hay muchas formas correctas ya inventadas para medir cuantitativamente el desempeño de un proyecto. Sin
embargo, el análisis cuantitativo no se improvisa bien. Cuando nos piden una explicación puntual sobre los
retrasos, por ejemplo, siempre podremos preparar una hoja de cálculo o una presentación
con nuestro análisis. El problema es que si tenemos que hacer esto cada semana, no nos
quedará tiempo para hacer otra cosa, y no gestionaremos el proyecto con eficacia. En la
actualidad, hay herramientas muy eficaces para planificar lo que debería ocurrir y
contrastarlo con lo que está ocurriendo realmente. Si estas herramientas se alimentan con
regularidad, analizar desviaciones no cuesta nada. Para realizar el seguimiento, es eficaz usar
las herramientas que ya existen.
El subgrupo de “Controlar las Líneas Base” incluye cuatro procesos, que pueden considerarse como los procesos
más “técnicos” que debe dominar el director de proyectos. Son las habilidades más hard y menos soft, si
queremos decirlo así. Afortunadamente, aquí hay herramientas y técnicas que han demostrado su efectividad y
hay un camino de aprendizaje muy transitado. Por desgracia para quien no domina esas técnicas, las evidencias
de poca profesionalidad suelen ser objetivas y evidentes.

En la siguiente figura se muestran los procesos dedicados a controlar las líneas base de alcance, el cronograma y
costes:
 5.5 Validar el Alcance: Consiste en formalizar la aceptación de los entregables del proyecto que se hayan
completado. El equipo ya ha verificado los entregables generados en ejecución en el proceso 8.3 Controlar
la Calidad. El siguiente paso es hacerlo llegar con la configuración adecuada al cliente (o a ciertos usuarios
representativos del cliente o la organización solicitante) con el fin de que estos entregables sean validados
mediante su inspección correspondiente. Aunque la decisión está en el tejado del cliente, no por ello el
equipo de gestión tiene que desentenderse. Al contrario: es muy importante que si los entregables son
correctos, la validación se produzca, si es posible poco a poco, a medida que se va entregando
parcialmente, de tal modo que cuando la lista completa de entregables está aceptada, el equipo de
dirección ya se puede plantear el cierre del proyecto. Como el cierre de un proyecto es una de las
actividades más importantes y distintivas en gestión de proyectos, gestionar para que se den las
condiciones de cierre no es menos importante. El proceso 5.5 Validar el Alcance, muchas veces se
complica porque los clientes son reacios a aceptar. Comunicar eficazmente con estos clientes, resolver
incidentes y conflictos, escalar los problemas a otros niveles de autoridad, etc. suelen ser actividades que
implican mucha carga de gestión.
 5.6 Controlar el Alcance: Consiste en monitorizar el estado del proyecto y del alcance del producto, y
gestionar los cambios a la línea base del alcance. Para medir el alcance se indican los porcentajes
completados sobre cada cuenta de control.
 6.7 Controlar el Cronograma: Consiste en dar seguimiento del estado de las actividades del proyecto para
actualizar el avance del mismo y gestionar los cambios a la línea base del cronograma a fin de cumplir el
plan. Para medir el cronograma se puede representar el porcentaje completado de cada actividad y
comparar las fechas de comienzo y fin reales con las planificadas.
 7.4 Controlar los Costes: Consiste en monitorizar el estado del proyecto para actualizar los costes del
mismo y gestionar posibles cambios a la línea base de costes. Para medir el desempeño de costes, se puede
comparar el presupuesto que realmente se ha ganado (conseguido, completado, producido) contra el
presupuesto previsto a la fecha y contra lo incurrido a la fecha.

Controlar los Riesgos, la Calidad y las Adquisiciones
 8.3 Controlar la Calidad: Consiste en monitorizar y registrar los resultados de la ejecución de las
actividades de control de calidad, a fin de evaluar el desempeño y recomendar los cambios necesarios. En
este proceso, el equipo inspecciona los entregables que vienen de ejecución y los someten a las pruebas
planificadas. Si pasan las pruebas entonces son entregables verificados que ya están listos para ser
validados por la organización solicitante. En este proceso también se validan los cambios, es decir: se
controlan que los cambios han sido debidamente implementados en ejecución.
 11.6 Controlar los Riesgos: Consiste en implementar los planes de respuesta a los riesgos, monitorizar los
riesgos identificados, monitorizar los riesgos residuales, identificar nuevos riesgos y evaluar la efectividad
del proceso de gestión de los riesgos a través del proyecto. La gestión de riesgos no es algo que se haga
solo al principio, solo tiene sentido gestionar riesgos si el registro de riesgos se mantiene continuamente
actualizado. La parte buena de los riesgos es que los riesgos caducan: el riesgo de que un proveedor
entregue tarde desaparece el día de la entrega, el riesgo de que el cliente no acepte un entregable
desaparece con la aceptación, al final del proyecto no hay ningún riesgo. En este proceso se lleva esa
contabilidad sobre el estado de los riesgos, con especial atención a los más importantes y urgentes, se
monitorizan y se adaptan los planes de respuesta, se revisan los riesgos y supuestos actuales y se
identifican, analizan y responden riesgos nuevos.
 12.3 Controlar las Adquisiciones: Consiste en gestionar las relaciones de adquisiciones, monitorizar la
ejecución de los contratos y efectuar cambios y correcciones según corresponda. Con ayuda de este
proceso, el equipo de dirección del proyecto controla las actividades habituales al administrar un contrato,
como son las reclamaciones, los pagos, información sobre el desempeño. Dado que en este caso el director
del proyecto no lidera el equipo que realiza los trabajos, es importante que registre toda la información
significativa ya que, en el peor de los casos, tendrá que testificar en un juicio representando a su empresa.

3.5. Grupo de Procesos de Cierre

Un director de proyectos se distingue de un director de servicios
principalmente por una razón: Lo que gestiona, es decir, el
proyecto, se termina en un momento dado. Ya desde su inicio nace
con ese objetivo: concluir antes de una fecha prefijada. Además del
objetivo temporal, hay otros objetivos no menos importantes,
como son terminar sin exceder un presupuesto, entregando una
funcionalidad determinada, consiguiendo que el producto sea
“bueno” desde el punto de vista de la organización solicitante, etc.,
pero quizá lo más distintivo de un proyecto es que empieza y
termina. Uno de los hábitos que se le pide a un director de proyectos es que comience “con el fin en la mente”.
Desde el primer día del proyecto debe visualizar el destino y el camino para llegar al mismo. Nos imaginamos
cómo será esa situación final en que los interesados “han alcanzado o superado sus expectativas” y queremos
hacer todo lo posible para llegar a ese destino. Un director de proyectos debe reconocer que el proyecto que
acaba de iniciar es una fuente de problemas que desconcertará y molestará a mucha gente que tendrá que
cambiar su forma de trabajar, en el que ocurrirán muchos problemas, conflictos, crisis inesperadas; en el que su
éxito dependerá de que un grupo de personas que no han trabajado juntas acaben siendo un equipo
cohesionado y sinérgico; en el que los contratos que su empresa firmará con terceros para que hagan ciertas
partes del proyecto podrían terminar en los tribunales, etc. Todo este “entuerto” debe deshacerlo el director del
proyecto, por tanto es muy natural que se imagine ese último día en que ocurre el cierre efectivo y por fin termina
todo: Ha convocado al patrocinador y un subconjunto representativo de interesados. Ha elaborado una
presentación que ha ensayado a conciencia. Se ha puesto su mejor traje, ha preparado la sala, el proyector, los
interesados ya han llegado, es la hora. Comienza por fin esa ceremonia llamada “presentación de fin de proyecto”,
pero en su cabeza, esta presentación tiene este otro título: “Adiós, me voy”.
Seguramente, esta forma de pensar tiene fuertes implicaciones psicológicas. ¿No resulta un poco alienante que
eso que nosotros hemos creado con tanta ilusión, “nuestro proyecto”, queramos hacerlo morir desde el primer
día? Sin embargo, esto es precisamente lo que se espera de nosotros: comenzamos, ejecutamos y cerramos
proyectos. Cuando has pasado por esto muchas veces, te acabas acostumbrando a esta última parte.
La ceremonia de cierre suele estar cargada de mensajes subliminales. Cuando yo cierro un proyecto, reconozco las
siguientes equivalencias entre lo que digo y lo que realmente quiero decir:
 Presentación de Fin de Proyecto = “Adiós, me voy”.
 Logros e hitos alcanzados = “No me queda nada por entregar y lo tengo todo aceptado”.
 La documentación del proyecto se puede acceder en esta carpeta, estas son las siguientes fases = “El
producto entra en fase de operación, ya no es un proyecto, yo no seré el responsable”.
 ¿Dudas o aclaraciones? = “Quien tenga algo que decir, que hable ahora o calle para siempre”.
La reunión de cierre es la más trascendente del proyecto. Deberá gestionarse de la

manera más efectiva. No debe convocarse si aún queda algo por hacer. Aunque esté
todo aceptado, no es suficiente. Hay que “escenificarlo” para que inequívocamente se
sepa que se ha terminado. A partir de esta reunión, los interesados ya no tienen derecho
a pedir más cambios.

El equipo de dirección del proyecto realiza, entre otras, las siguientes actividades de cierre:
 Aceptación formal: Obtener la aceptación final de los entregables del proyecto trabajando con el
patrocinador y/o la organización solicitante, para confirmar que el alcance y los entregables se han
validado.
 Transición: Transferir la propiedad de los entregables a los interesados asignados de acuerdo con el plan
del proyecto.
 Cierre administrativo: Obtener el cierre financiero, legal y administrativo usando prácticas generalmente
aceptadas, para comunicar el cierre formal y asegurar la liberación de responsabilidades futuras.
 Informe de cierre: Distribuir el informe final del proyecto incluyendo toda la información relativa al cierre,
desviaciones e incidentes, para comunicar la situación final del proyecto a los interesados.
 Lecciones aprendidas: Recopilar las lecciones aprendidas a partir de una revisión completa del proyecto,
para crear y/o actualizar la base de conocimiento de la organización.
 Dossier del proyecto: Archivar los documentos y material del proyecto, con el fin de retener el
conocimiento de la organización, cumplir los requisitos legales, y garantizar la disposición de la información
para su uso potencial en futuros proyectos e internos y auditorías externas.
 Satisfacción de la organización solicitante: Medir la satisfacción del cliente o la organización solicitante al
final del proyecto capturando su realimentación, para facilitar la evaluación del proyecto y mejorar las
relaciones con la organización solicitante.
En la figura pueden apreciarse los principales subgrupos del grupo de procesos de cierre:
 4.6 Cerrar el Proyecto o Fase: Finalizar todas las actividades en todos los grupos de procesos de la
dirección de proyectos para completar formalmente el proyecto o una fase del mismo.
 12.4 Cerrar las Adquisiciones: Finalizar cada adquisición para el proyecto.

Navegando Por La Guía Del PMBOK

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Navegando Por La Guía Del PMBOK

Cargado por

Copyright:

Formatos disponibles

3 Navegando

por la Guía del

3.1. Grupo de Procesos de Inicio ................................................................................................................85

3.2. Grupo de Procesos de Planificación..................................................................................................87

3.3. Grupo de Procesos de Ejecución ..................................................................................................... 103

3.4. Grupo de Procesos de Monitorización y Control ..................................................................... 110

3.5. Grupo de Procesos de Cierre ............................................................................................................ 117

El Director de Proyectos a Examen | 81

 La organización patrocinadora, a través de un patrocinador o bien un iniciador externo al proyecto,

82 | El Director de Proyectos a Examen

El Director de Proyectos a Examen | 83

84 | El Director de Proyectos a Examen

3.1. Grupo de Procesos de Inicio

El Director de Proyectos a Examen | 85

Así es como define los procesos de inicio la Guía del PMBOK®:

86 | El Director de Proyectos a Examen

3.2. Grupo de Procesos de Planificación

A partir del acta de constitución del proyecto y del registro de

El Director de Proyectos a Examen | 87

88 | El Director de Proyectos a Examen

En la figura pueden apreciarse los principales subgrupos de planificación:

El Director de Proyectos a Examen | 89

90 | El Director de Proyectos a Examen

En el Corazón de la Planificación: Riesgos, Calidad y Adquisiciones

El Director de Proyectos a Examen | 91

Planificar incorrectamente los Riesgos

Lo contrario a gestión de crisis se llama gestión de riesgos. La peor imagen

92 | El Director de Proyectos a Examen

Planificar adecuadamente los Riesgos

El Director de Proyectos a Examen | 93

94 | El Director de Proyectos a Examen

Planificar incorrectamente las Adquisiciones

En esta situación, el director de proyectos no controla los trabajos, sino que

Planificar incorrectamente la Calidad

El Director de Proyectos a Examen | 95

Planificar adecuadamente las Adquisiciones y la Calidad

La gestión de las adquisiciones del proyecto consiste en comprar o adquirir los

El proceso 12.1 Planificar la Gestión de Adquisiciones del Proyecto consiste en

96 | El Director de Proyectos a Examen

La gestión de la calidad del proyecto consiste en determinar

El Director de Proyectos a Examen | 97

Desarrollar la Línea Base de Alcance

98 | El Director de Proyectos a Examen

Planificar Recursos Humanos, Comunicaciones e Interesados

 La gestión de los recursos humanos del proyecto incluye los procesos

El Director de Proyectos a Examen | 99

Planificar las Actividades

100 | El Director de Proyectos a Examen

Desarrollar la Línea Base de Costes

 7.1 Planificar la Gestión de Costes: Establecer las políticas, los

 7.2 Estimar los Costes: Desarrollar una aproximación de los recursos

El Director de Proyectos a Examen | 101

Desarrollar el Plan para la Dirección del Proyecto

La gestión de la integración del proyecto incluye los procesos necesarios para

El proceso 4.2 Desarrollar el Plan para la Dirección del Proyecto consiste en

102 | El Director de Proyectos a Examen

3.3. Grupo de Procesos de Ejecución

El diagrama IPECC nos permite simplificar las grandes entradas y salidas

El Director de Proyectos a Examen | 103

En la figura pueden apreciarse los principales subgrupos de ejecución:

104 | El Director de Proyectos a Examen

En el Corazón de la Ejecución: Comunicar el 90% del tiempo

El Director de Proyectos a Examen | 105