Navegando Por La Guía Del PMBOK PDF

3
Navegando
por la Gua del
PMBOK
3.1. Grupo de Procesos de Inicio ................................................................................................................85
3.2. Grupo de Procesos de Planificacin .................................................................................................87
3.3. Grupo de Procesos de Ejecucin..................................................................................................... 103
3.4. Grupo de Procesos de Monitorizacin y Control ..................................................................... 110
3.5. Grupo de Procesos de Cierre ............................................................................................................ 117
3. Navegando por la Gua del PMBOK
Para cada uno de los 47 procesos, la Gua del PMBOK describe una serie de entradas, salidas, herramientas y
1
tcnicas. En total, se contabilizan 409 entradas y salidas y 209 herramientas y tcnicas . Por otra parte, los 47
procesos tienen muchas relaciones y son interdependientes (algunas herramientas y tcnicas se resan 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 lgico de las actividades de gestin 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 mtodo de representacin
basado en el estndar IDEF0. IDEF0 es un mtodo sencillo de especificacin formal de procesos, que permite la
descomposicin de procesos a travs de un anlisis descendente (top-down).
El estndar IDEF0 se ha adaptado en este libro con los siguientes convenios de representacin:
Las cajas representan los procesos elementales (nivel ms bajo de detalle, con una marca en la esquina
superior izquierda) y tambin los grupos de procesos que tenga sentido agrupar a este nivel, y que sern
detallados en niveles inferiores.
Las flechas entrantes a las cajas por el lado izquierdo representan las entradas (documentos, informacin,
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 tcnicas.
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 descomposicin inferior. Para
favorecer la simplicidad de la representacin, a veces las flechas aparecen en la descomposicin y no en el
diagrama superior (esto se marca con un parntesis sobre la flecha, o tnel). Tambin por simplicidad en la
representacin, 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 estndar de modelado de procesos IDEF0 permite obtener una
visin dinmica de los procesos, sus detalles y sus dependencias. En el enlace http://goo.gl/5bKXzl puede
descargar un fichero PDF titulado Navegador de la Gua 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. Tambin podr acceder a ciertos ejercicios sobre los procesos representados en cada diagrama.
Vase el anexo II con la enumeracin completa de entradas, salidas, herramientas y tcnicas para cada proceso.
La Gua del PMBOK no distingue entre herramientas y tcnicas. En los diagramas se han ubicado como herramientas las que pueden ser
automatizadas. Por ejemplo: observaciones podra ser una tcnica, o bien una herramienta si se automatizan con grabaciones por vdeo.
2
El Director de Proyectos a Examen | 81
De esta manera, una visin de alto nivel de la gestin de proyectos puede representarse de esta forma:
La organizacin patrocinadora, a travs de un patrocinador o bien un iniciador externo al proyecto,

solicita la realizacin 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 organizacin ejecutora aprueba el proyecto, finalmente se observar que se entrega formalmente un

producto, servicio o resultado final a la organizacin 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 Gua del PMBOK es precisamente una serie de buenas prcticas
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 organizacin ejecutora y por tanto ha de tener en cuenta los factores de
contorno (factores ambientales de empresa) y los artefactos de gestin escritos o normativa obligada
(activos de procesos de la organizacin).
El equipo de direccin del proyecto comienza generalmente por identificar a los interesados y documentar
los requisitos de la organizacin solicitante.
Cuando la organizacin ejecutora no realiza todo el alcance el proyecto, sino que subcontrata una o varias
partes a proveedores, estos presentarn sus mejores propuestas. Y la organizacin ejecutora determinar
los proveedores seleccionados. La relacin con estos proveedores durante el proyecto se administrar
generalmente a travs los correspondientes contratos.
82 | El Director de Proyectos a Examen
Si se baja a un nivel mayor de detalle, puede apreciarse cmo se resuelven las entradas y salidas a travs de los
3
cinco grupos de procesos :
Inicio:
A partir de la informacin de contexto sobre la caso de negocio, el acuerdo y/o el enunciado del
trabajo, si se aprueba el proyecto, se genera el acta de constitucin del proyecto, documento que
sirve para autorizar oficialmente el proyecto dentro de la organizacin ejecutora, nombrando al
director de proyectos, y otorgndole el nivel de autoridad para utilizar los recursos de la
organizacin. La otra actividad inicial no menos importante es la obtencin de la informacin
relevante sobre los distintos interesados. Es buena prctica recomendada que el director del
proyecto est presente antes de la aprobacin del proyecto para que ayude a integrar toda la
informacin generada en el debate que ha mantenido la organizacin sobre si hacer o no el
proyecto, y para que ayude a elaborar el acta de constitucin, destacando la informacin clave para
justificar el proyecto y reclamando por escrito su nivel de autoridad.
Planifica- A partir del acta de constitucin del proyecto y el registro de interesados, siguiendo los 24
cin:
procesos de planificacin, se acaba produciendo el documento maestro para la ejecucin y el control

del proyecto: el plan para la direccin del proyecto. Entre otra mucha documentacin importante,
tambin se puede generar, si el proyecto requiere la concurrencia de proveedores externos a la
organizacin ejecutora, la documentacin necesaria para efectuar las adquisiciones. En este grupo
de procesos el director de proyectos debe usar su potente imaginacin, como si fuera un orculo, o
un adivino con su bola de cristal, para visualizar el futuro del proyecto: qu habr que hacer y qu no,
cunto durar, cunto costar, cmo generar un producto que logre la satisfaccin del cliente o la
organizacin solicitante, quin deber formar parte del equipo, qu comunicar a quin, cundo y en
qu forma, cmo anticiparse a los problemas, qu hay que adquirir a terceros y qu estrategia hay
que seguir con los principales interesados.
Obsrvese que el grfico 3-3 de la pgina 53 de la Gua del PMBOK contiene bsicamente la misma informacin.
Ejecucin:
El director del proyecto dirige el trabajo definido en el plan del proyecto y la implementacin de las
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 desempeo para su posterior anlisis. Su objetivo es hacer que las cosas
se hagan, buscando ms 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 meloda del
proyecto. Cuando algo no ocurre como esperaba (p.ej., un violinista desafina) no se para la msica,
simplemente se emite una solicitud de cambio para su posterior evaluacin y anlisis.
Monito- El equipo del proyecto verifica que los entregables son correctos y el director del proyecto gestiona
rizacin
y
Control:
Cierre:
la entrega y persigue la aceptacin por parte del cliente o la organizacin solicitante. A partir de los
datos de desempeo del trabajo, se juzga si el proyecto progresa adecuadamente, en fecha, en
coste y si no es as se solicitan cambios para volver a las lneas base. Con ayuda de su equipo ncleo
y del comit de control de cambios, el director del proyecto gestiona integradamente los cambios
(que se solicitan en la ejecucin o como resultado de la monitorizacin y control) para procesarlos en
bloque y atendiendo a su prioridad relativa. En este grupo de procesos, podramos decir que el
director de proyectos se parece al mdico que vigila el estado de salud del proyecto, evala los
progresos y propone acciones para conseguir que se cumplan los objetivos.
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 organizacin
ejecutora debe cerrar formalmente el contrato y as concluye la relacin contractual y la
responsabilidad legal de ambas partes.
Lo que viene a continuacin es una descripcin de los procesos de gestin de un proyecto, desde su inicio hasta
su cierre, a travs de los cinco grupos de procesos, navegando por la Gua del PMBOK.
3.1. Grupo de Procesos de Inicio

En cualquier organizacin, ya sea orientada a proyectos, matricial o funcional, la decisin
de lanzar un proyecto no debe tomarse a la ligera. Antes de comprometer recursos y
presupuesto, es preciso un anlisis 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 decisin fundada sobre la necesidad de continuar, posponer o cancelar el
proyecto.
El equipo de direccin del proyecto realiza, entre otras, las siguientes actividades de inicio:
Estudio de viabilidad: Realizar la valoracin del proyecto sobre la base de la informacin disponible y
reuniones con el patrocinador, el cliente o la organizacin 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 organizacin solicitante del proyecto.
Anlisis de interesados clave: Realizar el anlisis de los interesados clave usando tormenta de ideas,
entrevistas y otras tcnicas de recopilacin de informacin, 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, informacin histrica y juicio de expertos, para identificar las limitaciones del proyecto y
proponer un enfoque de implementacin.
Acta de constitucin del proyecto: Desarrollar el acta de constitucin del proyecto analizando con mayor
profundidad los requisitos de los interesados para cumplir el alcance del proyecto, hitos y entregables.
Obtener la aprobacin del acta de constitucin del proyecto por parte de la organizacin patrocinadora y la
organizacin solicitante (si es necesario), para formalizar la autoridad asignada al director del proyecto y
conseguir el compromiso y la aceptacin del proyecto.
En la figura pueden apreciarse las principales entradas, salidas, herramientas y tcnicas, del grupo de procesos de
inicio:
A partir de la informacin de contexto sobre la necesidad del proyecto, se genera el acta de constitucin del
proyecto. La otra actividad inicial no menos importante es la elaboracin de un registro de interesados con la
informacin relevante sobre su posicin respecto al proyecto, poder, inters, conocimiento, accesibilidad, etc.
Durante el inicio del proyecto, hay que contemplar a la vez dos reas de conocimiento: La gestin de la
integracin (para resumir todo el debate organizativo de la alta direccin, expertos en la materia, estudios de
viabilidad, planes de negocio, etc. en un documento llamado acta de constitucin del proyecto) y la gestin de
los interesados (para identificar a los mismos).
As es como define los procesos de inicio la Gua del PMBOK:
4.1 Desarrollar el Acta de Constitucin 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 organizacin ejecutora a las actividades del proyecto.
13.1 Identificar a los Interesados: Identificar a las personas, grupos u organizaciones que podran ejercer
o recibir el impacto de una decisin, actividad o resultado del proyecto, as como de analizar y documentar
informacin relevante relativa a sus intereses, participacin, interdependencias, influencia y posible impacto
en el xito del proyecto.
3.2. Grupo de Procesos de Planificacin

En su da a da, 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 acabarn 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
gestin de proyectos, significa algo muy concreto: planificar. Una buena
planificacin es clave para el xito de cualquier proyecto (como se dice en ingls,
fail to plan is plan to fail, que podra 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 da a da, de verdad podemos llamar a eso gestionar un proyecto? Un director de proyectos que no
tiene el hbito de planificar causa muy mala impresin. 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 reunin 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 informacin disponible y con un margen de error aceptable,
aspectos tan importantes como qu hay que hacer y qu no, cunto esfuerzo supondr el proyecto, cunto
costar, cundo terminar, cmo se sabr si el producto final es bueno o malo, qu tipo de recursos se
necesitarn, cuntos y cundo, quin debe comunicarse con quin y cmo, cules son los potenciales problemas
que pueden ocurrir, qu partes habr que contratar a proveedores, etc.
El grupo de procesos de planificacin es sin duda el ms importante de la Gua del PMBOK, como lo demuestra
el hecho de que, de los 47 procesos, 24 pertenecen a este grupo. Simplificando mucho, podramos decir que un
director de proyectos es un especialista en planificar lneas base, para despus controlar las desviaciones durante
la ejecucin (y el resto son habilidades interpersonales). Si algo distingue a los proyectos de las operaciones, en
cuanto al grado de gestin que requiere un proyecto, es la necesidad de ceirse a un calendario, a un
presupuesto y a un alcance predeterminados, y todo esto ha de planificarse meticulosamente.
A partir del acta de constitucin del proyecto y del registro de

interesados, siguiendo los 24 procesos de planificacin, se acaba
produciendo un documento maestro para la ejecucin y el control del
proyecto, denominado plan para la direccin del proyecto. En la
mayora 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 informacin. Entonces se dice que se practica una planificacin gradual. En
cualquier caso, la re-planificacin est presente cuando se decide aprobar cambios que afectan al plan (ntese la
flecha de realimentacin desde control a planificacin del diagrama IPECC). Tambin hay realimentacin de
control a planificacin cuando se producen actualizaciones en los documentos del proyecto o se aprueban
cambios.
El equipo de direccin del proyecto realiza, entre otras, las siguientes actividades de planificacin:
Requisitos: Evaluar detalladamente con los interesados requisitos, restricciones y supuestos a partir del
acta de constitucin del proyecto, lecciones aprendidas de proyectos previos y el uso de tcnicas de
recopilacin de requisitos, para determinar los entregables del proyecto.
EDT: Crear una EDT con el equipo, descomponiendo el alcance para su mejor gestin.
Presupuesto: Desarrollar un presupuesto a partir del alcance del proyecto usando tcnicas de estimacin.
Cronograma: Desarrollar un cronograma del proyecto a partir de los plazos marcados, el alcance y los
recursos, para gestionar la conclusin en plazo del proyecto.
Recursos Humanos: Desarrollar un plan de gestin de recursos humanos definiendo los roles y
responsabilidades del los miembros del equipo del proyecto para crear una estructura organizativa efectiva
y dirigir la utilizacin y la gestin de los recursos.
Comunicacin: Desarrollar un plan de comunicacin a partir de la estructura organizativa del proyecto y los
requisitos de los interesados externos, para gestionar el flujo de informacin del proyecto.
Adquisiciones: Desarrollar un plan de adquisiciones a partir del alcance y el cronograma, para asegurar que
los recursos requeridos estarn disponibles.
Calidad: Desarrollar un plan de gestin de calidad a partir del alcance y los requisitos, para prevenir
defectos y reducir el coste de la calidad.
Cambios: Desarrollar un plan de gestin de cambios definiendo cmo los cambios sern gestionados
asegurando su trazabilidad.
Riesgos: Planificar la gestin 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
aprobacin para ejecutar el proyecto.
Kick-off: Realizar una reunin de lanzamiento para anunciar el comienzo del proyecto, comunicar los hitos
y compartir la informacin relevante.
En la figura pueden apreciarse los principales subgrupos de planificacin:
Los 24 procesos de planificacin pueden agruparse en tres subgrupos: 1) procesos obligatorios; 2) procesos
opcionales; y 3) procesos para cerrar la planificacin.
El primer subgrupo contiene la planificacin del alcance (qu hay que hacer y qu no, y cmo se
descompone el esfuerzo del proyecto), los recursos humanos (quin debe hacerlo y cmo hay que
organizar el equipo), los interesados (para quin ser el producto del proyecto y cmo hay que gestionar
sus expectativas y su participacin), las comunicaciones (quin debe comunicarse con quin, cmo y
cundo) y los tiempos (cundo 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 atencin 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 financiacin. Tambin tenemos la
planificacin de los costes (cunto costar el proyecto y cundo se ir consumiendo el presupuesto). Y por
ltimo, hay que compilarlo todo en el documento plan para la direccin del proyecto.
El segundo bloque est colocado, a propsito, en el centro. Estos procesos estn en el corazn de la planificacin
porque muchos proyectos fracasan por planificar incorrectamente los riesgos (qu tenemos derecho a creer y
qu no), las adquisiciones (cmo 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 organizacin 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 anlisis de riesgos y de la
planificacin de la respuesta a los mismos. El resultado principal de planificar la calidad es el plan para la gestin
de la calidad, que describe cmo se implementarn las polticas de calidad para garantizar que se trabajar
correctamente y para controlar que los resultados que se obtendrn sern correctos. De planificar las
adquisiciones resulta el plan para la gestin de las adquisiciones, que describe cmo el equipo de proyecto
adquirir bienes y servicios desde fuera de la organizacin ejecutora.
En el Corazn de la Planificacin: 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
organizacin solicitante como la organizacin 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 debera haber terminado en quince
meses y dura ms de veinte, porque acumula unas prdidas netas de cientos de miles de euros, o porque el
cliente no acepta las entregas y por tanto no paga.
Cuando se hace un anlisis post-mortem de un proyecto que ha fracasado, muchas veces descubrimos que la
causa principal se origin aguas arriba, al realizar planificacin. Cuando un proyecto fracasa estrepitosamente
por razones de planificacin, generalmente no es por haber programado errneamente el cronograma o
estimado incorrectamente los costes: no somos tan malos estimando. Tampoco hay que buscar la causa en
planificar errneamente las comunicaciones o la gestin de recursos humanos: estas reas son muy
importantes, pero su papel es decisivo durante la ejecucin, ms que en la planificacin.
Siendo tambin 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 razn y ms importante es que, aunque no se haga bien, esto es: no gestionemos bien los
requisitos, no documentemos bien las inclusiones, exclusiones, la descripcin 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 gestin del riesgo. Otras veces hay que
asumir una gran cantidad de retrabajo para que la organizacin solicitante acepte los entregables. Esto se
explica mejor desde la perspectiva de gestin de la calidad.
En general, podemos decir que un proyecto fracasa desde la planificacin cuando se planifican mal estas tres
reas de conocimiento: riesgos, calidad y adquisiciones. Podramos 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
cancelacin. Nos convencemos a nosotros mismos de que estamos gestionando riesgos porque tenemos una lista
de riesgos y la vamos repasando en cada reunin 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 rales, pero no vemos el tren que se acerca.
Algunos casos que ilustran esos riesgos del tipo tren que se acerca:
Un proyecto de consultora de ayuda al desarrollo de pequeas y medianas empresas de Egipto financiado

por el gobierno, tuvo que cancelarse en marzo de 2011, despus de las revueltas que derrocaron a Hosni
Mubarak. Los miembros del comit de direccin de Madrid se vieron sorprendidos por la cancelacin.
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 direccin del proyecto,
que siempre asumi que nuestra responsabilidad quedaba restringida al plano tcnico.
Otro caso, todo un clsico en gestin de riesgos, es el caso del aeropuerto de Denver, que tuvo que esperar
15 meses para empezar a operar (lo que supuso unas prdidas de 500 M$) debido al retraso inesperado en
la entrega del sistema software que gestionaba el equipaje de los viajeros.
Lo contrario a gestin de crisis se llama gestin de riesgos. La peor imagen

que puede proyectar un director de proyectos es cuando ocurre un desastre y l
no lo tena previsto, y se le ve nervioso, improvisando, alarmando a todos,
pulsando el botn 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
tena 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, tendramos que
anticiparnos con estas actividades. Si finalmente ocurre el problema, tendramos que prepararnos para ejecutar estas
otras actividades de forma eficaz. La frase tenemos derecho a creer? es la llave para abordar con madurez la
gestin de riesgos.
Planificar adecuadamente los Riesgos

La gestin 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 ejecucin del proyecto, pues los factores
que definen y afectan a los riesgos cambian continuamente. Fundamentalmente
hay que monitorizar los indicadores de transicin, o disparadores, pero adems
es necesario que el proceso de identificacin contine, por si aparecen nuevos
riesgos (lo que requerir replanificacin), y tambin hay que monitorizar cundo
expiran.
Los tres grandes pasos para planificar los riesgos son: 11.1 Planificar la Gestin de los Riesgos (definir cmo
realizar las actividades de gestin de riesgos de un proyecto), analizar los riesgos (lo que produce un registro de
riesgos con toda la informacin 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 planificacin de los riesgos del
Proyecto son el plan de gestin de los riesgos y el registro de riesgos.
A continuacin 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
caractersticas.
11.3 Realizar el Anlisis Cualitativo de Riesgos: Priorizar los riesgos para anlisis o accin posterior,
evaluando y combinando la probabilidad de ocurrencia e impacto de dichos riesgos.
11.4 Realizar el Anlisis Cuantitativo de Riesgos: Analizar numricamente 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 sera 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 capacitacin, de transferencia de riesgos, etc., a veces no hay ms remedio que
contratar como servicio un proyecto que hacen otros, para integrar sus resultados en nuestro proyecto.
En esta situacin, el director de proyectos no controla los trabajos, sino que

administra el contrato. Acta desde la parte cliente y espera los entregables
para aceptarlos, cuando quiz ya es demasiado tarde para influir. Cuando hay
conflictos, no tiene una posicin de mucho poder para negociar,
generalmente debe acudir a la direccin 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 declaracin
representando a su empresa.
Planificar incorrectamente la Calidad

El efecto de satisfaccin 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 aceptacin, y hay que disear
los procesos de aseguramiento y control de calidad que para que sea ms
probable que dichos criterios de aceptacin 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
habrn 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 reparacin no lograrn niveles
aceptables de calidad percibida. El da de la puesta en produccin ser imposible reducir los defectos a un nivel
aceptable para el cliente. Si se pudiera medir el riesgo del proyecto, comprobaramos que se acumula mucha
exposicin hasta el da 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 percepcin de
calidad, pero no hasta llegar al nivel de superar los criterios de aceptacin.
Planificar adecuadamente las Adquisiciones y la Calidad
La gestin de las adquisiciones del proyecto consiste en comprar o adquirir los

productos, servicios o resultados requeridos a terceros ajenos a la organizacin.
El proceso 12.1 Planificar la Gestin de Adquisiciones del Proyecto consiste en

documentar las decisiones de adquisiciones del proyecto, especificar el enfoque e
identificar a los proveedores potenciales. La salida ms importante de este proceso
es el plan de gestin de las adquisiciones.
Cuando un director de proyectos ha sufrido una mala relacin 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
desempeo, 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 clusulas, 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 adems 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 desempeo.
La gestin de la calidad del proyecto consiste en determinar

responsabilidades, objetivos y polticas 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 aceptacin del cliente.
Despus se planifica la calidad (estndares y mtodos aplicables), y a
continuacin, con el proyecto en marcha, se asegura que el proceso cumple los
estndares y se controla que los productos tienen los niveles de calidad
prefijados. El proceso 8.1 Planificar la Gestin de Calidad consiste en identificar los requisitos y/o estndares 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 ms importante de este proceso es el plan de gestin de la
calidad.
Tomemos de nuevo el ejemplo del proyecto de desarrollo de software en el que no se produca ninguna entrega
hasta el mes siete. Imagine ahora que practica un modelo de ciclo de vida iterativo-incremental. Observe cmo
mejora la gestin de expectativas del cliente.
En cada iteracin se construye algo que se puede probar, reparar y ensear al cliente. La calidad percibida va
creciendo desde el principio, y los niveles de riesgo se mantienen controlados. En la quinta iteracin se hace una
entrega formal y una parte del sistema que ya puede usar. En la figura puede observarse que hay previstas cuatro
entregas ms: 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
realimentacin. Es muy probable que reformule algunos requisitos, que diga eso est bien, pero y a
continuacin una serie de elementos que quiere cambiar. Cuando en la siguiente entrega el equipo entregue lo
que haba 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 ms importante, ms complejo,
de ms riesgo, o valor. Se deja para el final la funcionalidad secundaria. De esta manera, si el proyecto se cancela,
o se adelanta la fecha lmite, pueden entregarse partes con valor para el cliente. Desde las primeras entregas
(prototipos, pruebas de concepto, subsistemas funcionales, etc.) los usuarios ofrecen su realimentacin 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 Lnea Base de Alcance

La gestin 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 caractersticas y funciones
especificadas. La gestin del alcance se refiere a los trabajos del proyecto (qu hay que hacer y qu no) y tambin
al producto (qu caractersticas y funciones debe incorporar y cules no). La validacin del alcance del producto
se mide contra los requisitos. La validacin del alcance del proyecto se mide contra la lnea base del alcance.
Una buena planificacin del alcance servir para orientar al director del proyecto en la toma de decisiones a la
hora de decidir aadir o quitar trabajos, y al controlar qu est incluido y qu no, tanto en el proyecto como en el
producto. La planificacin del alcance comprende los siguientes procesos:
5.1 Planificar la Gestin del Alcance: Crear un plan para la

gestin del alcance que documente cmo 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 descripcin 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 ms pequeos y fciles de manejar.
La lnea base del alcance es la versin aprobada del enunciado del alcance, la EDT, y el diccionario de la EDT. La
lnea base del alcance se utiliza como base de comparacin entre el trabajo que se est ejecutando realmente y lo
que se debera ejecutar. Slo puede cambiarse a travs de procedimientos formales de control de cambios.
Planificar Recursos Humanos, Comunicaciones e Interesados
La gestin 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 Gestin de Recursos Humanos consiste en identificar y
documentar los roles dentro de un proyecto, las responsabilidades, las
habilidades requeridas y las relaciones de comunicacin, as como de crear
un plan para la administracin de personal.
La gestin de las comunicaciones del proyecto incluye los procesos necesarios para
garantizar la oportuna y adecuada recopilacin, creacin, distribucin, almacenamiento,
recuperacin, gestin, control, monitorizacin y disposicin final de la informacin del
proyecto. El proceso 10.1 Planificar la Gestin 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 informacin de los interesados y de los activos de la
organizacin disponibles.
La gestin 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 gestin adecuadas para lograr la
participacin eficaz de los interesados en las decisiones y en la ejecucin
del proyecto. El proceso 13.2 Planificar la Gestin de los Interesados
consiste en identificar a las personas, grupos u organizaciones que podran
ejercer o recibir el impacto de una decisin, actividad o resultado del proyecto, as como de analizar y
documentar informacin relevante relativa a sus intereses, participacin, interdependencias, influencia y
posible impacto en el xito del proyecto.
Planificar las Actividades
La gestin del tiempo del proyecto incluye los procesos necesarios para gestionar la conclusin en plazo del
proyecto. La planificacin del tiempo comprende los siguientes procesos:
6.1 Planificar la Gestin del Cronograma: Establecer las polticas, los

procedimientos y la documentacin necesarios para planificar, desarrollar,
gestionar, ejecutar y controlar el cronograma del proyecto.
6.2 Definir las Actividades: Identificar y documentar las acciones especficas

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 Duracin 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 programacin 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 informacin de las actividades para elaborar un
cronograma ajustado a los objetivos del proyecto.
Desarrollar la Lnea Base de Costes
La gestin 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 planificacin de los costes comprende los siguientes procesos:
7.1 Planificar la Gestin de Costes: Establecer las polticas, los

procedimientos y la documentacin necesarios para planificar, gestionar,
ejecutar el gasto y controlar los costes del proyecto.
7.2 Estimar los Costes: Desarrollar una aproximacin 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 lnea base de coste autorizada.
Desarrollar el Plan para la Direccin del Proyecto
El ltimo proceso de planificacin 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 programacin del proyecto. Al alimentar el cronograma con la duracin de las actividades es muy probable
que se obtenga un plazo superior a la fecha lmite. Tras aplicar una serie de alternativas y tcnicas de compresin
(o de renegociar las restricciones, por ejemplo aumentando el presupuesto) se consigue ajustar el cronograma a
las necesidades del proyecto. Es sensato que la lnea base de cronograma se desarrolle como colofn a las
actividades de planificacin, justo cuando ya est clara la lnea base de costes y hay que integrar toda la
informacin para crear el plan para la direccin del proyecto, de lo cual se ocupa el proceso 4.2 Desarrollar el
Plan para la Direccin del Proyecto, del rea de integracin.
La gestin de la integracin del proyecto incluye los procesos necesarios para

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

definir, preparar y coordinar todos los planes secundarios e incorporarlos en un plan
integral para la direccin del proyecto. Las lneas base y planes secundarios
integrados del proyecto se incluyen en el plan para la direccin del proyecto.
3.3. Grupo de Procesos de Ejecucin

El objetivo bsico del grupo de procesos de ejecucin
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 direccin del proyecto, donde
est escrito cundo comienzan y terminan las
actividades, cundo hay que adquirir y emplear los recursos, cmo hay que efectuar las adquisiciones, adquirir y
desarrollar al equipo, comunicar, etc. Por otra parte, tambin 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, adems de no improvisar, tambin es muy importante "no parar". Cuando ocurre algn
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 monitorizacin y
control el curso de accin ms apropiado. Y no ser el director
del proyecto el nico involucrado en esta decisin. No es buena
prctica reaccionar ante los problemas improvisando cambios en
ejecucin, pues entonces el alcance cambiara continuamente y
no habra un plan que seguir (tendramos lo que se denomina
scope creep -corrupcin 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 prctica es involucrar a los
dems y buscar juntos la solucin. 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 ms destacable de la ejecucin son los entregables. Mientras no hay entregables, lo nico que hay es
comunicacin. 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. Todava no
se entrega al cliente, ya se ver si la entrega pasa el control de calidad y despus se preparar para que el cliente
o la organizacin solicitante pueda validarla y expresar su aceptacin, pero esto son tareas de control, no de
ejecucin. En cualquier caso, el hecho de que una entrega ya est preparada para su revisin es muy relevante.
Siguiendo el smil de la orquesta, algn msico hara sonar los platillos.
El diagrama IPECC nos permite simplificar las grandes entradas y salidas
del grupo de ejecucin. Obsrvese que hay una flecha desde planificacin
a ejecucin (el plan), otra flecha desde ejecucin a control (los entregables
y los datos de desempeo) y otra desde control a ejecucin (los cambios
aprobados).
El equipo de direccin del proyecto realiza, entre otras, las siguientes actividades de ejecucin:
Adquirir los recursos: Obtener y gestionar los recursos del proyecto, incluyendo los externos siguiendo el
plan de adquisiciones.
Ejecutar las actividades segn se defini en el plan del proyecto, para producir los entregables dentro de
plazo y presupuesto.
Aseguramiento de calidad: Implementar el plan de gestin de calidad usando las herramientas y tcnicas
apropiadas, para asegurar que el trabajo se realiza de acuerdo con los estndares de calidad exigidos.
Implementar los cambios aprobados de acuerdo al plan de gestin de cambios, para cumplir los
requisitos del proyecto.
Implementar las acciones aprobadas para dar respuesta a los riesgos: Poner en prctica las medidas
aprobadas y las soluciones necesarias para minimizar el impacto de los riesgos del proyecto.
Desarrollo del equipo: Maximizar el desempeo del equipo a travs de liderazgo, mentoring, formacin y
gestin del equipo.
Gestionar la participacin 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 participacin.
En la figura pueden apreciarse los principales subgrupos de ejecucin:
La actividad principal de ejecucin que desarrolla el director del proyecto junto con su equipo de gestin 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 direccin 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 ejecucin. El buen desempeo depende del trabajo que haga el equipo: si no son buenos o no
trabajan bien en equipo, por mucho que se empee el director del proyecto, el proyecto ser un fracaso. En la
ejecucin tampoco es lo ms importante asegurar la calidad y efectuar las adquisiciones, pues el xito de estas
actividades viene determinado por una buena planificacin. Qu tiene ms importancia en la ejecucin?
Comunicar. Liderar.
En el Corazn de la Ejecucin: Comunicar el 90% del tiempo

Los directores de proyectos conceden mucha importancia a la comunicacin. PMI nos
recuerda que ms 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 documentacin, etc.
Pero hay que tener en cuenta que la comunicacin no es slo por escrito: el mayor
porcentaje del tiempo se invierte en llamadas, chats, videoconferencias, presentaciones,
reuniones con el equipo, con la organizacin solicitante, con los jefes y resto de
interesados, con cada miembro del equipo para orientarle y darle realimentacin, por no
mencionar la comunicacin informal que tiene lugar en los pasillos, en el comedor, frente a
la mquina del caf, etc.
Los seres humanos nos distinguimos de los animales en muchos aspectos, por supuesto, pero quiz sea uno de
los ms 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 categora de elementos preocupantes y desestabilizadores: Cuando tenemos hambre de informacin,
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 informacin es poder, pero
no es tico (ni eficaz) ocultar informacin para evitarnos problemas. Tampoco hay que tener miedo a dar malas
noticias. Ningn interesado opinar que somos eficaces si nuestra comunicacin 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 algn entregable, lo nico que hay para ofrecerles, es comunicacin. Los interesados son
"informvoros", necesitan comer informacin, pero sus necesidades varan: La PMO necesitar informes
semanales muy completos, el departamento de produccin necesitar informes mensuales sobre costes
incurridos, desviaciones, pronsticos, etc. En cualquier caso, cuando sentamos a un informvoro (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
comunicacin, qu necesitan saber del proyecto y en qu formato.
Hay que decirles cundo tendrn que esperar, y tomar esto como una promesa firme que cumplir. En los
proyectos, hay que planificar la comunicacin indicando, por ejemplo, que habr un informe de
seguimiento semanal que se comunicar por e-mail. No hay nada ms frustrante para los interesados que
la comunicacin sea espordica e impredecible. Seguir el plan de comunicacin es eficaz porque ahorramos
que nos hagan muchas preguntas (ya saben que las respuestas vendrn cuando se ha prometido).
Si queremos que vuelvan, tenemos que preguntarles si la comida les ha gustado, esto es, obtener
realimentacin regular de los interesados sobre el proceso de comunicacin.
Los procesos relacionados con ejecutar la comunicacin pertenecen a dos reas de conocimiento: gestin de las
comunicaciones y gestin de los interesados:
10.2 Gestionar las Comunicaciones: Crear, recopilar, distribuir, almacenar, recuperar y realizar la
disposicin final de la informacin del proyecto de acuerdo con el plan de gestin de las comunicaciones.
13.3 Gestionar la Participacin 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
participacin adecuada de los interesados en las actividades del proyecto a lo largo del ciclo de vida del
mismo.
En el Corazn de la Ejecucin: 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 quin debe hacer qu y cundo. Al principio, quiz
deba realizar algunas tareas, orientar estrechamente a su gente, pero la
aspiracin es que al final se consolide un equipo sinrgico y autosuficiente
en el que pueda delegar todos los trabajos para centrarse en la pura
gestin.
Que aparezca un equipo sinrgico es algo que no se puede garantizar. Usted no hace que ocurra, ms 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 deberamos usar la expresin team building: no es como poner ladrillos y finalmente se
"construye" un equipo. Ms adecuada sera la expresin team growing: podemos regar la planta, es decir,
proporcionarles la visin 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 tambin podra 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 frgil 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 ms cambios, que ese es su equipo de proyecto, su mejor tctica 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 preparacin, o no estn orientados a resultados, o simplemente
no se entienden o no se llevan bien, entonces tenga la seguridad de que no se conseguirn 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 lder eficaz debera ejercer los cuatro roles del liderazgo :
Modelar: Ser un modelo de integridad, una referencia para los dems, inspirar confianza.
Buscar caminos: No imponer la forma de hacer las cosas, sino considerar las sugerencias y
recomendaciones de los dems, encontrar terceras vas 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.
El Liderazgo Centrado en Principios, Stephen R. Covey, Ed. Paids Ibrica, 1993.
El liderazgo de equipos es un rea tan amplia que no puede desarrollarse completamente en la Gua del
PMBOK. Aun as, el director de proyectos puede encontrar una buena orientacin sobre las principales
actividades en los procesos de ejecucin 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 interaccin entre los miembros del
equipo y el ambiente general del equipo para lograr un mejor desempeo del proyecto.
9.4 Dirigir el Equipo del Proyecto: Realizar el seguimiento del desempeo de los miembros del equipo,
proporcionar realimentacin, resolver problemas y gestionar cambios a fin de optimizar el desempeo del
proyecto.
Simplificando mucho, las actividades de ejecucin 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 proporcionndoles formacin, infraestructura, visin, etc.
(9.3) y finalmente gestionar conflictos y corregir el mal desempeo (9.4). El proceso
9.2 es quiz uno de los ms importantes para el director del proyecto, pues an
queda en su zona de control proponer, exigir, o negociar que las personas idneas
formen parte del equipo. A partir de entonces depende de ellos que acaben siendo
un equipo sinrgico y cohesionado. Desde fuera solo podemos estimular, facilitar,
orientar, guiar (9.3) o bien que corregir el mal desempeo 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 Monitorizacin y Control

El hbito de conseguir que las cosas se hagan (Getting Things Done),
en gestin de proyectos significa hacer cumplir la planificacin. Esta
planificacin, a su vez cambiante, hay que mantenerla actualizada.
Hay muchos elementos de la planificacin que no se pueden medir
cuantitativamente, pero en lo que podemos medir, nuestra
responsabilidad es cuantificar la distancia entre lo que debera ocurrir
y lo que est ocurriendo. En nuestra profesin, la expresin
cuantitativa de lo que debera ocurrir se denomina lnea base. Hay
muchas formas de medir cuantitativamente el desempeo de un
proyecto, pero medir no es lo mismo que controlar.
Controlar significa limitar la distancia entre lo que debera estar ocurriendo y lo que
realmente est ocurriendo. La Gua del PMBOK nos dice que esto se consigue
solicitando cambios, que si se aprueban supondrn implementar acciones correctivas,
preventivas, de reparacin 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 ms 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 preocupacin. En nuestra
profesin, la frontera entre una zona y otra no est perfectamente delimitada en la mayora de los casos. En
muchas ocasiones, los interesados, en beneficio del proyecto, toleran que esos lmites se cuestionen y se rebasen.
Muchas veces, el director del proyecto prefiere pedir perdn a pedir permiso.
El diagrama IPECC nos permite simplificar las grandes entradas y salidas

del grupo de monitorizacin y control. Obsrvese que hay una flecha
desde control a ejecucin (los cambios aprobados), otra flecha desde
control a planificacin (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 direccin del proyecto realiza, entre otras, las siguientes actividades de monitorizacin y control:
Medicin del desempeo: Medir el desempeo del proyecto utilizando herramientas y tcnicas adecuadas
para identificar y cuantificar cualquier desviacin para proponer las acciones correctivas necesarias.
Gestin 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 organizacin 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 prximos
pasos para resolver incidentes usando herramientas y tcnicas apropiadas para minimizar el impacto en
plazo, coste y recursos.
Controlar la participacin de los interesados: Comunicar el estado del proyecto a los interesados para
obtener su realimentacin, con el fin de asegurar que el proyecto est alineado con sus necesidades de
negocio.
En la figura pueden apreciarse los principales subgrupos de monitorizacin y control:
En la figura, el subgrupo de la izquierda, controlar las lneas base, sirve para aplicar una serie de tcnicas bien
conocidas que permiten calcular desviaciones y pronsticos. 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 ms o menos mecnicas, al fin y al cabo. En la
parte central de la figura tenemos el subgrupo de controlar la comunicacin la participacin, los trabajos y los
cambios. Este subgrupo s resulta determinante para el xito o fracaso de los proyectos.
Controlando la Comunicacin, la Participacin, 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 direccin del proyecto
comunica adecuadamente y transmite una sensacin de confianza y credibilidad al grupo de interesados sobre la
consecucin final de los objetivos de alcance, plazo, coste y calidad. Por supuesto, ocurren problemas (si no, no
sera un proyecto!) pero la mayora de esos problemas se van viendo venir y hay respuestas aprobadas de
antemano por el equipo de gestin o el comit de seguimiento de alto nivel. Tambin 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 direccin del proyecto
puede resolver esta situacin con un golpe de timn y el proyecto vuelve al camino. Cuando no hay una
planificacin actualizada y realista, o el alcance cambia continuamente a capricho de ciertos interesados, entonces
ocurre lo que se denomina en ingls scope creep (corrupcin 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 informacin de los interesados del
proyecto.
13.4 Controlar la Participacin 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 desempeo definidos en el plan para la direccin 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 organizacin, documentos del
proyecto y plan para la direccin del proyecto; y comunicar las decisiones correspondientes.
Lo que est ocurriendo en el proyecto, los hechos relevantes de la ejecucin, son datos de desempeo 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 informacin en bruto en informacin elaborada que sirva para
tomar decisiones. Si se trata de informacin relativa a interesados, se procesa en 13.4 Controlar la Participacin
de los Interesados. El resto de informacin sobre comunicaciones, incidentes y hechos de desempeo, se procesa
en 10.3 Controlar las Comunicaciones. El resultado de ambos procesos es la informacin sobre el desempeo
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 tratarn, como el resto de cambios, en 4.5 Realizar el Control
Integrado de Cambios.
Es importante recordar cmo funcionan los dos procesos de integracin 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 mdico no podra realizar todas las pruebas clnicas en misma consulta, sino
que necesita los resultados (anlisis de sangre, bronquios, etc.) para decidir el tratamiento (medicacin, cambio de
hbitos, etc.). De igual forma, en la reunin de seguimiento sobre de un determinado proyecto no es el momento
de analizar los datos del desempeo del trabajo que vienen de ejecucin. Esos datos en bruto hay que
procesarlos, elaborarlos, prepararlos para su anlisis ejecutivo, en forma de informacin sobre el desempeo 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 dems en los problemas y buscar con ellos
las soluciones. Como mnimo, el director del proyecto debe compartir la carga del control con su equipo de
gestin. Sin bien lo ms efectivo es que en el proyecto se celebren reuniones peridicas de seguimiento, invitando
a los interesados clave que componen el comit de seguimiento. Estas reuniones de seguimiento tendrn una
determinada frecuencia y seguirn una agenda que hay que se disea de antemano en el plan de comunicacin 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 accin
para el periodo siguiente. Esta ceremonia se representa siguiendo el proceso 4.4 Monitorizar y Controlar el
Trabajo del Proyecto.
Cmo 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 despus es labor del equipo de
gestin analizarlos y priorizarlos y despus 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 ms
efectivo que los cambios se procesen por lotes, en la reunin con el comit de control de cambios.
Controlar las Lneas Base

Segn la Gua del PMBOK, una lnea base es una versin aprobada de un producto de trabajo que slo puede
cambiarse mediante procedimientos formales de control de cambios y que se usa como base de comparacin. En
otras palabras, podramos decir que la expresin cuantitativa de lo que debera ocurrir se denomina lnea base. En
todo proyecto hay 3 lneas base. Lnea base de alcance: vamos haciendo lo que haba que hacer? Lnea base del
cronograma: vamos en fecha, retrasados, adelantados? Lnea base de costes: vamos en coste, con sobrecoste, por
debajo de coste?
Hay muchas formas correctas ya inventadas para medir cuantitativamente el desempeo de un proyecto. Sin
embargo, el anlisis cuantitativo no se improvisa bien. Cuando nos piden una explicacin puntual sobre los
retrasos, por ejemplo, siempre podremos preparar una hoja de clculo o una presentacin
con nuestro anlisis. 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 debera 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 Lneas Base incluye cuatro procesos, que pueden considerarse como los procesos
ms tcnicos que debe dominar el director de proyectos. Son las habilidades ms hard y menos soft, si
queremos decirlo as. Afortunadamente, aqu hay herramientas y tcnicas que han demostrado su efectividad y
hay un camino de aprendizaje muy transitado. Por desgracia para quien no domina esas tcnicas, las evidencias
de poca profesionalidad suelen ser objetivas y evidentes.
En la siguiente figura se muestran los procesos dedicados a controlar las lneas base de alcance, el cronograma y
costes:
5.5 Validar el Alcance: Consiste en formalizar la aceptacin de los entregables del proyecto que se hayan
completado. El equipo ya ha verificado los entregables generados en ejecucin en el proceso 8.3 Controlar
la Calidad. El siguiente paso es hacerlo llegar con la configuracin adecuada al cliente (o a ciertos usuarios
representativos del cliente o la organizacin solicitante) con el fin de que estos entregables sean validados
mediante su inspeccin correspondiente. Aunque la decisin est en el tejado del cliente, no por ello el
equipo de gestin tiene que desentenderse. Al contrario: es muy importante que si los entregables son
correctos, la validacin 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
direccin ya se puede plantear el cierre del proyecto. Como el cierre de un proyecto es una de las
actividades ms importantes y distintivas en gestin 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 gestin.
5.6 Controlar el Alcance: Consiste en monitorizar el estado del proyecto y del alcance del producto, y
gestionar los cambios a la lnea 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 lnea 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 lnea base de costes. Para medir el desempeo 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 ejecucin de las
actividades de control de calidad, a fin de evaluar el desempeo y recomendar los cambios necesarios. En
este proceso, el equipo inspecciona los entregables que vienen de ejecucin y los someten a las pruebas
planificadas. Si pasan las pruebas entonces son entregables verificados que ya estn listos para ser
validados por la organizacin solicitante. En este proceso tambin se validan los cambios, es decir: se
controlan que los cambios han sido debidamente implementados en ejecucin.
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 gestin de los riesgos a travs del proyecto. La gestin 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 da de la entrega, el riesgo de que el cliente no acepte un entregable
desaparece con la aceptacin, al final del proyecto no hay ningn riesgo. En este proceso se lleva esa
contabilidad sobre el estado de los riesgos, con especial atencin a los ms 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
ejecucin de los contratos y efectuar cambios y correcciones segn corresponda. Con ayuda de este
proceso, el equipo de direccin del proyecto controla las actividades habituales al administrar un contrato,
como son las reclamaciones, los pagos, informacin sobre el desempeo. Dado que en este caso el director
del proyecto no lidera el equipo que realiza los trabajos, es importante que registre toda la informacin
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 razn: 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. Adems 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 organizacin solicitante, etc.,
pero quiz lo ms distintivo de un proyecto es que empieza y
termina. Uno de los hbitos que se le pide a un director de proyectos es que comience con el fin en la mente.
Desde el primer da del proyecto debe visualizar el destino y el camino para llegar al mismo. Nos imaginamos
cmo ser esa situacin 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 ocurrirn 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 sinrgico; en el que los contratos que su empresa firmar con terceros para que hagan ciertas
partes del proyecto podran terminar en los tribunales, etc. Todo este entuerto debe deshacerlo el director del
proyecto, por tanto es muy natural que se imagine ese ltimo da en que ocurre el cierre efectivo y por fin termina
todo: Ha convocado al patrocinador y un subconjunto representativo de interesados. Ha elaborado una
presentacin 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 presentacin de fin de proyecto,
pero en su cabeza, esta presentacin tiene este otro ttulo: Adis, me voy.
Seguramente, esta forma de pensar tiene fuertes implicaciones psicolgicas. No resulta un poco alienante que
eso que nosotros hemos creado con tanta ilusin, nuestro proyecto, queramos hacerlo morir desde el primer
da? 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:
Presentacin de Fin de Proyecto = Adis, me voy.

Logros e hitos alcanzados = No me queda nada por entregar y lo tengo todo aceptado.
La documentacin del proyecto se puede acceder en esta carpeta, estas son las siguientes fases = El
producto entra en fase de operacin, 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 reunin de cierre es la ms trascendente del proyecto. Deber gestionarse de la

manera ms efectiva. No debe convocarse si an queda algo por hacer. Aunque est
todo aceptado, no es suficiente. Hay que escenificarlo para que inequvocamente se
sepa que se ha terminado. A partir de esta reunin, los interesados ya no tienen derecho
a pedir ms cambios.
El equipo de direccin del proyecto realiza, entre otras, las siguientes actividades de cierre:
Aceptacin formal: Obtener la aceptacin final de los entregables del proyecto trabajando con el
patrocinador y/o la organizacin solicitante, para confirmar que el alcance y los entregables se han
validado.
Transicin: 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 prcticas generalmente
aceptadas, para comunicar el cierre formal y asegurar la liberacin de responsabilidades futuras.
Informe de cierre: Distribuir el informe final del proyecto incluyendo toda la informacin relativa al cierre,
desviaciones e incidentes, para comunicar la situacin final del proyecto a los interesados.
Lecciones aprendidas: Recopilar las lecciones aprendidas a partir de una revisin completa del proyecto,
para crear y/o actualizar la base de conocimiento de la organizacin.
Dossier del proyecto: Archivar los documentos y material del proyecto, con el fin de retener el
conocimiento de la organizacin, cumplir los requisitos legales, y garantizar la disposicin de la informacin
para su uso potencial en futuros proyectos e internos y auditoras externas.
Satisfaccin de la organizacin solicitante: Medir la satisfaccin del cliente o la organizacin solicitante al

final del proyecto capturando su realimentacin, para facilitar la evaluacin del proyecto y mejorar las
relaciones con la organizacin 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
direccin de proyectos para completar formalmente el proyecto o una fase del mismo.
12.4 Cerrar las Adquisiciones: Finalizar cada adquisicin para el proyecto.

Navegando Por La Guía Del PMBOK PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Navegando Por La Guía Del PMBOK PDF

Uploaded by

Copyright:

Available Formats

3

3. Navegando por la Gua del PMBOK

El Director de Proyectos a Examen | 81

3. Navegando por la Gua del PMBOK

La organizacin patrocinadora, a travs de un patrocinador o bien un iniciador externo al proyecto,

Si la organizacin ejecutora aprueba el proyecto, finalmente se observar que se entrega formalmente un

82 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

procesos de planificacin, se acaba produciendo el documento maestro para la ejecucin y el control

El Director de Proyectos a Examen | 83

3. Navegando por la Gua del PMBOK

84 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

3.1. Grupo de Procesos de Inicio

mantener el proyecto centrado en la necesidad de negocio,

El Director de Proyectos a Examen | 85

3. Navegando por la Gua del PMBOK

As es como define los procesos de inicio la Gua del PMBOK:

86 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

3.2. Grupo de Procesos de Planificacin

A partir del acta de constitucin del proyecto y del registro de

El Director de Proyectos a Examen | 87

3. Navegando por la Gua del PMBOK

88 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

En la figura pueden apreciarse los principales subgrupos de planificacin:

El Director de Proyectos a Examen | 89

3. Navegando por la Gua del PMBOK

90 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

En el Corazn de la Planificacin: Riesgos, Calidad y Adquisiciones

El Director de Proyectos a Examen | 91

3. Navegando por la Gua del PMBOK

Planificar incorrectamente los Riesgos

Un proyecto de consultora de ayuda al desarrollo de pequeas y medianas empresas de Egipto financiado

Lo contrario a gestin de crisis se llama gestin de riesgos. La peor imagen

92 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

Planificar adecuadamente los Riesgos

El Director de Proyectos a Examen | 93

3. Navegando por la Gua del PMBOK

94 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

Planificar incorrectamente las Adquisiciones

En esta situacin, el director de proyectos no controla los trabajos, sino que

Planificar incorrectamente la Calidad

El Director de Proyectos a Examen | 95

3. Navegando por la Gua del PMBOK

Planificar adecuadamente las Adquisiciones y la Calidad

La gestin de las adquisiciones del proyecto consiste en comprar o adquirir los

El proceso 12.1 Planificar la Gestin de Adquisiciones del Proyecto consiste en

96 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK

La gestin de la calidad del proyecto consiste en determinar

El Director de Proyectos a Examen | 97

3. Navegando por la Gua del PMBOK

Desarrollar la Lnea Base de Alcance

5.1 Planificar la Gestin del Alcance: Crear un plan para la

5.2 Recopilar Requisitos: Determinar, documentar y

5.3 Definir el Alcance: Desarrollar una descripcin detallada

98 | El Director de Proyectos a Examen

3. Navegando por la Gua del PMBOK