f' l7

o
- Curtis R. Cook
=
(n a

P
o
o i l, )

:,lc cnl()(luC ct'rrtradtl en cl pKryect0 h¿l comprobado su valor,

o
F
vr/
, r ot I r ¡t it'ntltl rcstr I t¿tdos cspectaculares terminados
-proyectos
,
'rr rrr,is rir¡riclcz y c()11 un costo más razonable que antes. El pro-

'lr,rrr,r ('s (lLrc cl pnrceso de administración usado para proyectos

ir',ur(l('s t's demasiado complicado y burocrático para los pro-
i::i)'
, t't tos tluc casi todos nosotros manejamos y suele ser más com-

Los cuofro
,lr'lo y costoso que el problema que intenta resolver. ¿Le suena
,rrtrlt'itltl?
I os 4 yilsos indispensables para administrar proyectos integra
,r inlorrnación y herramientas actuales más efectivas para la ad-
rrirristración de proyectos en un proceso especialmente diseña-
lo P¡¡¡'¿1 rnanejar proyectos pequeños o medianos. Este valioso
)r,uu.r¿rl le ahorrará tiempo y le proporcionará:
posos
Un proceso versátil de cuatro pasos para iniciar, pla-
near, controlar y finalizar su siguiente proyecto.
Formatos especiales para ayudarlo a organizar sus pro-
yectos y desarrollarlos con un mínimo de desperdicio
de esfuerzos.
indispensobles
Consejos, técnicas e historias reales surgidas de la ad-
ministración contemporánea de proyectos.
l,l olrjt.tivo fundamental de la administración de proyectos es
pctrq
I'rotltrcir los resultados deseados, a tiempo y en presupuesto.
I 'r'r'rn ita que esta obra le muestre cómo centrarse en este objetivo

v rnarrcjar los proyectos que transformarán exitosamente a sus

rrl, jt'tivcrs en resultados de utilidades,envezde simplemente crear
qdminisfror
rrrirs proyectos.

ISBN 3L¿]O-I,IIItr J
proyectos
PANORAMA
EDITORIAL
l,rr Fltlitorial de la
irr¡rcrilcióu y la Calidad
rww [ ), lnoramaeo.com.mx
r'r rl, r:i (cD
Danoramaed.com.mx ilillllillilllilllllllil I'AN()IIAMA
 /,_: :l-

,ñá//ry
El autor / 2'od
:l Dr. Curtis R. Cook, es presidente
:lc Novations Project Management en
Atlanta. Es responsable de lograr resul-
Los cuatro pasos---<*
tados por medio deldesarrollo e implan-
l¿rcrón de proyectos, gente y procesos.
indispensables para
Sus antecedentes laborales incluyen la
responsabilidad por utilidades en varias
administrar proyectos
empresas de consultoría y capacita-
ción, así como organizaciones del go-
[-lierno federal. Es conocido por su
capacidad técnica y su experiencia en
consultoría, mentoría, coaching, entre-
namiento, planeación estratégica y de-
sarrollo organizacional. El Dr. Cook ha
presentado seminarios en 35 países a
rniles de ejecutivos, gerentes y miem-
bros de equipos en virtualmente todos
los sectores empresariales, incluyendo
tecnología de la información, arquitec-
tura/ingeniería, gobierno, aeroespacial/
defensa, productos farmacéuticos, bio-
tecnolog ía, construcción, petróleo/ener-
gía, desarrollo de productos y servicios
generales. En total, el Dr. Cook tiene
más de 30 años de experiencia en la
administración de organizaciones de
los sectores público y privado, proyec-
tos y contratos. Posee un doctorado por
la George Washington University, un
MBA por la University of Utah y una li-
cenciatura por la University of Oklaho-
ma. Es un profesional certificado de la
administración de proyectos (PAP)y un
profesional certificado en la administra-
ción de contratos (PCAC).

Pon re Supnuclóri o¡r Srn Huuluo y sus l¡{snrucroN¡s

 Curtis R Cook

Los cuatro pasos

indispensables
para administrar
proyectos

n# PAN.RAMA EDTT.RIAL
 Dedicatoria:
Este libro está dedicado a mi esposa y mejor amiga Cindy,
I ()S 4 PASOS INDISPENSAIII I S PARA quien por 25 años me ha apoyado y creyó e1mí cuando
AI )MINISTRAR PROYEC IO$
ái¡e, " ¿sabes? voy a escribir un libro sobre ad'ministración
lftulo original en Inglót: de proyectos...
JUST ENOUGH PROJECT MANAGEMENT

Derechos Reservado¡
Copyright @ 2005, 2006 by f ho McGraw-Hill
Companies, Inc.

All rights rdserved,

McGraw-Hill, Two Ponn l,lnza, NewYork, NY
10121-2298

Portada:
Fotograffa. Photos.com

Traducido al español por:

Antonio Eroles G.

Primera edlción en €sDañol: 2006

@ Panorama Edltorial, S.A. de C.V.
Manuel Ma. Contreras 45-B
Col. San Rafael 06470 - México. D.F.

Tels.: 55-35-93-48 o 55-92-20-1 9

Fax: 55-35-92-02 o 55-35-1 2-1 7
e-mail: panorama @ iserve.net.mx
http : //www. pano ram ae d. com. m x

Printed in Mexico
lmpreso en México
lsBN 968-38-1491-3

Prohibida la reproducción parcial

o lotal por cualquier medio sin autorización
por escrito del editor.
 lndice
Prólogo .----.9
Introducción ..'...11
¿Es para usted Los 4 pasos indispensables para administrar
Reconocimientos proyectos? ......'.13
Formatosylistasdeverificación.. ......;l'4
I
Quiero expresar mi agradecimiento a mi t'clitor, Lisa O'Connor, por su Panorama cle la admlnlstraclón de proyectos . . . . . .t5
entusiasta apoyo a este proyecto. Como gt'rerrte de proyecto de un li- Día de acción de gracias en Beech Mountain . . . .15
bro sobre administración de proyectos, rlur)ca dcjó de expresarme que Administración justamente suficiente de proyectos . . . . . . . . . .16
el matcriar era interesante y útil para ella, ¡rroporcionándome un gran La administración de proyectos como Proceso . . . . . . . . .18
alie¡rto como autor. Algunos fundamentos antes de seguir . . . .1'9
Craig Sawin, presidente de Novatiorrs Group, me motivó a es- El valor de la administración de proyectos . . . . . . . . . . . -20
cribir este libro desde el momento en que lc presenté un modelo de la Ejemplos de demasiada administración de proyectos . . . - . . . . .24
prrrtada. Le agradezco a él y a muchos de los amigos y colegas de Todos los proyectos necesitan ser administrados-pero
Nov¿rtions Group su entusiasta apoyo. sólo lo suficiente pararealizareltrabajo .... . - - - - - - -.26
Finalmente, quiero agradecerle al grupo de J. Howard and Asso-
ci.rtes, haber sido los primeros en aplicar los principios de este libro. En 2
¡rarticular, Naomi Sutherland y Kathy Lennox fueron grandes par-
Inlclo delproyecto ......29
tidarias del enfoque simplificado y por medio de su disposición a usar ¿Esestounproyecto?... .........29
tuna administración de proyectos "suficiente" a sus propios proyectos, Arranquedelproyecto.... .......31
me alentaron a presentar la idea del libro a McGraw-Hill. Establezca el expedienteocarpeta delproyecto ... '...35
¿Quénecesitasaberantesdeproceder? ...'.....35
ElProtocolodelproyecto.. .....'.38
Transiciónalafasedeplaneación.. ... '..45
3
planeaclón
Fundamentos de la .. .. . ..47
Elprocesodeplaneación.. .......48
¿Cuánto tiempo debe dedicársele a la planeación? . . . . .49
Formandoelequipocentral .......50
Actividadesdeplaneación. ... ' '..51
Planpara monitorear la finalización de tareas ....... .'63
 Índice

4
Técnlc¡s avanzadas de planeaclón . . . .65
Maneras de desplegar el programa del ¡rroyecto
ymonitorearlafinalizacióndetareas ........65
Programación"avanzada" . .......68
Presupuestacióndeproyectos... ........74
Planeaciónderiesgos ......76
Planeación de la comunicación
Proceso de control de cambios
. . . .78
. . . .83 Prólogo
Aprobacióndelplandelproyecto .......83
Transiciónala fasedecontrol .....85
5
Controldelproyecto... .......87 I-
....
Actividadesdecontrol .......87 L- n Los 4 pasos indispensables para administrar proyectos, Curtis Cook
Administracióndeldesempeñotécnico .........87 ha traducido con éxito un gran de conocimientos destinados a
cúmulo
Comunicación de logros yestado del proyecto . . . . . . . .90 proyectos grandes y complejos, a un lenguaje que todos los involucra-
Reunirse o no reunirse-ésa es la cuestión . . . . . . . . . . . .90 dos en este tipo de actividades podrán entender y aplicar a su trabajo
Administración de variaciones de costos. diario en proyectos. Aunque es consistente con A Guide to the Project
programaciónyrecursos.. .....91, Management Body of Knowledge (p¡rtnox Guide), el estándar del Ameri-
Controldecambios ........95 can National Standards Institute para la administración de proyectos,
Administración de riesgosyasuntos .....97 el libro reduce muchos procesos a cuatro pasos prácticos fáciles de
Administración del equipo delproyecto ... ....98 entender.
Manejo de las relaciones con el cliente . . .1.02 Los 4 pasos indispensables para administrar proyectos incluye forma-
Transiciónalafase decierre .....104 tos y listas de verificación que pueden ser usados de inmediato. Por
6 consiguiente, es una guía muy útil para cualquiera que desarrolle ac-
Cierredelproyecto... ..tO5 tividades de corto plazo con resultados específicos medibles otras
-en
Modelo para cerrar el proyecto . . .108 palabras, proyectos.
Transicióna operaciones,apoyoymantenimiento ...,119 Empezando con una excelente introducción a los proyectos y su
AdministracióndeproyectosmúItiples ........120 administración, este libro pasa de inmediato a los aspectos prácticos.
El Capítulo 2 sobre el inicio del proyecto, proporciona un formato del
7
protocolo del proyecto claro y conciso, incluyendo instrucciones de có-
Manejo de proyectos múltlples y sobrecarga <Ie proyectos . . . .l2l
mo llenarlo para el proyecto del lector. De ahí, el libro pasa tanto a los
La sobrecargacomonorma ......1,2L fundamentos de la planeación del proyecto en el Capítulo 3, como a
Lainterconexióndetodo ........123 conceptos de planeación más avanzados en el Capítulo 4. El Capítulo
Cinco pasos para manejar la sobrecarga de proyectos . . . . . . .126
4 en especial, proporciona excelentes lineamientos de la forma de crear
Glosarlo ....135 programas realistas, cómo vencer las presiones políticas, cómo antici-
índlceanalítico ...143 par los riesgos y cómo tomar en cuenta las realidades estadísticas Para
l0 Curtis R. Cook

gcnerar un plan del proyecto que realmente tenga éxito (algo raro en
rrucstra sociedad).
El Capítulo 5 penetra en las realidades del control del proyecto una
vez que se ha aprobado el plan básico. Aquí, el lector encontrará de-
talles sobre control de cambios, manejo de los desafíos de los equipos,
¿idministración de la relación con los clientes y mantener el proyecto en
curso. El Capítulo 6 continúa el tema práctico del libro proporcionan-
do un proceso simple y fácll de seguir para lograr la aceptación del
cliente de los entregables, capturando las lecciones aprendidas, cele-
lntroducción
brando los éxitos del equipo y efectuando la transición a la operación
del proyecto.
En el Capítulo7, el libro cambia de giro al tratamiento del muy
necesario manejo de proyectos múltiples pequeños. Cook proporciona
un modelo excelente pero conceptualmente simple para manejar la a mayor parte de las personas está involucrada de alguna forma
sobrecarga de proyectos y proyectos múltiples. hoy en día en trabajos de proyectos, pero para casi todos nosotros, el
El libro termina con un excelente glosario de los términos clave y uso de técnicas formales de administración de proyectos de tamaño
una bibliografía muy informativa.
promedio, equivale a contratar a un despacho de contabilidad para
En Los 4 pasos indispensables para administrar proyectos, Curtis Cook
balancear nuestros libros. ¿Pueden hacerlo? Por supuesto sería
ha creado una guía práctica y fácll de usar para administrar proyectos. -pero
un exceso. Y sin embargo, cuando se usan en su proporción correcta,
Puede servir como un excelente manual o fuente de recursos para
los principios y técnicas de la administración de proyectos pueden ser
cualquiera involucrado en la administración de proyectos, en especial
invaluables incluso en proyectos pequeños- en especial cuando se
para quienes tienen poco entrenamiento formal o experiencia. Expre-
maneja una media docena. Bienvenido a Los 4 pasos indispensables para
sado de manera simple, este libro es de lectura obligatoria para las
administr ar proy ect os.
personas a cargo de proyectos que quieran terminarlos a tiempo, den-
Durante la última década, la administración de proyectos se ha
tro del presupuesto y de acuerdo a las especificaciones.
vuelto muy popular como enfoque para manejar esos esfuerzos finitos
a los que llamamos "proyectos".Peto, por desgracia,la tarea suele con-
David I. Cleland, Ph. D., PMP
Profesor Emérito siderarse como en exceso burocrática y complicada, añadiendo poco
University of Pittsburgh valor. En la edición de enero de 2004 de PM Network, "Ni hablar de
hojas de cálculo" [Pág.20], Tom Peters dice,
Con el advenimiento de la tecnología de la información, Ios
gerentes de proyectos se han enfocado demasiado en gráficas y
diagramas y no lo suficiente en el valor global del negocio...No
debemos ser abrumados por los detalles y perder de vista la
gran imagen.
Mis propias observaciones durante los últimos 30 años apoyan las
conclusiones de Peters. He visto crecer la administración de proyecto
 12 Introducción
descle una aplicación específica del sentido común hasta el uso exce-
sivo de procesos complejos. Muchas organizaciones han adoptado la
arlrninistración de proyectos pero usando el "enfoque del libro de 200
1-r.iginas" con docenas de pasos de procesos y las entradas, salidas, he-
¡'r.rrnientas y técnicas inherentes. Y sin embargo, las estadísticas citadas
por las principales organizaciones de investigación nos dicen que
nrenos del 50% de nuestros proyectos alcanzan sus objetivos. ¿Por qué?
La respuesta es bastante obvia. Como lo sugiere Peters,los geren-
tes de proyectos se han centrado en "enterrarse en laparte", gastando
mucho tiempo buscando datos y empaquetándolos para reportarlos a
la gerencia, sin ocupar el tiempo suficiente en realmente resolver proble-
mas y añadir valor. Es necesario tener en cuenta que el valor subyacen-
te de la administración de proyectos es la eficiencia y efectividad con
la que transforma los objetivos estratégicos en resultados de negocios.
Y no obstante, irónicamente, la profesión y la práctica se han venido
asociando con procesos burocráticos. Digo "irónicamente" porque la
fuerza impulsora de la génesis de la administración de proyectos fue el
deseo de eliminar la burocracia y realizar el trabajo.
¿Qué sucedió? En los primeros tiempos de la administración de
proyectos, los equipos de proyectos lograron grandes éxitos. El entre-
tenido e informativo libro de James Tobin, Great Projecfs [Free Press,
2001] está lleno de ejemplos de equipos que han logrado triunfos tan
diversos como dominar el Río Mississipi o la Internet. Debido al obvio
éxito de este enfoque, el concepto creció y comenzó a ser aplicado a to-
dos los proyectos y no sólo a los grandes. El Project Management
Institute [PMI] nació en los ochenta. El Comité de Estándares del PMI
escribió y publicó A Guide to the Project Management Body of Knowtedge
(PMBOK Guide), que describe 39 procesos y subprocesos, proporcionando
una gran cúmulo de herramientas y técnicas. Se instituyeron programas
de certificación, siendo la credencial más importante la designación de
Profesional de la Administración de Proyectos (PAP). Se crearon pro-
gramas académicos, incluyendo estudios de maestría y doctorado en la
especialidad de administración de proyectos. La idea era que si una
persona podía obtener el grado de rep o un título avanzado en la ad-
ministración de proyectos, esa persona sería un gerente de proyectos
efectivo, sino es que excelente. Y cuando esta estructura y conocimien-
tos se aplican a grandes proyectos y se apoyan en las herramientas de
software apropiadas, la conclusión es válida. Pero la mayoría de los
Introducción 13
proyectos no son de gran tamaño y los procesos complejos no ayudan
a los gerentes en los proyectos de tamaño promedio.
A un amigo mío le gusta decir, "Pata un niño de 4 años con un
martillo,la totalidad del mundo es un clavo". Armados con la PMBOK
Guide, más de 100,000 gerentes de proyectos se dedican a administrar-
los usando la "biblia" . Pero los proyectos pequeños no necesitan toda
la información, técnicas yherramientas delaPMBOKGuide y definida-
mente no necesitan los gruesos manuales de proceso para lograr sus
objetivos. Los 4 pasos indispensables para administrar proyectos des-
tila toda la información que "está alIá afiJera" en unas cuantas técnicas
fáciles y rápidas para quienes manejan proyectos de tamaño medio y
tienen que hacer malabares con varios proyectos pequeños. No hay du-
da que el enfoque de la administración de proyectos es muy valioso
cuando se aplica a cualquier proyecto, pero necesitamos aplicar sólo lo
suficiente para rcalizar el trabajo sin tantos obstáculos.
¿Es para usted Los 4 pasos indispensables
para adm inistrar proyectos?
Este libro una guía práctica de "como hacerlo" para manejar proyec-
es
tos. Si usted es responsable de la administración de proyectos dc tama-
ño pequeño a mediano, en especial cuando trabaja simultáneamerrtc en
varios de ellos, este libro es para usted. Piense en él como un manttal
que lo guiará paso a paso en su tarea. Siga los pasos descritos y tendrá
un mayor grado de éxito en sus proyectos. A lo largo de toda la obra,
cada paso se descompone en una serie de actividades simples qLre
puede realízar para llevar su proyecto desde el inicio a través de la pla-
neación, y hasta la finalización con conclusiones efectivas.
Si bien no es mi intención denigrar a la PMI o a la credencial PAP,
y por supuesto, tampoco a los títulos de postgrado (yo soy un PAP y
poseo un Ph. D. en un campo muy relacionado con la administración
de proyectos), la verdad simple es que no se necesitan esas credenciales
para manejar bien la gran mayoría de los proyectos. Lo que se necesita
es "suficiente" capacidad de administración de proyectos para realizar
bien el trabajo. Este es el principal enfoque de este libro.
Esta obra también proporciona un buen panorama general de la
administración de proyectos para quienes manejan a gerentes de pro-
yectos, para ejecutivos que patrocinan proyectos y son responsables de
los resultados, para muchas personas dedicadas a proyectos que no
l4 Introducción

son de gran envergadura y para los miembros de los equipos de pro-

yectos. El lenguaje utilizado es consistente con el de la PMB)K Guide
y los pasos descritos concuerdan con los cinco grupos de procesos del
1
PML Esto puede ser importante si su organización tiene un buen pro-
grama de capacitación para gerentes de proyectos y programas basado
en la PMB)K Guide. Encontrará que las definiciones de términos del
glosario son similares, y en algunos casos idénticas, a las definiciones
generalmente aceptadas por esta guía.

Formatos y listas de verificación Panorama de

El libro proporciona en toda su extensión varios formatos y listas de
verificación para ayudarlo a pensar en los documentos necesarios para
la administración
administrar proyectos y paracrearlos. Thmbién se incluyen las instruócio-
nes de cómo aplicar los formatos, junto con lineamientos prácticos para
de proyectos
uso en proyectos reales. Estos formatos son documentos Microsoft
Word o Microsoft Excel fáciles de crear.

Día de acc¡ón de gracias

en Beech Mountain

I f ace ,rt par de años, nuestra familia decidió que la cena del día de
acción de gracias se haría en nuestra pequeña cabaña de 75 metros cua-
drados en las hermosas montañas de North Carolina. Beech Moun-
tain, el pueblo donde ahora vivimos, está habitado por escasamente
27g almas y el clima en noviembre es frío ---<lima de chimenea. Pen-
saron que tener ahí a toda la familia con el aroma del pavo asándose y
los sonidos del fuego chisporreteando resultaría muy atractivo' Sólo
había un problema: La cocina de nuestra pequeña cabaña era aPenas
suficientemente grande Para una Persona- uno de esos espacios
donde, si la puerta del horno está abierta, no Se puede abrir el refri-
gerador. Mi esposa estuvo de acuerdo en que fuéramos, pero también
mencionó que tendríamos que cenar fuera o llevar el pavo ya PrePa-
rado, por lo pequeño de la cocina' Recuerdo que dijo "Es imposible
cocinar la cena del día de acción de gracias parat2 Personas en esa co-
cina". Naturalmente, como soy un gerente de proyectos/ comencé a in-
teresarme en el asunto. Me ofrecí como voluntario para administrar
el "proyecto" si ella estuviera dispuesta a actuar como mi experto en
16 Curtis R. Cook Panorama de la administración de proyectos T7

el tema (ET). Estuvo de acuerdo. Acabábamos de arrancar nuestro proyecto y el nivel de experiencia técnica del gerente de proyecto y
proyecto. el equipo, aplicamos justamente la suficiente Para efectuar el trabajo.
Para llevarlo a cabp, sabíamos que tendríamos un plan para coordi- Recordemos los pasos:
nar todas las actividades, por lo que conecté mi computadora portátil,
L. Iniciar: ¿Cuál es el reto o el problema?
abrí mi software de administración de proyectos, agarré mis libros de
recetas y con mi esposa (recuerde que ella era mi ET que poseía el co-
2. Planear: ¿Cómo deberemos proceder?
nocimiento técnico) me senté a crear el plan. El primer trabajo de la pla- 3. Controlar: ¿Estamos en el camino correcto?
neación de proyectos es listar todas las tareas que deberán hacerse para 4. Cerrar: Terminar el trabajo, evaluar lo hecho y absorber las lec-
alcanzar el éxito, por lo que generamos nuestra lista de tareas (planear ciones aprendidas
el menú, ir de compras, cocinar la cena, poner la mesa, etc.). A conti- La Figura L-1 muestra estos cuatro pasos como parte del Proceso
nuación, anotamos todas las tareas en el orden en que tendríamos que general.
realizarlas para poder preparar la cena y servirla a tiempo. Después
determinamos quién haría cada tarea (usamos a nuestros hijos y nues-
tros padres como "recursos"). Tras esto, analizamos todas las cosas que
podrían salir mal y añadimos unos dólares y algo de tiempo al plan. Fi-
nalmente, nos sentamos a revisar el plan y decidimos que estábamos
listos para echarlo a andar. ¡La planeación había terminado! Para asegu-
rarnos que todo mundo supiera cuál era su parte de todo el asunto, im-
primí la lista de tareas y la programación (si incluyendo la ruta crítica
en rojo puedo evitarlo). La adherí al refrigerador de nuestra caba-
-no
ña cuando llegamos y gocé anticipadamente contemplar las reacciones
de la familia cuando supieron que estaban incluidos en un proyecto.
Para abreviar la historia, todos estaban realmente excitados de
participar en nuestro "ptoyecto" y realmente se dedicaron a sus tareas.
El plan funcionó sin fallas con algún pequeño tropiezo aquí y allá para
mí, el gerente del proyecto. En algunos momentos nos retrasamos, pero
Figura 1-1. Los cuatro pasos de la administración de proyectos.
compensamos el tiempo con trabajos aquí y allá (control del proyecto).
La cena se sirvió a tiempo, todos se sintieron orgullosos de su contribu-
ción y gozamos de una cena perfecta. Sin embargo, hubo una lección Nótese que el paso de control incluye ejecutar el trabajo y contro-
que aprendí de forma difícil. Olvidé añadir "limpiar" a la lista de ta- lar las desviaciones con respecto al plan. El paso se llama control y no
reas y, como sucede con tanta frecuencia, el gerente del proyecto tuvo ejecución, porque el papel del gerente del proyecto mientras se está
que hacer la tarea sucia. Incluí esto es mi archivo mental de "lecciones realizando el trabajo, consiste en monitorear el desempeño e identificar
aprendidas " pata referencia futura. las variaciones con respecto al plan, para aplicar acciones correctivas.
La ejecución del trabajo no es por sí misma una función de la adminis-
tración del proyecto, aun cuando, como sucede a menudo, el gerente
Administración justamente suficiente de proyectos del proyecto también haga algo del trabajo o la mayor parte. En el
¿Aplicamos demasiada administración al proyecto o demasiado poca? enfoque de justamente lo suficiente, nos centramos en la forma en que
Aun cuando suena como que exageramos, de hecho, considerando el el gerente del proyecto lo controla, no en cómo hacer el trabajo técnico.
IB Curtis R. Cook Panorama de la administración de Proyectos L9

La administración de proyectos como proceso el trabajo se haga a tiempo, dentro del presupuesto, consistente
La administración de un proyecto es un proceso serie de pasos con las especificaciones y requerimientos. Se generan reportes de
-una
realizados para lograr un resultado específico. Todos los proyectos tie- avance del proyecto para mantener informados a todos los inte-
nen un ciclo de vida básico consistente de cuando 4 pasos. Depen- resados.
diendo de la industria y del tipo de proyecto, este moáelo básico es 4. Cierre del proyecto. El paso final consiste de tres actividades dis-
suscepüble de ser ampliado (algunas empresas farmacéuticas tienen tintas:
procesos de 12 pasos), pero no puede comprimirse. El enfoque de jus-
tamente suficiente es simplemente la aplicación de estos pasos a cual-
. Enhega. Asegurarse de que se le entregue al cliente del proyecto.
quier esfuerzo que consideremos como un proyecto. Analicemos cada
. Reciclaje. Asegurarse que las lecciones duramente aprendidas
paso con un poco más de detalle. (El resto del libro cubrirá cada uno durante el proyecto sean transmitidas o otros.
de ellos con mayor profundidad.)
. Celebración. Recompensar al equipo y celebrar el éxito.
El proceso de cierre incluye algunas comprobaciones de último
1. Iniciar el proyecto. El objetivo de este paso es reconocer la necesi
minuto para estar seguro que todo está en orden y que se han satisfe-
dad de un proyecto, determinar qué debe lograrse y comenzarlo cho los requerimientos del proyecto.
formalmente con un protocolo del proyecto. Durante el paso de
iniciación se selecciona al gerente del proyecto y se re olorga la
autoridad para crear el equipo que lo ejecutará. Algunos fundamentos antes de seguir
2. Planear el proyecto. La planeación del proyecto es el proceso de
Es útil pensar en un proyecto como en cualquier otro trabajo con un
inicio definido y un punto final, así como con objetiaos específicos y bien
desarrollar un plan detallado que incluya la lista de taréas, el plan
definidos que, al conseguirse, identifican la terminación. En la práctica,
de riesgos y el proceso de control de cambios. Esto puede parecer
demasiado detallado, pero si se toma un minuto para pénsarlo,
la mayor parte de los proyectos tienen recursos y tiempo limitados
para lograr los objetivos. Este sistema es tan típico que se le da incluso
verá que no lo es tanto. Incluso para proyectos de su casa, tiene
un nombre restricción triple- tal como se muestra en la Figura 1-2.
que saber qué pasos deberá dar para realizar el trabajo, cuánto -la
dinero tiene en su presupuesto, quiénes van a hacer las tareas y
cuánto tiempo tomará el proyecto. Y también sabe que algunas
cosas saldrán mal, lo cual requerirá un poco más de dinero y tiem-
po que el que tenía planeado. Es lo mismo para proyectos ,,ofi_
ciales" en el trabajo por lo general tienen más detalle Mes
para reflejar su mayor-aunque
tamaño y complejidad. Una vez que el pa-
trocinador del proyecto aprueba el plan, se le llama línea base-del
proyecto.
3. control del proyecto durante la ejecución del trabajo. El trabajo
comienza una vez que el plan ha sido aprobado. Durante este
Especificaciones
paso/ se realiza el trabajo técnico de acuerdo al plan y se identifi-
can cualesquiera variaciones para actuar sobre ellas y mantener el
proyecto en curso. El gerente del proyecto se coordina y se comu-
nica con el equipo del proyecto y la alta gerencia, y se asegura que
Figura 'l-2. La restricción triple
 20 Curtis R. Cook
Dentro del triángulo se localiza el alcance del proyecto, qre define
las fronteras del mismo en términos de requerimientos técnicos o es-
pecificaciones, y los límites de tiempo y costo. Es interesante observar
que son las restricciones lo que dan lugar al proyecto. Sin límites de
recursos, dinero o tiempo, habría poca necesidad de administrar el pro-
yecto. Claro está, en el mundo real, siempre hay restricciones y siempre
existe la necesidad de encontrar maneras eficientes de hacer el trabajo
con más rapidez, con menos costo y mejor. Tenga en cuenta que mien-
tras más estrechas sean las restricciones, mayor será la necesidad de
administrar el proyecto.
IJna vez que somos conscientes de estar trabajando en un proyec-
to, podemos usar la disciplina de la administración de proyectos para
realizar el trabajo. El Project Management Institute (pMI) define ü ad-
ministración de proyectos como "La aplicación de conocimientos, ha-
bilidades, herramientas y técnicas a las actividades del proyecto, para
cumplir los requerimientos de dicho proyecto"L La mayoría de loi ge-
rentes de proyectos exitosos dan una definición más detallada.
La administración de un proyecto es llevar a cabo el trabajo a
tiempo, dentro del presupuesto y de acuerdo a las especifica-
ciones.
El valor de la administración de proyectos
Los gerentes ejecutivos frecuentemente me preguntan porqué alguien
podría desear adoptar la administración de proyectos. Después de
todo, dirigir el negocio en la forma usual es más cómodo. y enfrenté-
moslo, a la mayor parte de la gente no le gusta los cambios y menos le
gusta operar con restricciones. Por tanto, ¿por qué elegir un método
que incluye restricciones y requiere un enfoque riguroso de la admi-
nistración del cambio? La respuesta simple es que el entorno compe-
titivo en el que operan casi todas las empresas requiere un enfoque
más disciplinado para obtener participación de mercado o incluso pára
sobrevivir. Y para proyectos que no son de negocios, este enfoque nos
ayuda a proceder de manera más organizada. Pero hay otras razones
específicas y bien documentadas para usar la administración de pro-
yectos, que cubriremos antes de seguir adelante.
Razón 1. Establece un solo punto de contacto y rendición de cuentas
para el éxito general del proyecto. La administración de proyectos
Panorama de la administración de proyectos 2L
simplemente no funciona a menos que el gerente del proyecto tenga
autoridad para descargar sus responsabilidades y rendir cuentas. LJna
de las fuerzas impulsoras de la administración de proyectos es la obvia
ventaja de potenciar a un equipo para que haga el trabajo sin tener que
preocuparse de las obligaciones usuales asociadas con su trabajo nor-
mal en la orgarrización. Al poner a cargo a una persona, los interesados
especial los clientes- saben a quién acudir con sus preguntas
-en
durante el diseño, la producción, las pruebas y el despliegue. Veamos
con mayor atención la autoridad,la rendición de cuentas y la responsa-
bilidad, pues son conceptos muy importantes.
La autoridad es el derecho a imponer cierto grado de disciplina.
lJn comandante militar posee la autoridad formal y legítima para
obligar a que se cumplan sus órdenes El presidente de una compañía
tiene la misma autoridad. Si la gente no cumple las "órdenes" del líder
formal, podrían aplicarse medidas disciplinarias o incluso un despido.
Los gerentes de proyectos tienen muy poca autoridad formal, pues
por lo general lideran equipos de personas que no le reportan a é1. Sin
embargo, los gerentes de proyectos pueden obtener de la alta gerencia
la autoridad formal necesaria por medio de un documento que des-
cribiremos después y que se llama protocolo del proyecto. Tenga presente
este documento mientras continuamos.
La rendición de cuentas significa que el gerente del proyecto debe
responder por la generación de evidencias visibles de progreso. En
otras palabras, el gerente del proyecto es responsable de los resulta-
dos, que generalmente se manifiestan como un producto físico o el
suministro de un servicio. Cuando la gente dice que debe "rendir cuen-
tas", se está refiriendo a que se espera que "produzca resultados".
La responsabilidad es la obligación de actuar sin necesidad de una
guía o autoridad formal. Es casi una obligación moral hacer lo correc-
to. A eso se debe que los libros gerenciales insistan en que la responsa-
bilidad no puede delegarse; es una obligación inherente. Un gerente
de proyecto que entienda el objetivo del mismo y esté comprometido
a lograrlo se siente responsable del resultado sensación de pro-
piedad del proyecto.
-una
Al conjuntar estos tres conceptos rendición de cuen-
-autoridad,
tas y responsabilidad- es fácil ver porqué al gerente de proyectos
puede exigírsele que produzca resultados solamente cuando se le ha
otorgaritr autoridad para realizar el trabajo y tiene una sensación de
22 Curtis R. Cook
responsabilidad por el resultado. Con ello estamos diciendo que la
tarea de un gerente de proyectos no es nada fácil.
Razón 2. Se enfoca en satisfacer las necesidades y expectativas del
cliente. Cuando el gerente del proyecto tiene la autoridad apropiada,
está potenciado para trabajar muy de cerca con el cliente para com-
prender sus requerimientos y mantener un diálogo continuo durante
su desempeño, para garantizar la satisfacción del cliente. Un cliente per-
cibe la diferencia cuando se adopta un enfoque de administración de
proyectos, porque su éxito como gerente del proyecto se mide en tér-
minos de qué tan bien se maneja la restricción triple al cliente
-darle de pre-
lo que se acordó que le proporcionaría, dentro de las restricciones
supuesto y tiempo que gobiernan al proyecto.
Razón 3. Mejora el desempeño con respecto al tiempo, el costo y las
áreas técnicas. Cuando la única responsabilidad de un individuo
-de
la cual depende su futuro- consiste en terminar un proyecto a tiempo,
dentro del presupuesto y de acuerdo a las especificaciones, esa perso-
na lo hará o "rnorítá en el intento", tal como se expresa coloquial-
mente. En ocasiones/ una vez que se ha nombrado a un gerente de
proyecto experimentado para manejarlo, 1o mejor que puede hacer la
gerencia es quitarse del camino. Esto tiene una desventaja en cuanto
que la presión sobre los miembros del equipo puede ser intensa
aclara expectativas y produce resultados. -pero
Razón 4. Genera resultados consistentes mediante la definición y
aplicación de un proceso en las unidades de negocio. Como lo pue-
den atestiguar muchas personas familiarizadas con el movimiento de
calidad, la aplicación de un proceso bueno y rígido a un problema
ayuda a eliminar desperdicios e ineficiencia. Cuando dicho proceso in-
cluye las mejoras prácticas y se aplica a toda la unidad de negocios, se
lograrán resultados superiores consistentemente. El problema en algu-
nas organizaciones es que existe ese proceso/ pero su uso es voluntario.
Esto no tiene sentido si el proceso puede generar mejores resultados de
negocios, pero en algunas empresas, la alta gerencia gasta dinero en
desarrollar procesos que no se hacen obligatorios. La única razón que
lo justifica es cuando el proceso es lento y burocrático. En tal caso, el
enfoque de este libro será de gran ayuda.
Razón 5. Se enfoca en administrar el alcance del proyecto y controlar
los cambios. Detallaremos este aspecto más adelante, pero uno de los
&t'é.¿¿'ay./.T
proyectos
Panorama de la administración de 23
principios fundamentales de la administración de proyectos es que sus
objetivos y alcance se definen desde un principio y no se permiten
cambios sin una autorización específica. Esto prácticamente elimina
el deslizamiento del alcance, que se define como un cambio de alcances
sin restricciones.
Razón 6. Ayuda a evitar desastres al administrar los riesgos. Piense
en un riesgo como cualquier cosa que pueda descarrillar al proyecto
de recursos, requerimientos mal definidos, clientes que cam-
-falta
bian de opinión con frecuencia, mal clima- lo que sea. En la planea-
ción del proyecto, el equipo discute en tormentas de ideas todos los
posibles impactos negativos para el proyecto y desarrolla respuestas
antes de la ejecución Como resultado, hay menos sorpresas y desastres
que amenacen a la consecución de los objetivos.
Razón 7. Refuerza a los equipos de proyectos y mejora la moral de
los miembros. Los desafíos significativos de desempeño crean equipos.
Una de las ventajas del entorno restringido en el que opera la mayor
parte de los proyectos es que crea un desafío instantáneo de desem-
peño. Como resultado, los equipos de proyectos se aglutinan con ma-
yor rapidez qrte los equipos funcionales. Además, a los seres humanos
generalmente nos gusta tener un objetivo claro en nuestro trabajo. Por
definición,los proyectos tienen objetivos específicos y medibles, y todo
mundo sabe cuál es su papel en alcanzarlos. Finalmente, nos encanta
terminar las cosas. Los proyectos tienen un principio y un final defi-
nidos. Cuando se termina el proyecto, celebramos y nos deleitamos
con la sensación de haber finalizado de haber terminado algo que
valió la pena. Todos estos factores--o un trabajo desafiante, objetivos
específicos y terminación --desembocan en un alta moral para los equi-
pos de proyectos.
Razón 8. Mejora el desempeño de las utilidades y hace ctecer al
negocio. Esta última razónes el resultado de las siete anteriores. El ren-
glón de utilidades mejora porque los equipos de proyectos son tanto
más efectivos realizar el trabajo ---como más eficientes
-permiten
menos recursos para lograrlo. Por otra parte, una buena
-utilizan
administración de proyectos resulta en una mayor satisfacción del
cliente, lo cual conduce a una mayor participación de mercado e in-
gresos más altos. La mayor satisfacción del cliente, acoplada a ope-
raciolrcs nrás eficientes, genera más utilidades.
24 Curtis R. Cook
Ejemplos de demasiada
adm inistración de proyectos
Quizás ya esté convencido de la necesidad de aplicar la administración
de proyectos. Pero, ¿qué sucede cuando se exagera y se aplica un exce-
so de administración de proyectos para el tamaño y complejidad del
mismo? La respuesta usual es un fracaso del proyecto, equipos desmo-
ralizados y gerentes frustrados. Veamos un par de ejemplos reales (con
los nombres cambiados, claro está).
Nuestro primer ejemplo es una gran compañía de la industria de
hardware de computadoras. La empresa X fue en un momento dado el
líder en su campo. Debido a algunos sonados fracasos de proyectos, la
gerencia decidió que necesitaban una buena administración de proyec-
tos. Buena decisión. El primer paso que dieron fue conjuntar un equipo
de todo el mundo para desarrollar una metodología de administración de
proyectos. Otra gran idea. Pero con el correr del tiempo, el alcance de la
metodología de proyectos se expandió con muy poco control de los
cambios. El equipo añadió pasos para manejar casi cualquier situación
posible. Gente adicional, más contratistas y especialmente más dinero,
fueron incorporados al proyecto. Cuando finalmente se obtuvo, el entre-
gable fue un enorme documento de metodología orientada a proyectos
en tres carpetas muy gruesas, un conjunto de dos panfletos describien-
do cómo proceder en cada uno de los cientos de pasos del proyecto y
un pequeño manual resumiendo todo el proceso.
El equipo de la oficina principal decidió que el proceso sería obli-
gatorio (nuevamente, nade de malo en ello si la metodología hubiera
sido amistosa para el usuario). Literalmente se le mandó a todo mundo
un paquete conteniendo la literatura y una nota aclarando que el pro-
ceso sería obligatorio Debemos aclarar que en el primer libro se presen-
taba una matriz aclarando que el proceso era escalable usarse
sólo ciertas partes para proyectos pequeños medianos -podían
y grandes-
pero el efecto impactante de de este conjunto de documentos sobre el
escritorio fue un fuerte disuasivo para siquiera abrir el paquete.
La empresa también gastó millones de dólares entrenando a sus
gerentes de proyectos, pero el entrenamiento fue genérico y no adap-
tado a la nueva metodología. Pero, tras unas cuantas sesiones, el di-
nero para el esfuerzo dejó de fluir. Después de todo, todo lo necesario
para administrar y completar proyectos ya estaba incluido en algu-
na parte de los libros.
Panorama de la administración de proyectos 25
Para los proyectos más grandes y complejos de la compañía, la
metodología y eI entrenamiento rindieron buenos frutos. Se usó un
software adecuado y la gente seleccionada para rcalizar estos grandes
esfuerzos sabía cómo hacerlos y qué partes de la tecnología tenía que
usar y cuáles ignorar. Pero, para el otro 80% de los gerentes asignados
a proyectos pequeños y medianos, la metodología era como un an-
cla. En sus intentos por usar el proceso y sus formatos, los gerentes de
proyectos se ahogaban en papeles. Algunos proyectos simplemente se
suspendieron y los quipos pasaron a hacer otras cosas la do-
cumentación era preciosa.
-pero
Más o menos un año después de la aplicación de la metodología,
la empresa realizó un auditoria global para determinar el porcentaje de
equipos que la estaban usando. ¿Resultado? ¡Menos del10%! La mayo-
ría de los gerentes de proyectos habían utilizado enfoques diseña-
dos en casa y / o procesos locales o regionales que ya existían antes de
los lineamientos corporativos. Como resultado, algunos proyectos fue-
ron exitosos y otros verdaderos desastres, sin lograrse las mejoras en el
porcentaje de proyectos completados a tiempo, dentro del presupues-
to y que cumplieran con los requerimientos de los clientes.
Durante los dos años siguientes,la mayor parte de los que habían
estado involucrados en la iniciativa habían sido despedidos o se ha-
bían ido voluntariamente a pasturas más verdes. La empresa, ahora
disminuida, todavía no tenía un proceso general para Proyectos peque-
ños y medianos tamaño de la mayor parte de los proyectos de una
-el
organización típica.
Nuestro segundo ejemplo se refiere a una compañía mucho más
pequeña .com del sur de California. Como todos sabemos, hubo
-una para la desaparición de estas pequeñas empresas de
muchas razones
Internet, pero una de ellas fue en buena parte la aplicación de demasia-
do proceso a proyectos de tamaño promedio. La empresa Y fue iniciada
por un par de emprendedores que tuvieron gran éxito al principio de
su aventura. Las ventas y utilidades crecieron y se prePararon Para una
oferta inicial de acciones al público. Durante las preparaciones, sur-
gieron algunos aspectos. Se dieron cuenta que no podían darse el lujo
de desarrollar "juguetes" y dejar que los clientes jugaran con ellos, pa-
ra después decidir si debían desarrollar sistemas de producción de las
aplicaciones más promisorias La gerencia sintió la necesidad de una ma-
yor consistencia en su enfoque y más éxitos comerciales. Necesitaban ser
capaces dc prede-cir bien sus utilidades para impresionar a los analistas
26 Curtis R. Cook Panorama de la administración de proyectos 27

del mercado de valores que evaluarían sus acciones. Por tanto, contrata- Nota
ron a un consultor para ayudarlos a desarrollar un proceso de adminis- L. Project Management Institute (PMD Standards Comitteen, A Guide
tración de proyectos, montaron una oficina de proyectos y controlaron to the Project Management Body of Knowledge, (Upper Darby, PA:
algunos de los que sobrepasaban sus presupuestos y tiempos. No era Project Management Institute ,2001), Pá9. 205.
una mala idea...
La primera señal de problemas surgió cuando se decretó que
todos los proyectos serían administrados usando un paquete de soft-
ware comercial. No se proporcionó entrenamiento sobre esta herra-
mienta y no se había desarrollado un proceso básico aplicable a toda la
compañía para manejar la administración de proyectos. Sin embargo,
la oficina de proyectos fijó nuevos lineamientos. Todo proyecto reque-
ría un protocolo múltiple, un plan detallado que típicamente cubría L5
páginas y reportes, diagramas y gráficas de gran complejidad, la mayor
parte de lo cual se producía con un paquete gráfico y no con un soft-
ware de administración de proyectos. Los gerentes de proyectos se pa-
saban todo el tiempo empujando papeles. Muy pronto se volvieron
administradores de proyectos, no líderes, y perdieron el respeto de la
gente que hacía el trabajo. No pasó mucho tiempo para que la "admi-
nistración de proyectos" fuera vista como un proceso burocrático que
no añadía valor y fue suspendida. La empresa regresó a sus métodos
particulares para manejar sus proyectos. Quebró en2002. Algunos de
sus competidores que habían adoptado los procesos, formatos y proce-
dimientos de suficiente administración de proyectos para controlarlos,
sobrevivieron y prosperan. Debo saberlo mis clientes.
Por consiguiente, la administración-sonde proyectos añade valor
sólo cuando se aplica en dosis apropiadas. Es mucho más inte-
-pero
ligente aplicar un poco, medir los resultados y donde sea necesario,
añadir enfoques más sofisticados, que ahogar a su mejor personal en
montañas de papeles.

Todos los proyectos neces¡tan

ser administrados-pero sólo lo
suficiente para reaLzar el trabajo
De acuerdo, usted está convencido de que la administración de proyec-
tos es buena para usted. Ahora ya es tiempo de profundizar en el pro-
ceso de administración justamente suficiente de proyectos y aprender
todas esas técnicas rápidas y fáciles para cristalizar los beneficios.
 lnicio del proyecto

T-
-I-tinicio del proyecto es el proceso formal de comenzarlo' El gerente
del proyecto verifita que se disponga de toda la información nece-
sariá pára empezar el proyecto y resume dicha información en el pro-
tocolo del proyecto ---el-único entregable de esta fase' Piense en cada
uno de loó cuatro Pasos del proceso de la administración del proyecto
como eventos con entradas y salidas. La entrada pfincipal necesaria
para arrancar un proyecto es algún tipo de documento de requerimien-
ios. Esto puede asumir una o más de varias formas:
. Especificacionesescritas
o Contrato con el cliente
. Orden de trabajo
¡ Solicitud de servicio
. Directiva Por correo electrónico
. Cualquier otro documento que exPrese la necesidad u objetivo
del proyecto
La principal salida es el protocolo aprobado del proyecto'
fa Figurá 2-L ilustra las áctividades que llevaa cabo el gerente del
proyecto durante el proceso de administración del mismo'
Destacándose en la figura las actividades del inicio'

¿Es esto un Proyecto?

io primero que debemos decidir es si se está trabajando en un Proyec-
to. Suena simple, pero a veces se presentan muchas confusiones en este
30 Curtis R. Cook Inicio del proyecto 3L

muy importante punto. Recuerde la definicióndeproyecfo y fin

-inicio
definidos, objetivo específico, etc. Ampliando esto un poco se genera
una lista de verificación que puede usarse para determinar si el trabajo
que se tiene en mente es un proyecto:
o ¿Tiene un principio y un final claros?
. ¿}{ay un objetivo específico y medible?
o ¿Es una clase especial de esfuerzo que requiere una solución
particular?
. ¿Se necesita una respuesta rápida?
e ¿Requiere coordinar y manejar varios elementos, sistemas o re-
cursos interdependientes?
Si las respuestas a estas preguntas son afirmativas, tiene en sus
manos un proyecto y la administración de proyectos le será útil. Si no
es así, estará realizando un trabajo conünuo, gobernado por las políti-
cas y procedimientos normales de su organización.

Arranque del proyecto

De acuerdo, es un proyecto. ¿Qué sigue? Sigue el arranque del proyecto,
que es relativamente simple pero muy importante. Se enfoca en deter-
minar quiénes son los participantes clave y en comprender sus papeles
y responsabilidades. Hágase las siguientes preguntas:
o ¿Realizaré yo todo el trabajo o habrá otros que contribuyan?
o ¿Quiénes formarán el equipo?
o ¿Quiénes usarán el producto final?
r ¿Quién especificará los requerimientos?
Desarrollar r ¿Quién aprobará el producto final?
pfoceso oe
control o ¿Quién paga las cuentas?
de camb¡os
o ¿Qué tan disponibles están los otros involucrados?
. ¿Tengo autoridad para pedir ayuda?
IJna manera simple de empezar es trazar un círculo con usted co-
mo gerente de proyectos en el centro y otros participantes en círculos
conectados al suyo, tal como se muestra en la Figura 2-2.Identifique
Figura 2-1. Diagrama de bloques del proceso destacando los pasos de inicio como mínimo a los siguientes participantes:
32 Curtis R. Cook

a Patrocinador del ProYecto

Gerente del ProYecto
El patrocinador'del iroyecto identifica a un gerente de proyecto
con la
a Gerente del ProYecto y habilidades relevantes
experiencia, co-p"ierróia, conocimiento Para
a Interesados clave en el ProYecto ad^ministrarlo exitosamente. ¿Qué cualidades debe tener un gran
ger-
ente de proyecto? Varias organizaciones han tratado de determinar
Casi
competenciás asociadas con el é*ito en el entorno de un proyecto.
aparecen en los
todas concuerdan que las que se listan a continuación
individuos de alto desemPeño:
Características de los grandes gerentes de proyecto
. Compromiso con el proyecto y el equipo
¡ Habilidades de comunicación
. Enfoque en el cliente
¡ Habilidad para tomar decisiones
o Habilidad para resolver problemas
o Habilidad para el manejo de conflictos
o Habilidad para energizar a los demás
Figura 2-2. Parlicipantes en el proyecto'
. Habilidad para persuadir e influir
¡ Habilidad para asumir la iniciativa
o Flexibilidad
Patrocinador del Proyecto . Capacidad de liderazgo
- esto es, habilidad pra motivar a los
El fatrocinador del pioy".to suele ser la persona que puede desple- demás a querer hacer ló que la gemcia considera como lo correc-
los fondos para el
luJ y ,."org-Elanizar lo, ."órrrto s y / o que Proporcionaaprobación final de to.Lacapacidaddeliderazgoincluyecualidadespersonales
iroy"cto. patrocinador eierce la autoridad de tales como empatía, integridad y honestidad'
coor-
ios usurrtos involucrados en el proyecto y se asegura que exista
Además de contar con casi todas estas característica, los gerentes
dinación y comunicación con ylntre los miembros de la alta gerencia'
debe de proyecto deben tener suficiente autoridad para desarrollar sus Pro-
C.ru.rdo ya se involucra el geiente del proyecto, el patrocinador
estar identificado y tener de hecho ya nombrado al gerente del Proyec- y""ior. Típicamente asumen una gran responsabilidady autoridad so-
2-l'
esto no sucede y queda en manos del gerente del bre sus proyectos y ejecutan las funcioes que se muestran en la Thbla
to. Algunas veces,
patroci-
p.oyuéto encontrar al "campeón" del mismo' A menos que el Interesados en el ProYecto
proyecto fallará sólo
nador esté identificado y séu utr campeón, el - Una vez nombrado, enire lás primeras cosas que debe hacer el
gerente
proyectos deb,en
será cuestión de tiempo. Por esta razón, los gerentes de del proyecto es identificar a todos los interesados-cualquiera que sea
mantenerse firmes y rehisarse a continuar si no se identifica al patrocinador' conjunto de
afeciadá por el proyecto. Todos los interesados tendrán un
hacer valer su posición
Esto puedé pu.""á, extraño, pero recuerde que expectatiia, y ér tárea del gerente del proyecto-determinar cuáles son
con el éxito'
es una característica de los gérentes de proyectos asociada y ,'i A alcance del proyecto eJsuficiente para satisfacerlos. De lo contrario,
¡No tenga temor de hacer lo correcto!
34 Curtis R. Cook Inicio del proyecto 35

el gerente del proyecto debe manejar las expectativas desde el principio

para evitar desastres.
Cuando existan dudas acerca de si un individuo o una organiza-
ción están involucrados en el proyecto, la mejor manera de proceder es
comunicarse directamente con el individuo en cuestión. Es una buena
idea desarrollar una lista de verificación para usted mismo y todos los
interesados potenciales considerando una gran diversidad de proyec-
tos, y usarla cada vez que inicie uno para asegurarse de no dejar fuera
a ningún interesado.

Establezca el exped¡ente o
carpeta del proyecto
A nadie le gusta el papeleo es una parte inevitable
-pero con proyectos pequeños,deellagerente
nistración de un proyecto. Incluso
admi-

debe asegurarse que se constituya un expediente del proyecto (que

puede ser simplemente una carpeta) y que contenga toda la documen-
tación importante generada en cada paso del proyecto. puede ser desde
una simple carpeta hasta un sistema de documentación en línea.
En la Thbla 2-2 se muestra una lista de comprobación de los do-
cumentos que debe contener el expediente del proyecto.

¿Qué neces¡ta saber antes de proceder?

una vez identificados los participantes clave y constituido el expedi-
ente del proyecto, éste realmente comienza. El gerente del proyecto
siempre debe hacerse las cinco siguientes preguntas al arrancar el
proyecto:
1. ¿Qué es? ¿Qué vamos a generar? ¿Qué se va a entregar?
2. ¿Quién lo necesita? ¿Quién es el cliente?
3. ¿Por qué lo estamos haciendo? ¿Cuál es el problema subya-
cente que estamos tratando de resolver o la oportunidad que
estamos buscando?
4. ¿Soy quien debe rendir cuentas del éxito del proyecto? Si no
lo soy, ¿quién lo es?
5. ¿Cuál es mi autoridad para que esto suceda? Si no tengo la
autoridad, ¿quién la tiene? ¿Por qué no la tengo yo? ¿Cómo
Tabla 2-1 . Responsabilidades y autoridad del gerente del proyecto puedo corregir esta deficiencia?

36 Curtis R. Cook
a Protocolo del proyecto
a Documentación la reunión de arranque
a Plan del proyecto
- Eskuctura detallada del trabajo
- Programa de trabajo
- Presupuesto del proyecto Entra figura
- Plan de recursos
- Plan de comunicaciones
- Plan de control de cambios
- Plan de riesgos
a Reportes de avance
a Solicitudes /aprobaciones de cambios
a Minutas de las reuniones
a Lecciones aprendidas
a Lista
Tabla 2-2. Responsabilidades y autoridad del gerente del proyecto.
A menos que se conozcan las respuestas a estas preguntas, el
proyecto no debe seguir adelante. Permítanme compartir un ejemplo
de un proyecto que casi fracasó debido en gran parte a que su gerente
simplemente carecía de autoridad para llevar a cabo el trabajo.
El proyecto consistía en renovar una pista de aterrizaje que se ha-
bía deteriorado debido a su antigüedad, el clima y un uso intensivo.
lJna nueva generación de aviones iba a usar la pista, por lo que tenía
que ser repavimentada para manejar el tráfico. Yo era el gerente del
proyecto eso pensaba. La mayor parte del trabajo lo iba a hacer un
-o
contratista, por lo que una de las primeras cosas que hicimos fue solici-
tar cotizaciones para seleccionar al más adecuado' Nunca se preparó
un protocolo del proyecto y no me aseguré de mi autoridad- creí que
todo mundo sabía que yo estaba " a cargo" , ¡Era mucho más joven en
aquel entonces!
Noté que, al convocar una reunión de estado de avance del pro-
yecto, algunos de los participantes clave de nuestra división de ingenie-
ría no asistieron y me costó mucho trabajo que el gerente de proyectos del
contratista me prestara atención. Pero hice lo mejor que pude y perseveré.
Inicio del provecto 37
Todo iba bien hasta que el contratista comenzó a retrasarse. Comenzó a
colar concreto a mediodía, con una temperatura superior a los 38" C (el
proyecto era en Phoenix, Arizona). Esto no sólo iba en contra de las me-
jores prácticas de la industria, sino que además constituía una violación
directa de las especificaciones del contrato. El agua se evaPoraba con
tal rapidez que se formaron grandes grietas que debilitaban al concreto.
Cuando me enteré de lo que estaba pasando, me Puse mi casco y
me dirigí hacia el lugar de trabajo con un ingeniero experto. Cuando
llegué, le dije al contratista que tendría que destruir todo el trabajo que
había hecho y volver a colar el concreto en la noche, cuando la tempe-
ratura fuera más baja, tal como lo había hecho con anterioridad. Observé
un intercambio de miradas furtivas entre nuestro ingeniero y el gerente
de proyecto del contratista y comencé a sospechar. Terminamos nues-
tra reunión sin que se hiciera comentario alguno y confronté a nuestro in-
geniero cuando regresamos a la oficina. Resultó ser que el ingeniero
había aprobado que se colara el concreto durante el día, siempre y
cuando su contenido de humedad se mantuviera suficientemente alto
para evitar cuarteadoras. Nuestro ingeniero había aprobado el cambio
con respecto al contrato sin molestarse en consultarme ni informar a
otros miembros del equipo para evaluar el impacto en el costo del pro-
yecto, el programa o las especificaciones técnicas. Cuando acudí al
"jefe" para aclarar mi autoridad, averigüé que quien realmente estaba
" a cargo" de la parte técnica del trabajo era el ingeniero. El único pro-
blema era que ni yo ni el resto del equipo lo sabíamos.
Naturalmente, estaba molesto, pero lo más importantes es que
el proyecto casi fracasó. El contrato tenía una cláusula de daños por el
incumplimiento de la fecha de terminación o de las especificaciones
técnicas, pero las acciones del ingeniero relevaron parte de las resPon-
sabilidades del contratista. El concreto se cuarteó y tuvimos una larga
batalla legal para obligar al contratista a regresar, destruir lo hecho y
volver a hacer el trabajo de acuerdo a las especificaciones pactadas. Si
el cambio se hubiera procesado correctamente, nunca hubiéramos
aprobado el procedimiento no estándar y la pista se hubiera termina-
do adecuadamente, con lo que nos habríamos ahorrado el montón de
dinero gastado en honorarios de abogados.
La lección de este caso es que el gerente del proyecto es el resPon-
sable del éxito total del proyecto y debe tener la autoridad para dirigir
al equipo y, cuando suceda algo como esto, acfuar para que el proyecto
se mantenga dentro del programa y en cumplimiento de las especifica-
38 Curtis R. Cook Inicio del proyecto 39

ciones técnicas. En retrospectiva, la lección que aprendí nunca

-que
olvidaré- fue asegurarme de contar con la autoridad para manejar el
proyecto desde antes de iniciarlo y que todos los miembros del equipo
conozcan sus papeles, responsabilidades y autoridad relativa.
El inicio del proyecto, incluyendo la preparación del protocolo, es
el primer paso importante para comprender esto y comenzar el proyecto Patrocinador del proyecto
con el pie derecho.

El Protocolo del proyecto

La mejor manera de arrancar un proyecto de tal manera que el patro-
cinador y el gerente conozcan el propósito del proyecto y su relación Otros interesados en el proyecto
con la estrategia, otros proyectos y operaciones, es crear unprotocolo del
proyecto o acta constitutiva. El protocolo reconoce formalmente Ia exis- Responsabilidades de los interesados
tencia de un proyecto, identifica a su patrocinador, a su gerente y a
otros interesados, describe el objeüvo y el alcance general, e incluye mu-
Objetivos de negocios
chos de los detalles necesarios para que el patrocinador tome la decisión
de autorizar o no el proyecto. Si bien el patrocinador es "oficialmente" el
originador del protocolo, el gerente del proyecto suele asumir la tarea de Objetivos del proyecto (emrnn)
prepararlo para que sea firmado por el patrocinado. En la Figura 2-3 se
muestran los principales elementos de un protocolo, que a continuación Resultados entregables
se discuten con suficiente detalle para permitirle preparar su propio
protocolo para sus proyectos "reales". Incluso si usted ya está traba-
jando en proyectos sin tener un protocolo, es una buena idea analizar Fecha de terminación
sus elementos para determinar si carece de alguna información. Esto
quizás explicará algunos de los problemas que está teniendo con cier- Suposiciones
tos proyectos.
Relación con los objetivos estratégicos y/o otros proyectos
Nombre del proyecto
Esto se explica por sí mismo, pero si no se le ha asignado un nombre al
proyecto cuando usted comience a participar en é1, hágalo y diviértase.
Cuando reúna al equipo por primera vez, piensen en algún nombre Estamos de acuerdo en que es un proyecto viable. Autorizamos que se inicie el
atractivo. Considere también acuñar alguna frase o lema que expre- proceso de planeación.
se el objetir¡o del proyecto. He visto lemas tales como "Los liquida-
dores bebidas para liquidar su sed". Otro simpático lema
-Servimos
que vi impreso en una camiseta para un equipo de exploración subma-
rina decía: "Sumérjase profundo, viva a poca profundidad". Esto le da
una idea de cómo hacerlo divirtiéndose. Figura 2-3. Protocolo del proyecto.
Hablando de camisetas, es una gran manera de construir la identidad del
equipo. Considere esta historia que de muestra el "poder de la camiseta".
40 Curtis R. Cook
A.dy Roddick, un fenómeno tenístico norteamericano, acababa
de terminar un juego triunfal en el tomeo del All-England Tennis Club de
2004. Lo estaban entrevistando para la televisión y traía puesta una
camiseta de la Copa Davis. Antes de esto, Roddick no había decidido
si participaría en la Copa Davis o los Juegos Olímpicos, y sin embargo,
aparecía en la pantalla portando esa camiseta. Cuando se le preguntó
si estaba deseoso de competir para los EUA, contestó diciendo algo pa-
recido a lo siguiente, "Sí, es sólo una camiseta, pero cuando me la puse
me di cuenta que era parte del equipo que representaría a nuestro país.
Esto realmente me motivó y estoy ansioso por incorporarme al equipo
de Copa Davis.
¿La moraleja de esta historia? Cosas como las camisetas, tarros para
caféy otros artículos que ayudan a establecer la identidad de un equipo,
son formas valiosas de elevar la moral --de ayudar a sus miembros a
ser conscientes de que son de hecho un equipo y no sólo un grupo de
individuos talentosos. Un jugador de tenis millonario con una cierta ac-
titud displicente, se siente ahora como parte del equipo. Si funcionó
para que el capitán del equipo enlistara a Andy Roddick, es probable
que también funcione para usted.
Patrocinador del proyecto
Regishe el nombre de la persona que autoriza el proyecto. El patroci-
nador proporciona los fondos, establece las prioridades de los proyec-
tos y tiene un nivel suficientemente alto para resolver los asuntos de
recursos.
Gerente del proyecto
Registre su nombre en este cuadro. Usted es la persona responsable del
éxito general del proyecto.
Gliente
Ya sea un proyecto interno o externo, dicho proyecto tiene un cliente.
Se trata de la persona o entidad que será el principal beneficiario de sus
esfuerzos. Registre el nombre de esa persona o entidad.
Otros interesados en el proyecto
Se trata de una información crucial que muchas veces se menosprecia.
Un interesado se define como un individuo o una organización invo-
lucrados en el proyecto o que serán afectados por el mismo. ¿Puede
imaginarse no hablar con un interesado clave durante el inicio o la
planeación de un proyecto? No tendría sentido y sin embargo, sucede
Inicio del proyecto 4L
con frecuencia. Si el proyecto depende de que los interesados propor-
cionen recursos y no se les ha consultado, obviamente se sentirán mo-
lestos y renuentes a cooperar. Es responsabilidad del patrocinador
coordinarse con los interesados incluso desde antes de nombrar al ge-
rente del proyecto. Sin embargo, algunas veces esto no sucede. En estos
casos, recae sobre los hombros del gerente del proyecto realizar esta
tarea. Identifique a todos los interesados, hable con ellos y convénza-
los antes de arrancarlo. Es una buena inversión de su tiempo.
Responsabilidades de los interesados
Anote el nombre de todos los interesados con los que haya hablado, así
como sus responsabilidades asociadas con el proyecto. Debe ser breve
ejemplo, puede registrar "George Johnson, gerente, división de
-por
compras; ejecutar contrato con tres analistas para apoyar el diseño del
sistema". Un enunciado simple sobre la contribución del interesado es
suficiente por ahora para sostener las conversaciones con ellos. Esto le
permitirá saber si le falta algo.
Objetivos de negocios
¿Cuál es la fuerza impulsora del proyecto? ¿Cuál es la necesidad del ne-
gocio? Escriba esto en este bloque. Si no comprende la relación entre es-
te proyecto y los objetivos de negocios, averígüelo antes de continuar.
Objetivos del proyecto
Por definición, todo proyecto tiene un objetivo. Pero, para que sea va-
lioso en guiar al equipo y la subsecuente evaluación del proyecto, con-
viene que el objetivo cumpla las reglas del acrónimo EMARR:
Específico. ¿Cuál es exactamente el resultado buscado? ¿Qué se debe
entregar? ¿Qué espera el cliente ver al finalizarse el proyecto?
Medible. En la era actual del desarrollo de proyectos se pone más énfa-
sis en definir, durante la preparación del caso de negocios, la métrica
que se usará para evaluar si el proyecto fue un éxito o un fracaso. ¿Son
estos parámetros de desempeño que deben cumplir los resultados,
funciones que el producto o el sistema deben exhibir, incluyendo los
niveles de satisfacción del cliente o usuario que deben cumplirse?
Todas estas cosas son medibles.
Acordado. Todos los interesados deben estar de acuerdo en que los
postulados del protocolo tienen un impacto en ellos o bien que influi-
 Curtis R. Cook
42
rán para proporcionar recursos u otro tipo de ayuda. La mejor manera
con
de garantizar la comprensión es comunicarse con ellos
-reúnase
que ano-
cada interesado y discuta los elementos del protocolo. Pídales
ten sus iniciales o su firma, o bien que confirmen por correo electrónico
que están de acuerdo con los objetivos del proyecto.
Realista. Mantenga el objetivo razonable y realista en concordancia
ilusionismos. Cuando
con el tiempo y los recursos disponibles
tenga dudas, hable con el patrocinador. La
-no
mayor parte de los gerentes
de producto son personas positivas y capaces, pero éste es el momen-
to de realismos sobrios. Recuerde que está estableciendo expectativas con
las que usted y su equipo tendrán que vivir durante todo el proyecto.
Restricción de tiempo. Todo proyecto tiene un principio y un final fini-
tos. Si no se menciona en otra parte del protocolo, agregue las fechas
del periodo en este bloque.
Res u ltados entregables
Liste los resultados entregables específicos que generará el equipo del
proyecto, incluyendo los siguientes:
o LJna descripción del hardware o los productos tangibles que se
usarán o crearán en la solución'
o I-Ina descripción del software que se usará o se creará.
o dibilidad disminuirá y su diálogo con el patrocinador será... digamos
Identificación de cualesquiera servicios que deben ProPor-
cionarse como parte de la solución, tales como entrenamiento,
guía, asistencia o bien seguimientos y garantías'
Cuando se conozcan, deberán identificarse las exclusiones, pues
los interesados suelen suPoner que lo que no está explícitamente ex-
cluido está incluido.
Fecha de terminación del ProYecto
Añada la fecha de terminación si la conoce. si no se ha fijado una fe-
cha, algo está mal. Créame, alguien tendrá una expectativa muy defi-
nida de cuándo debe finalizarse el proyecto y su trabajo como gerente
del proyecto consiste en documentarla en el protocolo. También iden-
tifique, siempre que le sea posible, los principales referentes, esto es,
los hechos o acontecimientos que se usarán para medir el progreso. Si
no sabe cuáleS Son en este momento, no Se preocupe. Se reunirá muy
Inicio del proyecto +J
pronto con el equipo y discutirán los referentes, las tareas y el progra-
ma de trabajo.
Presupuesto del proyecto
Incluya el presupuesto del desarrollo completo del proyecto si lo cono-
ce. No acepte una frase de "por determinarse". Como en el caso de la
fecha de terminación, alguien, debe ser el patrocinador- conko-
la un presupuesto finito para
-y
este proyecto, que debe registrarse en el
protocolo. Sin embargo, puede muy bien suceder que los fondos de
un proyecto provengan del presupuesto de un departamento y que no
estén separados. Incluso en estos casos, es imperativo que el gerente
del proyecto sepa cuánto dinero y otros recursos podrán utllizar.
Suposiciones
No puedo exagerar la importancia de documentar las principales su-
posiciones en las que están basados los demás elementos del protocolo'
Liste los factores o situaciones que usted suPone que existirán o no exis-
tirán al penetrar en la fase de planeación. Por ejemplo, si no se conoce
con exactitud la fecha en la que dispondrá de un cierto recurso, el
equipo debe hacer una suposición razonable en cuanto a dicha fecha y
registrarla como suposición. Si usted suPone que todos los recursos
clave estarán disponibles cuando se necesiten, que contará con los fon-
dos, que no surgirán cambios en el alcance, deberá documentar todo
esto aquí. Tenga cuidado de no suponer que no existen riesgos. Su cre-
que interesante. Haga suposiciones razonables, documénteles aquí y
discútalas con el patrocinador. Su objetivo es contar con una idea clara
del entorno y los retos que enfrentará como gerente del producto.
Relación con los objetivos estratégicos
y otros proyectos
Como se muestra en la Figura 2-4, todo producto debe tener una
relación con un objetivo estratégico o cuando menos con la unidad de
negocios para la que se va a desarrollar el proyecto. Y no está por de-
más señalar que todo producto está relacionado con cuando menos un
proyecto y muy probablemente con otros más. A menos que el gerente
del proyecto y el patrocinador sean conscientes de esto, se presentarán
problemas cuando surjan conflictos de recursos entre varios produc-
tos. Es un trabajo arduo obtener esta información, pero la inversión
reclitúa en eliminar el caos y una implantación con menos problemas.
44 Curtis R. Cook Inicio del proyecto 45

Responsabilidades y firma del patrocinador a Forma el protocolo del proyecto.

Cuando ya se hayan discutido y acordado los elementos del protocolo
con el patrocinador y los interesados clave, es tiempo de que el patroci-
nador firme el documento. Nótese que por lo general, otros interesados
suelen estampar sus iniciales en una hoja de coordinación o enviar un
correo electrónico diciendo que han revisado el protocolo y están de
acuerdo en apoyarla. Al firmar el documento, el patrocinador del pro-
yecto está indicando que proporcionará los fondos suficientes para su
desarrollo y que descargará las demás responsabilidades típicas que se
requieren de un patrocinador, tales como las siguientes:
a Participa en las revisiones y la resolución de problemas.
Distribución del protocolo
lJna vez aprobado el protocolo, se deben distribuir copias a los miem-
bros del equipo del proyecto y a los interesados internos. No es acon-
sejable disiribuirlo a los interesados externos, tales como proveedores
y consultores, cuando la información de presupuesto y riesgos sea con-
fidencial.
Transición a la fase de Planeación
Cuando el protocolo ya haya sido firmado y distribuido, el gerente de
proyecto está listo para integrar el equipo de trabajo que le ayudará a
áesárrollar el plan. Si se trata de un proyecto muy pequeño, usted y el
equipo pueden ser una sola persona. Gran parte de la información
inituiaa en el protocolo se utilizarápara el plan, pero éste es más deta-
llado y constituye el mapa que el equipo usará para completar el pro-
yecto exitosamente.

Figura 24. Relación estratégica con otros proyectos.

Establece y comunica el caso de negocios y la alineación con el

proyecto.
a Fija el alcance y describe con claridad las expectativas.
a Selecciona y nombra a un gerente de proyecto.
a Actúa como mentor del equipo y está disponible y accesible.
a Proporciona y garantiza el presupuesto requerido.
a Fija la estimación inicial de la fecha de terminación del
proyecto.
Participa con el gerente del proyecto en la definición del pro-
yecto y el protocolo.
 Fundamentos
de la planeación

I-
t-l
- principio directriz de la planeación del proyecto es mantenerla
tan simple como sea posible, dependiendo del tamaño de dicho pro-
yecto. Para proyectos pequeños, el plan puede consistir de dos o tres
páginas, mientras que en los proyectos grandes será mucho más deta-
llado. El plan del proyecto es el mapa para ejecutarlo y cualquiera que
sea su tamaño, debe incluir y cubrir los siguientes elementos:
e Resumen del proyecto: Un resumen ejecutivo del origen del
proyecto y sus objetivos.
o Estructura de división del trabajo (EDT): La lista de tareas.
. Asignaciones de recursos: Quién va a hacer el trabajo.
. Programa del proyecto: El programa detallado de tiempos y la
fecha de terminación.
. Presupuesto del proyecto: Cuiínto dinero está asignado al
proyecto.
. Evaluación de riesgos: Qué puede salir mal y que acciones y
reservas deben incluirse en el plan para mitigar los eventos de
mayor riesgo.
. Comunicaciones: Cómo planea el equipo comunicarse, reunir-
se y reportar los avances.
. Proceso de conhol de cambios: Cómo se manejariín los cambios.
 48 Curtis R. Cook
La manera más rápida de desarrollar el plan consiste en reunir al
equipo del proyecto y tener una sesión de tormenta de ideas para cap-
turar y registrar la información necesaria. use técnicas y materialés
simples, tales como notas adheribles o un rotafolios, y después genere
un plan preliminar para_que el equipo lo revise. LJna vez que el e-quipo
esté de acuerdo con el plan, el gerente del proyecto se reúne.o., ét pu-
trocinador, hace los ajustes necesarios y pone el plan en su forma final
para su aprobación. Cuando ya ha sido aprobado, el plan se convierte
en lo que se conoce como línea base. En eite capítulo nos concentrare-
mos en los fundamentos de la planeación de pioyectos. En el Capítu-
lo 4 introduciremos algunas técnicas más avanzadas, tales como el
análisis de ruta crítica, para su aplicación a proyectos más complejos.
El proceso de planeación
El protocolo del proyecto es la herramienta principal de la planeación.
Proporciona toda la información que el gerénte del proyecto necesita
para avanzar. Imagine por un momento lo que sería empezar ur-pro-
yecto sin esta información ----como disparar en la oscuridád esperando
dar en el blanco. si usted se llega a encontrar en este tipo de si-tuación,
¡u¡{e hlber llegado el momento para aplicar una de las principales
habilidadesde los gerentes proyectos; seaisertivo y manténgase firme.
Asegúrese de contar con un protocolo firmado.
La planeación de proyectos es un proceso bastante directo. El
equipo del proyecto descompone los objetivos en una lista de ,'trozos', de
trabajo manejables, que en su conjunto reciben el nombre de estructura
de diaisión del trabajo (EDT) o, más comúnmente, una lista de tareas.
Después de que el equipo haya creado la EDT, se identifican las de-
pendencias de las tareas. En proyectos pequeños, esto es algo intuitivo
y obvio, pero en los-de gran tamaño eslrabajo duro. Esta aóción, junto
con el cálculo de la duración de cada tarea, resultará en la obtención del
programa del proyecto y revelará la ruta crítica. (Definiremos y discu-
üremos la ruta crítica posteriormente.) una vez que se han asignado los
recursos a las tareas de la EDI el programa del próyecto puedeiefinarse,
analizado en cuanto a,sus riesgos y preparadó pára su aprobación.
Dependiendo de la magnitud del proyecto, el equipó puede gene-
rar una diversidad de planes subordinados, tales como .tr, ptur, de-ries-
gos/ un plan de comunicaciones y un plan de control de cambios del
alcance. En proyectos pequeños, éstal son simplemente secciones o
Fundamentos de la
párrafos del plan general. una vez reunida y documentada toda la infor-
mación, el patrocinador aprueba el plan y el equipo está autorizado
para continuar y ejecutar el plan.
El principal entregable del paso de planeación es el plan del pro-
yecto, que define en detalle:
. Qué se va a hacer (la ror)
o Quién hará el trabajo (asignaciones de recursos)
. Cuóndo se hará el trabajo (el programa del proyecto)
o Cuánto costará el proyecto (el presupuesto)
o cómo se manejará el proyecto en términos de control de los
cambios de alcance, reportes de avance y control general de las
variaciones.
Considerando en conjunto con el protocolo del proyecto, el pran
del proyecto conjunta en un solo lugar virtualmente todo lo que se
sabe del mismo.
¿Guánto tiempo debe dedicársele
a la planeación?
con frecuencia me preguntan cuánto tiempo debe dedicarse a la pla-
neación. En nuestras sociedades occidentales, casi siempre tenemos
prisas para seguir adelante. Como resultado, usamos poCo tiempo en
la planeación y demasiado en discusiones durante su ejécución. En con-
traste, las sociedades orientales pasan más tiempo planeando y lo-
grando consensos antes del trabajo y la impleméntación es basiante
tersa. Nuestra meta es dedicar a la planeación el tiempo suficiente para
Iograr una comprensión clara de lo que se requiere pára alcanzar ei ob-
jetivo del proyecto.
Cgmo regla general, los equipos de proyectos deben pasar un mí-
nimo del 5% de la duración del mismo en la fase de planeación. casi
siempre se requiere más tiempo, pero éste es el mínimo. por ejemplo,
digamos que usted quiere construir una nueva plataforma de despacho
y que cree que el trabajo le tomará unos 3 días (24 horas de trabajo)
para hacerlo. El cinco por ciento de 24 horas es sólo 72 minutos.
¡úsé
mucho más tiempo planeando la cena del día de acción de gracias!No
obstante, al aplicar la regla general a nuestros proyectos en el trabajo,
gcneralmente se produce una reacción negativa de los gerentes y los
50 Curtis R. Cook
miembros del equipo por el tiempo gastado en la planeación. Escucha-
mos frases tales como "Sigamos adelante podemos perder el
tiempo en planes elegantes". Lo que realmente-no
est¿ín diciendo es que no
tenemos tiempo para planear, pero sí lo tenemos para reaccionar a las
consecuencias negativas que indudablemente surgirán si no hacemos
una buena labor de planeación desde el principio. Éste es un buen mo-
mento para practicar nuevamente su actitud de firmeza. Insista en
tomarse una cantidad razonable de tiempo para planear el proyecto y
se ahorrará muchos sinsabores y tiempo de reacción ante las emer-
gencias posteriormente.
Formando el equipo central
El elemento más importante del proyecto es el equipo de trabajo. El
equipo del proyecto planeará, implantará y monitoreará el trabajo
desarrollado. El gerente de proyecto es responsable de integrar y man-
tener un equipo cohesivo, funcional y motivado, capaz de realizar el
trabajo tal como se planeó.
La mayoría de los gerentes de proyectos de poca experiencia que
han sido promovidos de las filas técnicas dan por sentadas las habiti-
dades de la gente y, como resultado, no integran equipos de alto de-
sempeño. Si bien no está dentro de los propósitos de este libro entrar
en detalles de cómo integrar equipos, podemos proporcionar la infor-
mación "justamente suficiente" para hacerlo: Para obtener mayor in-
formación, recomiendo altamente el libro del Dr. ]im Lewis, Project
Leadership (véase la sección de lecturas adicionales).
Sin embargo, como mínimo, usted debe lograr lo siguiente para
tener probabilidades de formar un equipo cohesivo:
. Identifique a los miembros clave basándose en la naturaleza
del trabajo.
o Obtenga el compromiso de los miembros del equipo. (Si es de-
masiado pronto para conocer a los miembros del equipo, ob-
tenga el compromiso de los proveedores de recursos. Si logra
hacer un buen trabajo coordinando el protocolo del proyecto
con los interesados, esto no deberá ser difícil.)
o Asigne papeles y responsabilidades en el equipo.
. Asegúrese que el equipo cuente con los recursos necesarios.
Fundamentos de la planeación 51
o Convoque a una reunión de inicio para que el equipo se conoz-
ca y se genere la excitación y el compromiso (reparta esas ca-
misetas).
El gerente del proyecto debe participar directamente en la interac-
ción y operación cotidiana del equipo. El liderazgo es quizás la habili-
dad más significativa que el gerente del proyecto aporta al mismo y el
uso de esa habilidad siempre debe ser evidente. Como gerente del pro-
gerente funcional- es responsable de motivaq,
-noal el
yecto, usted
alentar y liderar equipo. De hecho, durante el desarrollo del proyec-
to, usted es el jefe. Formar un equipo efectivo es un requisito para que el
proyecto avance; sin esto, no podrá hacerse bien.
Actividades de planeación
La Figura 3-1 ilustra las actividades que el gerente de proyecto lleva a
cabo durante la segunda fase,la planeación del proyecto. Veremos ca-
da una de estas actividades, de tal manera que, al terminar el capítulo,
será capaz de preparar un plan para sus proyectos reales.
Revise los requerimientos del proyecto
Un viejo axioma de la administración de proyectos dice "No resuelva
el problema equivocado de manera perfecta". Esto simplemente sig-
nifica que debe tomarse el tiempo para pensar bien en el plan antes de
proceder a su ejecución. Y este primer paso del proceso de planeación
consiste en analizar los requerimientos con una mentalidad abierta,
hablar con el cliente y comprobar que nada ha cambiado desde la ela-
boración del protocolo del proyecto. Es decir, verifique que estará re-
solviendo el problema correcto.
Aclare los papeles y responsabilidades
Ya hemos gastado bastante tiempo en determinar quiénes están en el
equipo, pero en este punto es cuando el gerente del proyecto respira
profundamente, estudia los objetivos y restricciones generales del pro-
yecto y decide a quienes quiere en el equipo. Es siempre una combina-
ción de a quiénes quiere y quiénes están disponibles, y estrictamente,
son los gerentes funcionales los que asignan a la gente apropiada al
¡:royecto. Pero ésta es su oportunidad para seleccionar a su equipo y
comenzar a trabajar con ellos para que todos comprendan los diferen-
tcs papeles y responsabilidades.
52 Curtis R. Cook Fundamentos de la planeación 53

Conduzca la reunión de arranque del proyecto

Figura 3-1. Diagrama de bloques del proceso destacando los pasos de planeación
Después que se han identificado y asignado los miembros del equipo
del proyecto, el siguiente paso es conducir una "reunión de arranque".
Esta reunión es una introducción al proyecto para los miembros del
equipo que no fueron parte del esfuerzo preliminar de planeación,
para el personal gerencial que aporta los miembros, Para la gerencia
ejecutiva y paraotros interesados en el proyecto. En esta reunión, el ge-
rente del proyecto lo describe, trabaja para establecer la identidad del
equipo y genera una sensación de excitación por el proyecto.
Como gerente del proyecto, la reunión de arranque es su primera
oportunidad para demostrar su liderazgo, Por lo que conviene seguir
las siguientes reglas:
1. Empiece la reunión a tiempo.
2. Logre sus objetivos usando una agenda.
3. Termine la reunión a tiempo.
Simple, ¿no es cierto? Pero, ¿cuándo fue la última vez que asistió
a una reunión que empezó y terminó a tiempo y se lograron los obje-
tivos? Usted estará demostrando estos valores en esta reunión, por lo
que debe hacerlo bien.
El formato de la reunión de arranque depende del tamaño y la
complejidad del proyecto más grande sea éste, más formal
-mientras
debe ser la reunión. Para la mayor parte de los proyectos, una agenda
simple y un máximo de L hora son suficientes para que el proyecto em-
piece bien. Y para equipos virtuales con proyectos pequeños, una lla-
mada telefónica puede bastar.
En la reunión de arranque, el gerente del proyecto debe establecer
una atmósfera de retos, trabajo en equipo y colaboración entre sus
miembros. Los integrantes del equipo deben sentirse excitados ante el
proyecto y sus papeles individuales. Considere usar la lista de la Tabla
3-1 para asegurarse de cubrir todo en su preParación para la reunión.
Acabo de mencionar la agenda. Para garantizar que se cubran
todos los aspectos durante esta reunión ser una de las Pocas
ocasiones en que estén juntos -puede
en un solo lugar todos los individuos
clave para el proyecto- use una agenda que yo he usado durante
las dos últimas décadas. Funciona, por lo que le pido que se sienta en
libertad para aplicarla a sus proyectos reales.
54 Curtis R. Cook
. Prepare un resumen de los objetivos de la reunión, destacan-
do las oportunidades que este proyecto representará para la
organización y para los miembros del equipo. Cubra cualquier
aspecto especial del proyecto que pueda presentar retos más
allá de lo normal.
o Prepare un panorama del proyecto que resuma los requeri-
mientos del negocio y los planes actuales para satisfacer dichos
requerimientos. Asegúrese de referirse a los elementos del
protocolo del proyecto, incluyendo las restricciones de pre-
supuesto y tiempo. Actualice al equipo en cuanto a los logros
del proyecto.
o Programe que el patrocinador del proyecto hable por 10-15
minutos sobre su opinión de la importancia del proyecto.
. Discuta los papeles y responsabilidades de todos los miem-
bros del equipo y otros interesados, si es que están presentes.
. Discuta las comunicaciones. ¿Qué información debérá inter-
cambiarse? ¿Quién necesita tenerla? ¿Qué formará asumirá?
¿Cuándo se realizarán las reuniones del proyecto?
. para programar, presupuestar, asignar recursos, controlar los cambios
Usando como guía el programa del proyecto en el protocolo,
discuta los cuestionamientos a dicho programa y la forma en
que el equipo podrá cumplir con la fecha planeada para su
terminación. Presente los entregables del proyecto y discuta
los eventos importantes.
r Programe un taller de planeación para que el equipo central
genere el plan del proyecto.
o Determine qué acciones de seguimiento se requieren a partir
de esta reunión y planee asignar responsabilidades acordes
con esto, para que la planeación del proyecto pueda proseguir.
o Lleve comida.
Tabla 3-1 . Lista de verificación de la reunión de arranque.
Fundamentos de la planeación 55
Es una buena práctica tomar unas cuantas notas durante la reu-
nión y distribuirlas, junto con las acciones acordadas, a todos los asis-
tentes a la reunión. En muchos casos, el gerente del proyecto conducirá
una reunión de planeación detallada inmediatamente después de esta
reunión. Recuerde notificar por adelantado a los miembros clave del
equipo de proyecto, pues las sesiones de planeación toman más tiem-
po que una simple reunión de arranque.
Nota: Asegúrese que el patrocinador del proyecto tenga la oportuni-
dad de participar en la reunión de arranque. Es una oportunidad para
que él demuestre su apoyo al proyecto y al equipo, y la forma en que
encaja en la misión y la estrategia de la organización.
Genere una estructura de la división del trabajo (EDT)
El término estructura de Ia diuisión del trabajo puede sonar imponente,
pero es una frase de amplio uso que simplemente significa una lista de
las tareas que deberán llevarse a cabo. Una EDT es un árbol genealó-
gico de todos los trabajos del proyecto requeridos para suministrar un
producto o servicio finales. Proporciona la estructura para planear y
controlar la totalidad del proyecto durante toda su duración.
La EDT es la clave para el resto del proceso de planeación y se usa
de alcance, el análisis y control de variaciones y los reportes de avance.
Muchas organizaciones desarrollan repetidamente el mismo tipo de
¡,rroyectos genéricos. Como resultado, los equipos pocas veces tendrán
(lue crear una EDT desde cero. Es una buena idea conservar copias de
las estructuras más cornunes de división del trabajo para uso futuro. Si
su empresa tiene una oficina de proyectos o una división que archive
l¿rs lecciones aprendidas y proporcione ayuda interna a los gerentes de
proyectos, podrá suministrar muestras de EDT.
Nótense las primeras palabras de la definición de una EDT: "lJna
r,DT es un árbol genealógico de todos los trabajos del proyecto..." LaÍa-
zcin de que los equipos deban incluir en la EDT tantos trabajos como
lcs sea posible es simplemente que, si se deja fuera un trabajo significa-
tivo, las estimaciones de fechas y presupuesto serán erradas. Cuando se
tlcscubra que falta ese trabajo durante la ejecución del plan del pro-
vccto, tcndrán que adicionarse tiempo, recursos y dinero, causando va-
t'i.tr'iot.tcs inr¡r1r¡r1¡l¡1¡cs y cxpectativas fallidas. La creación de la EDT al
56 Curtis R. Cook Fundamentos de la planeación 57

INFORMACIÓN PARA LA PREPARACIÓN DEL DOCUMENTO nivel de tareas es el primer paso real del esfuerzo detallado de planea-
proyecto I proyecto ción del proyecto.
del Gerente del I Fecha de preparación
En términos generales, un proyecto está constituido por fases,
tales como diseño, desarrollo, pruebas, despliegue y transición a opera-
INFORMACIÓN DEL PATROCINADOR
ciones y soporte. Estas fases pueden descomponerse aún más en tareas
Patrocinador I Información de contacto
específicas para ser asignadas a los miembros del equipo del proyecto.
Para cada fase y tarea del proyecto, la cuestión es si el elemento
ASISTENTES puede o debe descomponerse con mayor detalle para definir mejor el
Nombre I Correo electrónico u otra dirección trabajo a rcalizan Si la respuesta es afirmativa, el elemento se descom-
pone en partes más pequeñas, cada una de las cuales se evalúa de ma-
nera similar.
¿Qué tan detallada debe ser la EDT? Depende de cuánta atención
gerencial y control que usted, como gerente del proyecto, sienta que
INFORMAC]ÓN DE LA REUNIÓN necesita para garantizar que el trabajo se haga. Descomponga el pro-
Fecha Tiempo de inicio Tiempo de terminación Lugar yecto en tareas demasiado minúsculas y el resultado será una mi-
crogestión. Las tareas demasiado minuciosas invitar a Pasar por alto
Próposito de la reunión
un elemento crítico del trabajo que puede retardar el proyecto si se
deja de hacer. La clave para una adecuada estructura de división del
trabajo es un buen criterio.
TEMAS DE AGENDA PRESENTADOR TIEMPO Una EDT puede representarse con un formato gráfico o con una
descripción. Una EDT gráfica es parecida a un organigrama, tal como
Bienvenida e introducción
se muestra en la Figura 3-3.
Perspectiva ejecutiva

Panorama del proyecto

Objetivos del proyecto
.,:,:,...,.::,:..:...o:llu,..ll,..lll..:lll
Elementos del protocolo
Solución propuesta
Entregables del proyecto
Logros del proyecto a la fecha t.l:t2
'.,;,',rl',;,:,7¡,ai]tt',i¡rr;,;il:,;,,a;:;',.¡;¡,

Programa del proyecto y t' :,, :ll lil¡:lllllll:::::;:::::¡:::::::¡::ll

Referentes principales
Papeles y responsabilidades
t-t I I

del equipo 1.3.{ 113,2 ,.

Plan de comunicaciones

Asuntos especiales
Resumen y cierre

Figura 3-2. Modelo de la agenda de arranque Figura 3-3. EDT gráfica

 58 Curtis R. Cook Fundamentos de la planeación 59

Si bien es útil como ejercicio de integración del equipo, generar Comentario sobre el uso de software
una EDT usando notas autoadheribles, la mayoría de las veces se dis- de administración de proyectos
pondrá de una EDT anterior como punto de partida. La Figura 3-4 Notará que no he mencionado el uso de Project de Microsoft ni ningún
muestra una descripción para la construcción de una casa en el hermo- otro software de administración de proyectos. La razón de esto es sim-
so paraje de Beech Mountain, North Carolina. Nótese que la EDT de la ple: Muchas personas no cuentan con software de programación y bas-
Figura 3-4 tiene una columna mostrando entregables. Toda tarea de tantes de las que lo tienen no saben usarlo con efectividad. Es por ello
la EDT tendrá su correspondiente entregable evidencia tangible que mi enfoque de justamente lo suficiente utiliza un software al que
de haberse terminado la tarea. Aunque no es-una absolutamente esencial todo mundo tiene acceso Excel, PowerPoint y Outlook. Éstos no
incluir un entregable para cada tarea, es una buena idea acostumbrar- son los -Word,
únicos paquetes disponibles en las oficinas, pero son los que
se a pensar de esta manera. Posteriormente, durante la fase de control uso personalmente y son bastante comunes. Verá que todos los formatos
del proyecto, necesitará algún parámetro para evaluar si el trabajo se de este libro son Word, Excel o PowerPoint Además, los formatos son
está haciendo a tiempo y tal como se especificó. Contar con un entre- fáciles de crear en éstos y otros programas similares, por lo que deberá
gable medible realmente ayuda. sentirse libre para generar los suyos y usarlos regularmente.
El modelo para crear la EDT y algunos de los otros elementos del
lr,Pérsoná,;::::l:
Tarea Entresable Eót¡mádó r,iás,Íoñádá,,,,,,,,
::,,:i,:Fééhá,:dérrl
:telmjhadióñ plan del proyecto se titula Hoja de trabajo de tareas del proyecto. Es una
1.'t Limpiar el lugar
hoja de cálculo Excel que empieza con la EDT y, a medida que se va
Lugar limpio 6,000 Jones Chainsaws Agosto 15
desarrollando el proyecto, incluye otros elementos para asignación de
1.2 Construir recursos, fechas de terminación de tareas planeadas, fechas de termi-
cimientos
nación reales y comentarios. La Figura 3-5 muestra el modelo en blan-
Sitio listo Smith
'l .2.1 Excavar para 9,000 Diggers Sept 10
co y la Figura 3-6 muestra el mismo modelo con los cuadros llenados
zapatas para un proyecto típico.
1.2.2 Colado de Ioclas las zapatas Jailors Nótese que en la Figura 3-6 se incluyen tareas EDT para adminis-
12,000 Sept 20
zapatas en su luoar Construction trar proyectos. Es una buena idea añadir estas tareas al plan del pro-
1.2.3 Colocar blo- Muros construidos pari
que de concreto 6,000 Blockbusters Octubre 1
yecto, para impedir que se olviden. Además, si al proyecto se le está
el bloque de concreto
cargando su tiempo, necesitará monitorear sus actividades con res-
1.3 Construir casa
1.3.
,|
Marco
pecto al plan. La adición de tareas de administración del proyecto tam-
Marco de Pyramid
de la Casa madera completado
37,000
Builders
Octubre 31 bién ayuda a que sus esfuerzos sean visibles.
Techo instalado
1.3.2 Colocación con tejas Mountain
Asigne recursos
de techo Acme 544, 21,000 Nov 15 Mencioné antes que integrar el equipo del proyecto es la primera y
Boys Bldrs
verdes más importante actividad del gerente del proyecto. Si usted ha segui-
1.3.3 Instalación
de tuberías Etc. 14,000 Barney Dic 15 do el "libreto",habrá realizado la reunión de arranque y ahora todos
1.3.4 lnstalación
están motivados. Ha llegado el momento de comenzar el. proceso de
Mountain
Etc. 19,000 Dic21 asignar o recomendar recursos para llevar a cabo las tareas específicas
Eléctrica Electric
n,n... de la EDT. Al asignar recursos, es importante considerar y resolver los
siguientes aspectos:
1.9 Entrega Casa terminada Julio 14
de Llaves a
¿A quiénes y qué necesitamos para que el proyecto sea un éxito?
Figura 34. Descripción de la EDT: construcción de una casa en Beech Mountain. a
¿Quiénes están realmente disponibles?
60 Curtis R. Cook Fundamentos de la planeación 61

Táréa O¡riiéh Oüándo i'i: ¿á;ii.',i'

Hoja de trabajo de las tareas del proyecto-Globus Offsite
iEñtiésqb!é

rfateá Entiégabit.é Quién Gffientaric

Admón. proyecto Varios
Reunión de Agenda de Sally
19t5t04
arranque la reunión Postite
Equipo
Plan del proyecto Plan 20t5t04
del provecto
Reuniones Memos Sally Cada
de avance de avance Postite semana
Monitorear Ajustes Durante
y controlar cuado sean Equipo el evento
el evento necesar¡os
Capturar Documento Sally y
las lecciones de lecciones equipo 24t6t04
aprendidas aprendidas
Celebración Diversión Sally y
del equipo y lecciones equrpo 25t6t04
aorendidas

Finalizar agenda Agenda Sally Postite 21t5t04

Reservar hotel Contrato Jimmy Jones 25t5t04

Decidir menú Menú Jimmy Jones 25r5t04

Especificar equipo Lista de AA/ Seiichi 1t6t04

Figura 3-5. Hoja de trabajo de las tareas del proyecto. audiovisual Nagao
Obtener orador Contrato Bill McMurry 1t6t04
externo
o ¿Cómo podemos compensar la carencia si los recursos no están Obtener capaci- Contrato Seth Godin 3t6to4
tador externo
disponibles cuando los necesitemos? Arreglar Contrato Bill McMurry 7t6to4
o ¿Causarán las restricciones de recursos fallas de programa- entretenim¡ento

ción o de presupuesto? (Cualesquiera disponibilidades de re- Revisar

presentaciones
Presentacio- Sally y 7t6t04
nes aprobadas Seth
cursos no resueltas causarán problemas que eventualmente
Prueba Ensayo lnteresados 15t6t04
se reflejarán en una de las restricciones del triplete: fallas de del evento
programación, disminución del contenido técnico del proyec- Instalaciones Cuartos,
y coordinación alimentos, Equipo 17t6t04
to o costos excesivos.)
del evento etc.
Discuta los faltantes o los cuellos de botella con el patrocinador Evaluación Evaluaciones Seiichi 1 8/6-
de la reunión y resumen Naqao 21t04
del proyecto. Cuando haya resuelto estos aspectos e identificado a los
miembros del equipo que realizarán los trabajos, anote sus nombres
en las hojas de trabajo de las tareas del proyecto, tal como se muestra Figura 3-6. Hoja de trabajo llena de las tareas del proyecto.
 Curtis R. Cook Fundamentos de la planeación 63
62

fual. Estos esfuerzos llevan a la ruta crítica, que se discute en

en la Figun 3-6- Si el "quién" es un proveedor, anote esa informa-
el Capítulo 4.
ción en lugar de un nombre.
4. Consultándolo con el miembro del equipo responsable, deter-
Programe el trabajo mine la fecha de terminación de cada tarea, recordando las
Tiempo-¿alguna vez hay suficiente tiempo? No en el mundo de los condiciones señaladas en el punto 2.
proyectos. La programación del proyecto es las "entrañas" del plan y, 5. Anote las fechas de terminación de tareas en la hoja de trabajo
aunque se refiere a tiempos, es afectada por los costos y los elementos del proyecto. La Figura 3-6 muestra una hoja de trabajo que
técnicos. El gerente del proyecto es responsable de generar un calen- incluye las fechas. Recuerde anotar todas las suposiciones
dario realista, cort la ayuda de los miembros de su equipo. que afectan a la programación. Pueden incluirse en la hoja de
Crear un calendario del proyecto consiste en seis pasos funda- trabajo usando la columna de "comentarios". (Sólo hace falta
mentales: hacer un "click" con el botón derecho sobre la correspondien-
te celda y oprimir "insertar comentario".) Esto es importante
1. Generar una estructura de división del trabajo hasta el nivel de cuando se discuten las razones de la calendarización con el
tareas. patrocinador y los interesados.
2. Especificar a la persona que efectuará cada tarea, tal como ya 6. Genere el calendario total del proyecto y las fechas de termi-
se discutió. Recuerde que la mayor parte de la gente no puede nación. Con todas las tareas relacionadas y asignadas y ya con
dedicar 8 horas completas diarias a trabajar en el proyecto. las fechas de terminacióry se puede determinar la fecha de ter-
Parte de su tiempo estará dedicado a actividades que no son de minación del proyecto.
trabajo directo, tales como entrenar, tiempo libre, café, Pausas
para fumar, etc. Otra porción veces considerable Plan para mon¡torear
-a -esta
dedicada a trabajo operativo. Y su proyecto no es el único en el
que están trabajando, por lo que sólo disponen de cierta parte
la finalización de tareas
de su tiempo para su proyecto. Asegúrese que cuando alguien Para resumir en dónde estamos en cuanto a la planeación, hemos crea-
le diga que necesitatá "X horas" para hacer una tarea, sepa lo do una lista de tareas EDT- y para cada una de ellas, hemos
que significa. ¿Considera este tiempo todas sus demás activi- incluido la persona que-la la llevará a cabo (el "quién" de la hoja de tra-
bajo) y la fecha de finalización ("cuándo"). Estamos progresando bas-
dades o se refiere a un mundo perfecto sin interrupciones? En
el Capítulo 4 discutiremos esto a fondo. Por ahora, asegúrese
tante, pero necesitamos un plan para ver cómo monitorearemos
posteriormente las fechas de terminación, una vez iniciado el trabajo.
de comprender el mensaje que se le está comunicando.
lln el Capítulo 4 se cubre esto, además de algunas técnicas avanzadas
3. Establecer las dependencias entre las tareas. En otras palabras,
tle programación.
decidir cuándo puede empezar cada tarea y cuándo debe ini-
ciarse de acuerdo a las tareas anteriores. Se establecen tam-
bién las actividades sucesorias. ¿A dónde conduce cada tarea?
¿Qué se retrasaría si una tarea se frenara? Es trabajo arduo,
pero debe hacerse para tener una calendarización realista. Si
está empezando sin un plan del proyecto como guía, use notas
autoadheribles para mostrar las relaciones. Si cuenta con un
ejemplo anterior, simplemente añada, elimine o modifique las
tareas y relaciones para que sean un reflejo del proyecto ac-
 <-'é@ry'

Técnicas avanzadas
de planeación

I-
,-
Ln el Capítulo 3 hablamos de los fundamentos de la planeación de
proyectos. En éste daremos un paso más y presentaremos algunas he-
rramientas avanzadas de planeación que ayudarán a controlar el pro-
yecto. También discutiremos la importancia de contar con un plan de
comunicaciones y cómo desarrollarlo. Veremos la forma de anticipar los
riesgos y formular un plan para reaccionar a ellos en caso de ocurrir. Y
veremos cómo controlar los cambios en el alcance del proyecto para
que no erosionen al plan del proyecto y lleven al fracaso.

Maneras de desplegar el programa del proyecto

y mon¡torear la finalización de tareas
Los gerentes de proyecto más exitosos saben en todo momento dón-
de está exactamente el proyecto con respecto al tiempo. Para facilitar
cl trabajo de comparación de los tiempos reales con los planeados, se
pueden usar tres diferentes perspectivas del programa del proyecto:
un calendario simple, una gráfica de Gantt o un diagrama de red. Con
frecuencia se usan los tres para que el gerente del proyecto lo analice
desde diferentes ángulos.
La perspectiva de calendario
Una manera simple pero muy efectiva de monitorear las fechas de ter-
rninación de tareas consiste en usar el software de calendario que casi
66 Curtis R. Cook Técnicas avanzadas de planeación 67

todos tenemos en nuestras computadoras' Personalmente uso el Out- Gráfica de Gantt

look de Microsoft cuando no estoy usando una aplicación de Progra- Hay otros dos métodos populares Para representar y monitorear fe-
mación de administración de proyectos (Figura 4-1). El outlook me chas de finalización: la grófica de Gantt y Ia red lógica (también llamada
permite añadir tareas a mi calendario, compartir calendarios con otros diagrama de red, gráfica PERT o diagrama de precedencia). En la práctica,
miembros del equipo y agregar los recordatorios que surjan Para ase- estos enfoques sólo pueden usarse en combinación con softwares de
gurarme de estar al tanto de las tareas clave que aparecerán pronto, y administración de proyectos
-a menos que a usted le guste construir
óopiar y pegar información a otros softwares para reportar preparacio- a mano gráficas complicadas. Ningún libro sobre administración de
t ur y .bti"ót electrónicos. Inmediatamente después de fijar las fechas proyectos estaría completo si no mencionara estas herramientas.
de finalización, resolver las restricciones con el patrocinador (y asumir Las gráfica de Gantt en todos los libros y cursos de
-estudiadas
muchos riesgos -discutiremos esto después), agrego las fechas de ter- capacitación- son simplemente gráficas de barras horizontales con
minación y lós eventos clave a mi calend atio Outolook y enciendo la fun- una escala de tiempo, mostrando el inicio, la finalización y la dura-
ción de reiordatorio Para darme suficiente tiempo de reacción en caso ción de cada tarea, así como su relación con las demás. Mientras que un
de presentarse un Problema' calendario distribuye el programa en varias páginas, una gráfica de
El enfoque tut simple que es muy sorprendente que no haya Gantt muestra el programa en una sola página de la EDT y proporcio-
"J
más personas usándolo. Inténtelo na una visión clara de dónde está el proyecto con respecto al programa
-funciona' planeado. Esto hace de la gráfica Gantt una excelente herramienta pa-
ra discutir el proyecto en reuniones de seguimiento cuando
se necesita construir otra periódicamente con el
-incluso
software de presen-
Domin$o Lunes' Martes Miércoles Jüév"s Vierrreé sábádo
tación. Y claro está, las gráficas de Gantt se construyen automática-
Registrar Verificar mente una vez establecidas las dependencias y duraciones. La Figura
proyecto prec¡os
materiales
4-2 muestra una gráfica de Gantt genérica.
en el JHSS
Nótese que los programas para las tareas D1' y D2 de la Figura 4-2,
Completar
Obtener
pran incluyen ambas un colchón,lo que significa que las fechas de finali-
copia de
propuesta del proyecto zación pueden variar dentro de ciertos límites sin que tengan impacto
firmada
por el CSM cn la fecha de conclusión del proyecto. La tarea D1 puede retrasarse
por casi una semana y media antes de que afecte aLaE1., y laD2 puede
ldentificar lnic¡ar
líder de desarrollo retrasarse dos semanas y media antes de que afecte a E1.
GUdUllcvlull
Diagramas de red
l-os diagramas de red muestran las relaciones lógicas entre las tareas
sin una escala de tiempo. La gran ventaja de un diagrama de red es que
rrruestra la ruta crítica del proyecto de tareas a través de
-la secuencia
la red en la que cualquier demora causará un retraso en la fecha de la
f inalización del proyecto en su totalidad. La construcción de un dia-
tlrama de red usando notas autoadheribles permite que el equipo
visualice y despliegue las relaciones entre las tareas y obtenga la fecha
rlc finalización del proyecto de una manera lógica y directa. Unavez
Figura 4-1. Vista del calendario. t'orrstrtriclo cl diagrama de red, la ruta crítica puede mostrarse en una
68 Curüs R. Cook

tienden a generar programas demasiado optimistas - y lo que se Pue-

de hacer para que dichos Programas sean más realistas'

B1
Diseño del
sistema de
1234567 negocios
@¡ La linea indica el colchón
A g"t" símbolo indica el inicio de la tarea
V g"t" símbolo indica la terminación de la tarea c2
Modificar
Procedimientos
Figura 4-2. Gráfica de Gantt. internos

gráficaGantt cuando ésta se usa para informar al patrocinador o a los D2

i-nteresados. Las tareas críticas añadidas a un calendario Outlook

pue- Probar
procedimientos
den resaltarse y monitorearse más de cerca que otras. (Ib.gu cuidado, internos
sin embargo, pues la ruta crítica tiende a cambiar cuando se va agotan-
do el colchón de tareas no críticas.)
Los diagramas de red son difíciles de mantener al día si no se está
usando ,rr, ,óft*ute de administración de proyectos. No obstante, para
la sesión inicial de planeación son casi indispensables cuando el equi-
po ,,empie za de.".b". La Figura 4-3 ilustra un diagrama de red típico.

Prog ramación "avanzada"

Si bien nuestra concepto de administración justamente suficiente de
proyectos discute los fundamentos aplicables a cualquier proyecto,
p"ql"no o grande, algunos de mis lectores potenciales me han pedido
qná itr.tnyu-.rr,ur líneás sobre consideraciones de Programación avan-
Figura 4-2. Diagrama de Red
,rdo. gn esta sección cubriré un Par de factores del mundo real que
 70 Curtis R. Cook
Presión política
Hasta ahora hemos discutido el proyecto como si todos los miembros
del equipo, incluyendo al patrocinador, la alta gerencia y otros intere-
sados, fueran totalmente racionales. pero éste .,o es siempre el caso.
Por desgracia, a pesar de nuestros mejores esfuerzos para fbrmular un
plan realista, con frecuencia aparecen presiones gerenciales para acor-
tar tiempos cuando se presenta el plan para su aprobación. Él patroci-
nador puede reaccionar emocionalmente, diciendo cosas como,' -trab ajen
con más inteligencia. ¿Dónde está esa actitud de ,si se puede,? Nues_
tros competidores se nos adelantarán el tiempo a la mitad,,.
-recorten
No niego la existencia de presiones reales del mercado, p".o mucha de
la resistencia que nos presentan proviene de la creencia de que el plan
está demasiado "acolchonado" y que la única manera de presionar a
los equipos de proyectos consiste en comprimir las fechas y mantener
la presión.
¿Qué puede usted hacer como gerente de proyecto en esta sifua-
ción? Mi consejo e?.que mantenga la calma, aipiie 10 veces profun-
damente y use la lógica del proceso para estaLlecer un diál,ogo no
emocional con quien se esté resistiendo. usted cuenta con un argumento
muy poderoso en apoyo a su plan validado los requerimientos,
-ha los requerimienlos
conjuntado a los expertos, descompuesto a una es-
tructura lógica de trabajo, usado la EDT para fi¡ar las fechas de finali-
zación-de tareas y relacionado las tareas entre ellas para generar una
fecha de terminación racional del proyecto. Tiene todas las'cartas en la
mano. Aúne este enfoque racional al poder de su firmezay convencerá
a los escépticos de que usted y el equipo están en lo córrecto y que
quienes desconocen los detalles están equivocados.
¿QuÍ pasa si, a pesar de este enfoque, todavía persiste la resis-
tencia y la presión para comprimir las fechas? Tiate de invitar a esa
persona a una sesión de resolución creativa deproblemas, donde expli-
cará-en detalle que usted y elequipo realmentácreen que están p.urln-
tando la realidad. Pero, si se le pasó algo, también quérrá sabeiqué es
y obtener el beneficio de la experiencia y las leccionés aprendidas-. Este
diálogo desembocará en uno cualquiera de tres resultaáos:
1. Después de analizar e1 plan detallado, la persona lo apoyará y
quedará convencida de que usted sabe lo que está haiiendo.
2' Tendrá que ajustar el plan de acuerdo a la experiencia y a las
percepciones aportadas por esa persona.
Técnicas avanzadas de planeación 71
3. Se le dirá que no hay otra solución y que se ponga a trabajar.
En este caso, ajuste el plan a sus deseos, documente la conver-
sación y actualice su currículo, pues lo necesitará al no cumplir
con la fecha de terminación.
Los gerentes de proyectos deben mantenerse firmes en lo que
creen es realista, incluso cuando son confrontados por el patrocinador
o algún miembro de la alta gerencia.
El optimismo natural de los gerentes de proyectos
Nosotros los gerentes de proyectos somos optimistas por nafuraleza. A
pesar de haber aprendido de dura manera algunas de nuestras lec-
ciones, seguimos creyendo que podemos remontar todos los obstácu-
los y alcanzar el éxito. Puede que se trate de un complejo de héroe,
pero esto sería tema para otro libro. Nuestra actitud de que si se puede
es una virtud en muchos casos, pero nos lleva a meternos en serios
problemas si no somos cuidadosos.
Como siempre estamos presionados por el tiempo, y quizá debi-
do a que tratamos con miembros expertos en el equipo que nos propor-
cionan sus estimados de fechas de terminación, usamos estimaciones
para generar el programa. Pero, si nos basamos en estimados de una
sola fuente, estamos negando la posibilidad de que algo salga mal. sin
embargo, existen modelos para incorporar los riesgos al proceso de
programación.
Incluso los modelos de programación más básico por ejemplo, la
técnica de reaisión y eualuación de programas (pERt por sus siglas en in-
glés) la posibilidad de escenarios del peor y el mejor de
-incorporan
Ios casos. El muy conocido y sin embargo poco usado modelo pERT in-
cluye tres estimados pesimista y más probable- para
tomar en cuenta que las -optimista,
cosas pueden salir peor a lo esperado y que
algunas veces se tiene suerte. Los esfudios han demostrado que, cuan-
clo un gerente de proyecto usa un solo estimado, éste está más cercano
al caso optimista que al peor de los casos (pesimista). La Figura 4-4
rrruestra esta tendencia de manera gráfica.
Nótese en la Figura 4-4 que el estimado más probable está más
cercano al valor del lado izquierdo, el optimista, que al del lado derecho
o pesimista. Como resultado, la estimación para la fecha de termina-
t'itirr total del proyecto es más optimista de lo que debiera ser. usted
l)uedc conrprobar estc fcnrinrcno cn slrs proyectos reales tomando una
72 Curtis R. Cook
Promedio PERT ponderado
EE _t== 0+(4xMostLikely)+P
-oJ
9t
=E -
¡v
(L --6
Pesimista
Baja
Posibles resultados
Figura 44. Gráfica de Gantt.
muestra de 5 a L0 tareas y pedirle a la persona que las está haciendo
que le dé tres estimados. Consistentemente recibirá un estimado más
cerr:ano al valor optimista que al pesimista. Lo que esto significa es que/
al calcular el promedio ponderado, el valor de dicho Promedio es "ia-
lado,, hacia la derecha por el valor pesimista. Esto resulta en un PERT
o valor ponderado más pesimista que el estimado más probable de un
solo punto que le dieron inicialmente. Me gusta Pensar en este valor
como un dato más realista, no pesimista, considerando los muchos pro-
yectos que exceden las fechas de terminación planeadas.
Por ejemplo, digamos que uno de los miembros de su equipo le ha
dicho que se necesitarán 10 días para completar una tarea. Usted registra
este dato en el programa junto con los demás estimados. Ahora suPon-
gamos que decide usar el enfoque PERI y le pregunta a la cuál sería el es-
ümado en el peor de los casos (escenario pesimista). Le contesta que Para
tareas similares en el pasado le ha tomado hasta 20 días. Cuando le pre-
gunta sobre el mejor de los casos,le dice que Podría hacerlo en 8 días si
todo funciona a la perfección. Aplicando la fórmula PERT a estos estima-
dos, se obtiene un tiempo estimado (T") de 11.3 días, en comParación
con la estimación de un solo Punto de 10 días diferencia de ape-
nas 1".3 días. Esto no Parece Sran cosa, pero
-una
incluso en un Proyecto Pe-
queño, probablemente existirán 30 o 40 tareas. Digamos que 15 de esas
tareas están en la ruta crítica. Multiplicando 1..3 días por 15 tareas nos
da L9.5 días. se trata de casi un mes comPleto de trabajo. En un sentido
muy real, su fecha estimada de terminación ya está subestimada por L
mes antes que siquiera se inicie el trabajo. Ahora si es algo importante.
Técnicas avanzadas de planeación 73
Para evitar que esto le suceda, le recomiendo colectar todos los
tres estimados de cada tarea en su proyecto o cuando menos los de las ta-
reas más críticas, calcular los tiempos esperados Para esas tareas y usar
estos valores para su programa, en lugar de las cifras únicas más proba-
bles que casi siempre se usan. También puede añadir tiempo al programa
como una contingencia para este fenómeno si no puede obtener los tres
estimados de la gente muy ocupada que está haciendo el trabajo.
Estadística y convergenc¡a de rutas
Muchos gerentes de proyectos no entienden de estadística. Como re-
sultado, no comprenden las probabilidades asociadas con el éxito o
fracaso de un proyecto. tlna manera de mejorar las probabilidades de
éxito consiste en usar el enfoque PERT ya discutido. Cuando se calcu-
lan los tiempos esperados, también podemos obtener lo que se conoce
como desaiación estándar. Se trata de una medida número- que
-un
representa cuiínto tiempo tendríamos que agregar al programa para in-
crementar la probabilidad de éxito. Pero me estoy adelantando. Prime-
ro se necesita conocer un fenómeno llamado conaergencia de rutas.
Los efectos de la convergencia de rutas ocurren cuando en una
red coinciden varias rutas, tal como se mostró anteriormente en la grá-
fica Gantt de la Figura 4-2.En ese proyecto, las tareas DI,D2 y D3 deben
estar todas terminadas a tiempo o las tareas E1' y E2 no podrán inicia-
rse cuando estaba planeado. Cuando esto sucede, tenemos que tomar
en cuenta las probabilidades combinadas. Una probabilidad combinada
ocurre cuando dos o más eventos son interdependientes.
Por ejemplo, veamos si puede contestar esta pregunta: Si tiene un
90% de confianza de que las tres tareas se terminarán
-DL,D2yD3-
a tiempo, ¿cuál es la probabilidad de que las tareas E1' y E2 se inicien a
tiempo? Si contestó 70"/" está en lo correcto. Cualquiera otra respuesta
cstá equivocada. Veamos cómo se calcula: 0.9 x 0.9 x 0.9 : 0.72. Esto
significa que podemos pensar que el éxito es 90"/" probable, pero, de
Irecho, es sólo 70"/" probable. Y se pone peor. Digamos que también
tiene un 90% de confianza de que la tarea E1 se verificará como estaba
planeado. La probabilidad combinada es ahora 0.72 x 0.9 : 0.65. Y si
la probabilidad de la tarea E2 es también 0.90, la probabilidad de que
ntrestro proyecto se termine a tiempo es ahora de 0.65 X 0.9 : .58. En
otras palabras, tenemos un 58% de probabilidades de completar exito-
s.rrncnte nuestro proyecto a tiempo. Por tanto, estamos iniciando nues-
tro proyccto c()n trna probabilidad de éxito drásticamente reducida,
74 Curtis R. Cook
aun cuando estamos 90% confiados en que cada tarea del plan trans-
currirá como se esperaba.
La combinación de estimados de un solo punto y convergencia de
rutas matan a cualquier proglama incluso antes de iniciarlo cier-
-son
tamente malas noticias. ¿Qué se puede hacer al respecto? El primer
paso consiste en ser conscientes de que estos factores realmente afec-
tan a nuestros planes de proyectos. El segundo es determinar cuánto
tiempo se necesita añadir al programa Para elevar las probabilidades
de terminación a tiempo a un nivel confortable. Podríamos calcular la
desviación estándar usáramos el enfoque PERT- y agregarla a
-si
nuestros tiempos esperados para mejorar las posibilidades de éxito.
Sin embargo, francamente, éste es el punto en el que se ven caras de
sorpresa siquiera Pensar en usar este tipo de lenguaje con patro-
-sin
cinadores y otros interesados.
¿Dónde nos deja esto? Sin duda, nos deja vulnerables. Pero habla-
remos de la administración de riesgos agregando una reserva a nues-
tro proyecto. Tenemos que incluir reservas o reguladores, que serán
usados a discreción del gerente del proyecto para restaurar las proba-
bilidades. El único problema con este método es que algunas Perso-
nas Io consideran como un acolchonamiento. El hecho simple es que
estas fuerzas actúan en nuestros proyectos y debemos planear tomán-
dolas en cuenta para tener una posibilidad razonable de triunfar. Y si
alguien lo quiere desafiar cuando sugiera crear este regulador, pre-
gúntele qué porcentaje de sus proyectos se terminan a tiempo. Esto le
proporciona una evidencia suficiente.
Presupuestación de proyectos
Un amigo mío muy sagaz, alguna vez me dijo que todos los excesos de
costros de un proyecto se deben a problemas de estimación. Y es cierto
conociéramos un proyecto a la perfección antes de iniciarlo, ge-
-si
neraríamos estimados correctos todas las veces. En el mundo real esto no
Sucede, pero sí existen métodos para ayudarnos a formular estimados
de costos bastante confiables.
Hay tres niveles de precisión o estimación de Proyectos/ conoci-
dos con los nombres de descendente, presupuestario y ascendente'
Presupuesto descendente. Recuerde que el protocolo del proyecto con-
tiene una estimación de su costo. ¿De dónde provino esta información?
Técnicas avanzadas de planeación 75
Probablemente de una estimación gerencial, basada en experiencias
anteriores, o quizás fue la cantidad contratada menos gastos generales
y utilidad. En cualquier caso, fue la visión "desde 10,000 metros de
altura". Por definición, los estimados descendentes son poco precisos
y de uso limitado para los gerentes de proyectos que intentan contro-
larlo antes de iniciarlo. La mayor parte de los estimados descendentes
son restricciones límite de lo que el gerente de lo que el gerente del
-el
proyecto puede gastar.
Estimación presupuestaria. Cuando el objetivo del proyecto está bien
definido, se conocen las categorías de recursos y gastos y se dispone de
información sobre gastos administrativos, el estimado presupuestario
es apropiado. Si bien este estimado no es tan preciso como el de tipo
ascendente, con frecuencia es "suficiente" er:.la fase de planeación. Si
conocemos los "tipos" de mano de obra que usaremos, así como otros
costos directos, tales como materiales y viajes, y costos indirectos, in-
cluyendo gastos administrativos aplicables, podemos desarrollar pre-
supuestos de proyectos razonablemente precisos.
Presupuesto ascendente y/o detallado. La estimación más precisa se
obtiene estimando el costo de cada tarea de la Eot, sumando todos los
estimados y añadiendo una reserva para riesgos. Los estimados ascen-
dentes se basan en tres pasos simples:
1. Calcular el costo total de cada tarea del proyecto. El miembro
del equipo asignado a cada tarea debe párticipar en la estima-
ción de los costos de mano de obra, materiales y otros insumos
para realizar la tarea.
J Sumar todas las tareas para obtener el presupuesto total del
proyecto. El gerente del proyecto suma los costos de cada tarea
y genera el presupuesto del proyecto.
3. Añadir una cantidad para contingencias imprevistas. (Habla-
remos de esto más adelante.)
IJna vez completado el estimado ascendente, compárelo con el
cstimado descendente incluido en el protocolo del proyecto. Resuelva
las discrepancias discutiendo las diferencias con el patrocinador del
proyecto. No sea tímido de su trabajo es manejar las expectati-
vas y mientras más pronto -parte
se refiera a la discrepancias, en mejor
si tttacititr t'sl¿l r.i.
76 Curtis R. Cook Técnicas avanzadas de planeación 77

Planeación de r¡esgos
Enfrentémoslo, no todo saldrá de acuerdo a lo planeado para el proyec-
to, por lo que es prudente tomar en cuenta los riesgos que comúnmente
o.rlrr.r, en el eniorno de proyectos. Incluso en proyectos pequeños, la
planeación de riesgos es lmportante. Los riesgos y las es-trategias de
mitigación deben dbcumentarse en el plan del proyecto. El gerente-del
proylcto debe hacerse una pregunta simple: " LQué puede salir mal en
óste proyecto?" Como mínimo, considere las siguientes interrogantes
cuando esté formulando el Plan:
1,. ¿se comprenden bien los requerimientos del cliente y están
documentados?
2. ¿Se detallan los estimados
de costos y tiempos o se fijaron des-
cendentemente?
3. ¿Qué tan probable es que cambie el alcance del proyecto? Figura 4-5. Análisis de riesgos.
4. ¿Habrá recursos dedicados al proyecto o sólo
estarán disponi-
bles en el momento en que se necesiten?
IJna vez que se han identificado y analizado los riesgos, existen
5. ¿Se reasignarán recursos clave al proyecto
o se perderán?
básicamente cuatro maneras para manejarlos:
6. ¿Presionarán los clientes u otros las fechas límite? o Evitarlos: Una manera segura de evitar un riesgo es no desa-
¿Será el cliente responsable y cumplirá con los eventos clave?
rrollar el proyecto. Suena extraño, pero esta decisión debe
8. ¿Tendremos problemas técnicos? tomarse antes de que la alta gerencia le dé luz verde al inicio
9. ¿Hemos considerado los efectos de los estimados únicos y la del proyecto. Una vez iniciado éste, el equipo puede considerar
convergencia de trayectorias? cambiar el plan del proyecto o el enfoque técnico del trabajo
La evaluación y planeación formal de riesgos son muy importan- para eliminar las soluciones de alta tecnología. De otra manera,
tes en los proyectos grandes y se cubren en detalle en cursos de capaci-
evitar el riesgo no es una opción.
tación y libros enfocados a proyectos importantes. Pero aún en proyectos
o Aceptarlo: Literalmente, la aceptación significa no tomar ac-
pequeños necesitamos incluir la planeación de riesgos como un Paso ción alguna para reducir la probabilidad o el impacto del suceso.
Íormal de los esfuerzos de programación de proyectos. Como dice Clint Eastwood, "¿Te sientes con suerte?" Pot ejem-
El riesgo puede definirse como una función de tres variables -un plo, si usted se sube a su automóvil y conduce en una autopista
suceso qne pnóae causar una perturbación, la probabilidad de que el su- interestatal a más de 100 kilómetros por hora sin abrocharse el
ceso se preJente y el impacto que el suceso tendrá en el proyecto si se cinturón de seguridad, está aceptando el impacto de su deci-
presenti. En la Figura 4-5 se muestra la interacción de estas tres variables. sión si llega a tener un accidente. En general, la aceptación no
si utr suceso de riesgo es probable y tendría un efecto catastrófico, es una buena alternativa para los sucesos de alto riesgo.
es obviamente un riesgo alto y debe tomarse en cuenta. Si un suceso es
. Mitigarlo: La mitigación significa actuar para reducir la pro-
menos probable y tiene un impacto despreciable, es un riesgo bajo y babilidad o el impacto del riesgo. En esto se pasa la mayor
puede aieptarse sin necesidad de actuar. El plan del proyecto debe con- parte de su tiempo el equipo en la planeación de riesgos. Há-
iid".ut todos los riesgos altos y la mayor parte de los riesgos moderados. gasc la siguiente pregunta: ¿Qué puedo hacer ahora durante la
7B Curtis R. Cook Técnicas avanzadas de planeación 79

planeación para disminuir la probabilidad o el impacto del su- Información del proyecto Describa el suceso que podría ocurrir
ceso? Por ejemplo, un riesgo típico es la posibilidad de que al Nombre del proyecto
equipo le sea retirada una persona clave cuando más se nece- Gerente de proyecto/ Tet.
sita. ¿Qué puede hacer para mitigar este riesgo? Podría sub-
Tarea
contratar la tarea o cuando menos desarrollar un plan para
ello, que entraría en acción si obtiene indicios del suceso. Tam- # de EDT o tarea
bién podría desarrollar una fuente secundaria entrenando a al- Alta
guien más para el caso de necesitarse. El objetivo es disminuir
Describa el impacto significativo
el riesgo a un nivel aceptable para que no mate ni dañe seria-
mente al proyecto. Si no puede hacer otra cosa, agregue fondos en el proyecto si esto ocurre
o.::
o tiempo de contingencia al plan del proyecto "por si acaso".
o É;
Transferirlo: ¿Puede transferir o compartir el riesgo con otra
entidad o grupo? Normalmente, esta estrategia se usa para los
€:
€t
riesgos financieros, mediante un seguro o un contrato. tg
Es útil sistematizar este proceso de planeación de riesgos. La Describa la probabilidad del suceso
Figura 4-6 muestra un formato que he usado durante años para ayu-
darme a identificar y analizar los riesgos y escoger la estrategia de res- Bajo lmpacto Alto
puesta más adecuada.
Al final de la sesión de planeación de riesgos, el gerente del pro-
yecto selecciona las respuestas apropiadas y ajusta la restricción triple
costo o enfoque técnico y/o alcance- para que refleje las Para cada una de las siguientes estrategias de respuesta, discuta la ventajas y
-tiempo,
estrategias y acciones planeadas y aplicadas. desventajas y después seleccione la que mejor corresponda a en la situación.

Respuestas al riesqo
Planeación de la comunicación
Estrategia Evitar Aceptar Mitigar Transferir
Un elemento esencial de cualquier plan debe ser una discusión de las
maneras en las que el equipo se comunicará durante el proyecto y Ventaias
cómo se transferirá la información de su avance a los interesados. A Desventajas
pesar de nuestras mejores intenciones de comunicarnos con frecuencia
con los miembros del equipo, una vez que se está trabajando en el Orden de
proyecto es frecuente que las comunicaciones se interrumpan. Esto preferencia
conduce a sorpresas las sorpresas en los proyectos suelen ser desa-
-y
gradables. Las malas comunicaciones son el resultado de dos factores
Figura 4-5. Formato para la administración de riesgos.
primarios:
1. Estamos tan ocupados que nos olvidamos de mantener el flu- Estas dos causas están relacionadas entre sí. Si el plan del proyec-
jo de información. to incluye los requerimientos de comunicación y las expectativas del
2. El gerente del proyecto no ha hecho planes para el intercambio c'quipo, lo más probable es que haya un buen flujo de información y
de información. se presentcn menos sorpresas.
 t
il
I

lr Técnicas avanzadas de planeación B1

80 Curtis R. Cook

Las comunicaciones en el entorno de un proyecto no son fáciles.

. Revise con ellos sus ideas, borradores y planes.
El número de enlaces de comunicaciones crece exPonencialmente a . Obtenga su aprobación para los cambios pendientes.
medida que aumenta el número de miembros del equipo, tal como se . Obtenga su aprobación de los entregables finales.
muestra a continuación. . Establezca un "diálogo continuo" con el equipo.
Número de canales de comunicación en una red: La aplicación de estos lineamientos debe mantener a todos los in-
n(n-1) teresados informados y comprometidos con los objetivos del proyecto.
2 En cuanto a la forma que deben asumir los reportes rutinarios de
avances, lo más simple es un memo o un correo electrónico. La Figu-
Por ejemplo, en un equipo de cinco miembros hay
ra 4-7 muestra un ejemplo de un reporte de avance usando un forma-
: 1o canales to de memorando. Para un reporte un poco más formal, considere el
ry uso del formato que se muestra en la Figura 4-8.
Y con siete miembros hav
7 (7 - l) : 21 canales
Mémorándo de avance del proyecto
2
A: Curtis Cook.
Es evidente que una de las más altas prioridades del gerente De: Shamika Reyes.
del proyecto es planear las comunicaciones y asegurarse que se Pro- CC: Robert Seals.
duzcan. Asunto: Reporte de avance del proyecto para el nuevo equipo tele-
El plan del proyecto siempre debe incluir un párrafo o dos descri- fónico.
biendo los siguientes elementos: Fecha: 4-12-04
o ¿Quiénes necesitan la información?
o ¿Por qué la necesitan?
Logros esta semana:
. L. Se preparó un documento conteniendo todos los requerimientos
¿Qué necesitan?
. de entrenamiento, junto con la descripción de cada uno de ellos.
¿Cuándo la necesitan?
o 2. Se identificaron los principales impresores y se recibieron sus
¿En qué forma necesitan la comunicación? cotizaciones.
. ¿Cuándo se debe reunir el equipo del proyecto Para discutir los
avances, los problemas, etc.?
3. Se inició el trabajo de preparación del folleto para informar a los
empleados sobre el nuevo sistema.
Poco o mucho, todos los proyectos son diferentes, Pero en general,
los miembros del equipo comunican el estado del proyecto al gerente Asuntos que necesitan acción:
del mismo semanalmente, el gerente lo consolida,lo evalúa en general 1. El departamento gráfico advierte que hay lentitud en los trabajos
y se lo pasa al patrocinador y al cliente, junto con cualquier acción para debido a sobrecarga.
superar los reveses. Los siguientes son algunos lineamientos probados
y comprobados: Estado general del proyecto: Verde.
. Comuníquese con frecuencia con los miembros del equipo, el
patrocinador y el cliente. Figura 4-7. Memorando simple del estado de un proyecto
 II

82 Curtis R. Cook Técnicas avanzadas de planeación 83

REPORTE SEMANAL DE AVANCES Proceso de control de cambios

A: El manejo de los cambios durante el desarrollo de un proyecto es uno
De: de los aspectos más importantes de la administración de proyectos.
Nombre del proyecto: El deslizamiento del alcance expansión irrestricta del alcance-
Semana terminada el: puede causar que se rebasen -lael protocolo del proyecto y el presupues-
to con respecto a la línea base.
ACTIVIDADES Liste las actividades y los logros de la semana
para este proyecto.
El control de cambios es realmente un estado mental. Expresa que
Y LOGROS
ESTA SEMANA Refiérase a la EDT para reportar los logros, nada del plan del proyecto aprobado puede cambiar sin la partici-
planes y asuntos. pación del gerente del proyecto. Como mínimo, el proceso de control
1.
de cambios debe incluir lo siguiente:
2. 1. Todos los cambios deben presentarse al gerente del proyecto
3. mediante un formato de solicitud de cambio o por correo elec-
PLANES PARA Anote los objetivos para la próxima semana trónico.
LA SEMANAQUE y las actividades importantes para este proyecto. 2. Los cambios se registran usando una hoja de cálculo simple.
TERMINA 1. 3. El equipo evalúa el impacto del cambio con respecto al progra-
2. ma, el presupuesto y las especificaciones.
3.
4. El impacto se discute con el solicitante. (Con frecuencia, la so-
CAMBIOS EN LAS Liste las fechas límite nuevas, licitud de cambio es retirada al conocerse su impacto.)
FECHAS LíMITE modificadas o importantes. 5. El cambio propuesto se discute con el patrocinador y el cliente.
Tarea
- Fecha límite revisada 6. El cambio es aprobado o rechazado y se le informa la decisión
al solicitante. (Asegúrese que todo mundo entienda quién pue-
de aprobar cambios antes de iniciar el proyecto.)
7. Se notifica el cambio a los interesados.
8. El cambio se incorpora al plan del proyecto y los entregables.
En proyectos pequeños, las solicitudes de cambios pueden pre-
sentarse por correo electrónico, pero en proyectos mayores y más com-
plejos, deberá usarse unformato de solicitud de cambio, tal como el que se
muestra en la Figura 4-9.
A primera vista, parecería que el proceso de control de cambios es
SUPOSICIONES Liste las suposiciones.
fastidioso, pero en realidad es muy simple. Requiere un sistema estricto
al que algunas organizaciones no están acostumbradas o no quieren
ASUNTOS Liste cualquier asunlo (nuevo o abierto)
aceptar. Usted y la alta gerencia deben juzgar cuánto proceso es justa-
que requiera un plan de acciÓn.
mente suficiente para controlar los cambios en su empresa.
RIESGOS Liste cualesquiera riesgos nuevos o continuos
asociados con el proyecto. Aprobación del plan del proyecto
l)espués de haber completado todos los elementos del plan, el ge-
Figura 4-8. Memorando simple del estado de un proyecto. rcntc del proyccto y su equipo revisan la totalidad de dicho plan para
 'I
84 Curtis R. Cook Técnicas avanzadas de planeación B5

asegurarse que sea internamente consistente. Esta revisión garanti-

INFORMACIÓN DE PREPARACIÓN DE DOCUMENTO
za qlue se han incorporado todos los elementos importantes del plan y
Nombre del proyecto Preparado por Fecha de ldentificación
preparación del provecto
que el equipo tiene una fuente de información que puede usar para
controlar el proyecto una vez que se inicie el trabajo. Se trata de un
CAMBIO PROPUESTO paso crucial en el ciclo de administración de un proyecto. Hasta este
DESCRIPCION DEL CAMBIO momento, no se gastado mucho tiempo ni dinero. Sin embargo, una
Defina el cambio deseado con suficiente detalle para permitirle al equipo vez que el plan queda aprobado, comienzan a cargarse los tiempos de
evaluarlo. ldentifique todos los elementos ce la eor afectados por el cambio los recursos humanos al proyecto y los costos se van acumulando con
rapidez. Sin una línea base aprobada, el control objetivo de los aspec-
tos técnicos, los costos y el programa será muy difícil, si no es que
imposible.

RMONES DEL CAMBIO Transición a la fase de control

Describa porqué este cambio es necesario o deseable.
IMPACTO EN EL PROGRAMAY EL PRESUPUESTO
Mencione el efecto de este cambio sobre el programa del proyecto y
los costos. Incluya la duración y el costo del cambio específico, así como
el impacto general si se conoce.
SUPOSICIONES
Liste las suposiciones técnicas y de negocios.
La aprobación del plan del proyecto constituye el final de la fase de
planeación y el inicio del esfuerzo físico y de la fase de control del ciclo
de vida del proyecto. Éste es un buen momento para invitar al equipo
a una pequeña celebración. Después de esto, la presión continuará in-
crementándose para que el proyecto se desarrolle de acuerdo al plan.
Recordará que la fase de planeación empezó con mucho bombo.
Hubo una reunión de inicio a la que asistió el patrocinador y que sir-
vió para motivar al equipo. Si bien no suele haber una sesión formal
para comenzar la implantación y el control, es una buena idea juntar
al equipo con el patrocinador para forrnalizar la aprobación del plan
y lograr que él los aliente al comenzar el trabajo.

AUTORIZACIÓN _ GERENTE DEL PROYECTO

Nombre Firma Teléfono Fecha

AUTORIZACIÓN - PATROC¡NADOR DEL PROYECTO

Nombre Firma Teléfono Fecha

Figura 4-9. Formato para la solicitud de cambios

 Gontrol del proyecto

,
,
Llegamos a la parte difícil. El proyecto está en marcha y están suce-
diendo cosas. Se están realizando tareas, surgen problemas, ocurren
cambios. Lo que parecía claro y manejable está ahora desdibujado y
complicado. Estamos inundados de información de ta-
-terminación
reas, retrasos, aspectos que requieren nuestra atención y reuniones a las
que tenemos que asistir. Nuestro desafío es mantener el CONTROL.

Actividades de control
Durante la fase de control del proyecto, el equipo lo desarrolla de acuer-
do a la línea base del plan. Siguiendo la estructura de división del tra-
bajo, el programa y otros elementos del plan del proyecto, el equipo
trabaja para alcanzar referentes y cumplir con los objetivos. El gerente
del proyecto maneja los cambios o desviaciones del plan a medida que
se presentan durante su ejecución.
Las actividades de esta fase en realidad se llevan a cabo en para-
lelo más que secuencialmente. El gerente del proyecto debe controlar
estas actividades y asegurarse que se enfoquen en completarlo de
acuerdo a los objetivos de desempeño.
En la Figura 5-1, se muestran las actividades específicas que reali-
za el gerente del proyecto durante esta fase. Discuüremos cada tina de
ellas por separado.

Administración del desempeño técnico

El objetivo de la mayor parte de los proyectos consiste en proporcio-
nar una solución a una necesidad del negocio. El gerente del proyecto
 'J

88 Curtis R. Cook Control del proyecto 89

debe asegurarse de estar logrando avances técnicos, así como progresos

en otras áreas, con respecto a la consecución de los objetivos. Los pro-
cesos de planeación, ejecución y control existen por una razón
-para
satisfacer los requerimientos del proyecto enunciados en el protocolo.
Ya sea que el desempeño resulte en un producto físico o un servicio,
constituye la base de la existencia del proyecto.
Su labor como gerente del proyecto, aunque usted mismo esté
realizando algunas tareas técnicas, es monitorear todo el trabajo técni-
co que se está desarrollando y evaluar el progreso con relación al plan
del proyecto. Su fuente de información es, desde luego, el equipo de
trabajo. Más adelante discutiremos la administración del equipo, pero
es obvio que sin un alto nivel de confianza y respeto entre el gerente
del proyecto y el equipo, la información que fluye hacia el gerente del
proyecto sobre el estado del trabajo técnico, estará distorsionada.
Basándose en la información recibida, iniciará acciones correc-
tivas para cualquier variación surgida. A continuación se discute la
forma que pueden aplicarse estas acciones. Thmbién estará monito-
reando las actividades de cambios de tareas técnicas, el cumplimiento
del proceso de control de cambios y la incorporación de cambios al
plan después de ser aprobados por el patrocinador. Por consiguiente,
la comunicación constante del progreso técnico entre todos los miem-
bros del equipo, incluyendo al cliente, es de importancia capital.
Es evidente que el gerente del proyecto no puede ser un simple
administrador, ni tiene que involucrarse en relaciones significativas
con los miembros de mayor orientación técnica del equipo. Si bien mu-
chos expertos y practicantes insisten en que el gerente del proyecto
no necesita ser un conocedor en cuanto a la tecnología del proyecto, el
Oesar.rollar conocimiento técnico para los proyectos pequeños es una necesidad
proceso de
control ineludible. No obstante, mientras mayor sea el proyecto, menos cono-
de camb¡os
cimientos técnicos se requieren. De hecho, en los proyectos de gran
envergadura, probablemente es un error que el gerente trate de parti-
cipar en los aspectos técnicos. Para expresarlo de otra manera, si el ge-
rente está en los pasillos acomodando la mercancía en los estantes,
¿quién estará manejando la caja registradora y la tienda? El proyecto
puede salirse de control en un área técnica mientras el gerente está
profundamente involucrado en su tecnología favorita. Mientras más
grande sea el proyecto, más necesita el gerente centrarse en manejar al
Figura 5-1. Diagrama de bloques del proceso destacando los pasos del control. t'ciuipo.
90 Curtis R. Cook
Comunicac¡ón de logros
y estado del proyecto
¿Está usted satisfaciendo las expectativas del cliente y
del patrocina-
áor? No suponga que así es ---<omuníquelo. Aunque no lo crea, a la gente
suele olvidársele hácer esto. Están tan ocupados haciendo el trabajo y ma-
nejando el proyecto es, en apagat fuegos- que Se saltan este
muy imporlur,ie -esto
uspecto del control del proyecto. Los reportes periódi-
cos del estado del proyecto y visitas cortas ayudan a asegurarse que
está cumpliendo las expectativas. Las comunicaciones frecuentes tam-
bién le ayudarán a lograr una influencia informal con el equipo y le
proporcionan al patrocinador la información que necesita- para rePor-
iut ios avances y problemas a sus superiores. Los memos de estado del
proyecto realmente son de gran ayuda.
La forma y frecuencia de las reuniones del equipo,los reportes del
estado del proyecto del equipo a usted,los reportes del gerente del pro-
yecto al patrocinador y a otros interesados sobre los avances del proyecto
él1o tier,e que haber sido incluido explícitamente en el plan del
-todo
proyecto. Si no fue así, tendrá problemas en esta etapa para que_todos los
invólucrados "lean la misma página" con respecto a intercambio de in-
formación. Si por alguna razón, el plan no incluyó esta información, aho-
ra es el momento pára establecer los métodos que usará para el resto del
trabajo. Es buena idea modificar el plan con esta informacióry Para no
tener problemas repetitivos más adelante cuando las cosas estén "ca-
lientes".
Supongamos que se hizo bien y se documentaron los requeri-
mientos e inlercambios de información en el plan del proyecto. Todo lo
que tiene que hacer es entonces seguir el plan. Use el formato de
ieporte seleicionado para recabar información del equipo y pasársela
al patrocinador y otros interesados.
Reunirse o no reun¡rse-ésa es la cuest¡ón
En el plan del proyecto, quizás incluyó un comentario general referen-
te a que el equipo se reunirá "cuando resulte necesario" para resolver
problemas, además de las reuniones semanales programadas para re-
portar los avances. Pero en la práctica, ¿cuándo debe reunirse física-
mente el equipo? Por una parte, querrá evitar reuniones rutinarias sin
ningún propósito, mientras que por otra, deseará reunirse con la su-
ficiente frecuencia para Preservar la identidad y el espíritu de equi-
Control del proyecto 91
po. Conviene aplicar los siguientes lineamientos para lograr un buen
balance:
o Reuniones uno a uno para resolver problemas individuales.
. Reuniones en grupo para discutir asuntos de interés común y
obtener retroalimentación del equipo.
El tipo de retnión más frecuente se centra en el estado del proyecto.
Estas reuniones le ofrecen al gerente del proyecto la oportunidad de
solicitar retroalimentación, avances, información e ideas del equipo con
respecto a diversos aspectos del proyecto. Les proporcionan a los miem-
bros del equipo la oportunidad de interactuar entre ellos.
Como gerente del proyecto, usted es responsable de planear y
conducir las reuniones y de asegurarse que se enuncien y se alcancen
los objetivos de la reunión. Los siguientes pasos le ayudarán a lograr
reuniones productivas:
L. Prepare una agenda (quizás podrá utilizar la agenda de la reu-
nión de arranque como ejemplo), enunciando el propósito de
Ia reunión, su duración esperada, la lista de convocados, etc.
2. Notifique a los convocados cuando menos con una semana de
anticipación para cada reunión.
3. Asegúrese que en la reunión se cubran todos los tópicos men-
cionados en la agenda.
4. Documente las acciones y otras decisiones surgidas durante la
reunión.
5. Distribuya las minutas de la reunión a todos los invitados (no
sólo a los asistentes).
6. Asegúrese que las acciones, junto con el individuo responsable
de llevarlas a cabo, se registren en la agendapara la siguiente
reunión programada.
Administración de variac¡ones de costos,
programación y recursos
Además del desempeño técnico, son tres las mediciones de desem-
Pcño del gerente del proyecto: variaciones de costos, variaciones de
programación y variaciones de uso de recursos. Vigile bien estos as-
l'rt'ctos y tcrrclrá sr¡s dedos sobre el pulso del proyecto.
 II

92 Curtis R. Cook Control del proyecto 93

I
I

Usando la información del estado del proyecto proporcionada por a la falta de recursos, y que dichos recursos existen en un pro-
el equipo, será consciente de las variaciones de costos y Programación yecto menos crítico, tendrá armas para al patrocinador. Esto no i

con respecto al plan y de las restricciones de recursos humanos que lo hará muy popular con el gerente del proyecto de baja prio-
amenacen la buena marcha del proyecto. De acuerdo a la naturaleza ridad, pero si el plan de ese proyecto se ajusta con respecto a su
del problema y a la situación, y en colaboración con el equipo, su trabajo pérdida de recursos, el gerente no será penalizado por no lo-
consiste en corregir el problema y que el proyecto regrese a su curso grar sus objetivos. I

planeado. Si no puede resolver el problema Por sí mismo, discútalo . Modifique o reduzca el alcance del trabajo (sujeto desde luego
con el patrocinador, sin dejar de mencionar su recomendación de ac- a un acuerdo con el cliente). Por desgracia, frecuentemente nos
ción correctiva. vemos forzados a tomar esta alternativa como última y poco
En algunos casos, el plan del proyecto tendrá que revisarse si el deseable solución. Si el programa es el objetivo de mayor prio-
presupuesto, el programa o los recursos no pueden mantenerse. De ser ridad, el alcance puede disminuirse para preservar la fecha de
ásí, el gerente del proyecto trabajará muy de cerca con el patrocinador terminación. En muchas ocasiones, un proyecto encadenado es
y el cliente para revisarlo, mantener motivado al equipo y continuar el punto de partida de otro proyecto para que la siguiente ge-
avanzando con respecto al plan revisado' neración dé lugar a un producto.
Hay tantas acciones correctivas para problemas esPecíficos del Obviamente, algunas de estas acciones aumentan los costos. Si se
proyecto como problemas, por lo que una lista detallada de cómo "co-
agregan más recursos a la tarea que está retrasada, esto suele dar lu-
iregfu" un proyecto que esté fuera de control es casi imposible, dado el
gar a tiempos extra, costos de consultores externos o simplemente la
alcance de este libro. No obstante, hay algunos enfoques generales que
aplicación de más horas de mano de obra para llevar a cabo el trabajo.
pueden considerarse para ayudarlo a manejar las variaciones y recu-
El gerente del proyecto tendrá que discutir estos impactos con el pa-
perarse de sus efectos:
trocinador y el cliente antes de actuar.
Aplique más o diferentes recursos humanos a las tareas atra-
sadas, en especial aquellas que constituyen la ruta crítica. Sin
embargo, es necesario recordar que aventar recursos a una ta-
HOJA DE TRABAJO DE TAREAS DÉL.PROYECÍTGLOBUS OFFSITE AI416104
rea que está atrasada no necesariamente resuelve el problema.
Reconfigure el plan del proyecto de tal manera que las tareas T€rea Entregable Ouién CüándCI RéáI Gomeñtário
se lleven a cabo con una secuencia diferente o en paralelo. Admin¡strac¡ón
del proyecto Varios
Aunque los riesgos aumentan al operar en paralelo, en ocasÍo-
nes esta acción resulta en una aceleración del trabajo. Sin em- Reunión de
arranque
Agenda de
la reunión
Sally
Postitte 19t5t04 19t5t04
bargo, debe haber recursos humanos disponibles Para tealizar
Plan del Plan Equipo del
estas tareas y de acuerdo a mi experiencia, dichos recursos no proyeclo Proyecto 20t5t04 20t5t04
suelen estar disponibles cuando se necesitan Para acelerar el
Reuniones Memorandos Sally Semanales
proyecto de esta manera. de avance de estado Postitte
Reasigne recursos entre proyectos (tome recursos de un pro- Monitoreo y Anexos que Equipo Durante el
yecto de baja prioridad). Si tiene la suerte de trabajar en una control de sean Evento
eventos necesarios
organización que jerarquiza sus Proyectos de acuerdo a su con-
tribución a los objetivos estratégicos, puede proceder "qui-
tándole a Pablo para darle a Pedro". Si es capaz de demostrar
que su proyecto es de más alta prioridad y que sufrirá debido Figura 5-2. Hoja de trabajo actualizada de las tareas del proyecto. (continúa)
 ]t
I

I'
rtl

94 Curtis R. Cook l

HoJA DE TR.ABAJo DE TAREAs DEL pRoyEcrHLoBUs orrsite ¿Recuerda nuestra de trabajo de las tareas del proyecto? Es el t

-hoja
momento de actualizarla con las fechas reales de terminaóión, las fe-
Táreá Entregab.lé Ouién cüÉñd6 Reál ,C,6rnéntaiió chas replane¿das y los comentarios que reflejen las razones de las
variacioner. Figura 5-2 muestra uná hoja de trabajo parcialmente Li
Capturar Documento Sally lu_
lecciones de lecciones y el Equipo actualizada de las tareas del proyecto para reflejar el ptog.eso real de l

aprendidas aprendidas 24t6t04 algunas de las tareas.

Ir

Celebración D¡vers¡ón Sally

del equipo y lecciones
aprendidas
y el Equipo
25t6t04
Gontrol de cambios
Todo proyecto de cierta envergadura experimenta cambios de diseño
Terminar agenda Agenda Sally Sally enferma técnico, programa, costos estimados, recursos y otros aspectos. sin em-
Post¡tte 21l5tO4 23t5t04 dos días b,argo, si dichos cambios no se controlan cuidadosa y iigurosamente,
el proyecto puede salirse de curso con gran facilidad, tal"como se ilus-
Contratar hotel Contrato Jimmy
Jones 25t5t04 25t5tO4 tra en la Figura 5-3.
El equipo no
pudo acordar I

Jimmy menú-
Decidir menú Menú Jones 28t5t04 31t5t04 decisión
retrasada por
el fin de
semana

Seiichi
Especificar equipo Lista de Seiichi retrasado por
audiovisual equipo Nagao 1t6to4 4t6t04 otras
prioridades
Modifique un lado
Decidir orador Contrato Bill McMurry 1t6to4 de la restricción triple
externo sin tener cuidado.. .

Contratar Contrato Seth Godin 3t6t04

entrenador e)derno

Definir Contrato Bill McMurry 7t6to4

entretenimiento
Revisar Presentación Figura 5-3. Control de los cambios.
presentación aprobada Sally y Seth 7t6t04

Facilidades Ensayo general lnteresados 't5t6to4 El gerente del proyecto es responsable de implantar y, con la ayu-
da del patrocinador, de obligar a[ cumplimiento del p.o""ro de con-
Prueba Cuartos, trol de cambios especificado en el plan del proyecto, -puru ur"gr.urr"
y coordinación comidas, Equipo 't7t6t04
de la reunión etc. clue éste no sufra las catastróficas consecuettiiui del déslizamiento
del
¿rlcance. Recuerde que el alcance del proyecto se define como
Evaluación Evaluación Seiichi el con-
tenido de trabajo
de la reunión y resumen Nagao 18-21t6t04
-el total de del
cl proyecto. El deslizamiento
actividades y entregables- incluido en
alcance ocurre cuando se presentan
cambios de los que el gerente del proyecto no está enterado y que ero-
Figura 5-2. Hoja de trabajo actualizada de las tareas del proyecto. si.nan cl prestrptresto y el programa sin su conocimiento ni control. A
 'I
96 Curtis R. Cook
manera de revisión, los siguientes son los pasos esenciales en el proce-
so de control de cambios para minimizar el deslizamiento del alcance:
L. Presentar la solicitud de cambio.
2. Registrar la solicitud de cambio.
3. Evaluar el impacto del cambio.
4. Aprobación o rechazo del patrocinador.
5. Documentación del cambio si se aprueba e informar al equipo.
Un proceso aplicado rigurosamente ayudará a asegurarse que los
cambios al proyecto se identifiquen, documenten y procesen. Esto ga-
rantiza que la documentación del proyecto estará actualizada para
reflejar los cambios, que los presupuestos y Programas se ajusten aPro-
piadamente y que, en última instancia, los entregables resultantes del
proyecto satisfagan las expectativas del cliente. Sin un control de los
cambios --créame- reinará el caos y el proyecto estará en peligro de
fracasar o cuando menos de sobrepasar el presupuesto y el Programa.
Permítame darle un ejemplo.
Mi esposa trabajó Para un arquitecto de Columbus, Ohio. Cuando
se incorporó a su empresa, se le entregó un grueso expediente de docu-
mentos que se habían "colectado" para un gran proyecto de construc-
ción para una comunidad de jubilados que la empresa había diseñado
y que tuvo fallas durante el desarrollo del proyecto. Muchos de los do-
cumentos hacían referencia a cambios de diseño que se habían hecho
durante la construcción. Su responsabilidad consistía en negociar el
efecto neto de estos cambios en el contrato con el principal contratista
de la obra y resolver cualquier disputa.
Estableció un diálogo con el contratista y encontró docenas de
cambios no documentados que habían sido introducidos por el gerente
de construcción de la empresa. Ninguno de ellos había pasado Por un
proceso de control de cambios; por consiguiente, nunca se evaluaron
los impactos en el presupuesto y el calendario de la construcción. Sin
embargo, el contratista de la obra había preparado registros del mo-
mento, la fecha y la naturaleza de los cambios dictados y pudo probar
un impacto considerable en el costo y el programa. El resultado es que
toda la utilidad que la empresa había planeado obtener de ese proyecto
desapareció a causa de los cambios no autorizados. Esto pudo haber
sido evitado con sentido común, simplemente siguiendo el proceso de
Control del proyecto 97
control de cambios discutido antes. Recuerde la frase "I-In trato es un
trato, los extras cuestan extra". Es así de simple.
Administración de riesgos y asuntos
Gran parte de la actividad de cambios en los proyectos se refieren real-
mente a los eventos de riesgos que se presentan. Si el equipo hizo un
buen trabajo de discutir los riesgos y las estrategias de respuesta, mu-
chos de estos eventos habrán sido previstos y las respuestas estarán listas
para su implantación. Habrá menos sorpresas y menos labor de apa-
gar fuegos. Sin embargo, aún con el proyecto más simple, surgirán
algunas incógnitas durante el proyecto. Por esta razón,la actividad de
administración de riesgos y asuntos debe ser una actividad continua.
¿Cuál es la diferencia entre un riesgo y un asunto? En el Capítulo 4
discutimos en detalle los riesgos, y a manera de revisión los riesgos
son eventos que pueden socavar o destruir el proyecto que real-
-algo
mente lo puede perjudicar. Es posible prever los riesgos; por consi-
guiente, durante la planeación del proyecto, el equipo anahza los riesgos
potenciales y las respuestas planeadas y todo ello queda incluido en el
plan. A medida que se va desarrollando el proyecto, los riesgos se en-
frentan en forma continua y los nuevos riesgos se manejan de una
manera muy similar a como se hizo durante la planeación. Cuando se
presentan los eventos de riesgos, se aplica la respuesta apropiada.
Por otra parte, los asuntos son sucesos que necesitan ser resueltos
a medida que surgen durante el proyecto. Se monitorean en una hoja
de cálculo simple llamada registro de asuntos. (No se necesita un forma-
to ----es muy simple.) Si quedan sin resolverse, los asuntos pueden
magnificarse a problemas que podrían tener un impacto negativo en el
proyecto. Los asuntos se asignan a alguien para su resolución y se moni-
torean en las reuniones de avance o con mayor frecuencia, dependien-
do de la urgencia.
En los casos de riesgos y asuntos, los gerentes de proyecto con
una actitud preactiva y flexible están mejor equipados para manejar
las malas noticias cuando aparecen inevitablemente sucederá
-como
tarde o temprano. Como se dice comúnmente, Murphy está vivito y
coleando y lo visitará en sus proyectos- sólo que no sabe cuándo.
Continúe involucrando al equipo en la administración de riesgos y
¿rsuntos. Discuta los riesgos, los asuntos y los cambios en todas las reu-
rriones del equipo, para minimizar el número de sorpresas. Los miem-
 II
98 Curtis R. Cook
bros del equipo son quienes están más cercanos al trabajo y, en conse-
cuencia, están mejor equipados para identificar, analizar y responder a
los riesgos que emergen durante el desarrollo del proyecto.
Un recordatorio final. Siga usando el formato de administración
de riesgos ya discutido, para centrarse en los tres elementos que cons-
tituyen un riesgo: el propio evento, su probabilidad de ocurrencia y el
impacto que produce cuando ocurre. Responda a los riesgos mode-
rados y altos y acepte el resto. Y no se empantane en la realidad. Visua-
lícese a sí mismo como una persona dinámica, creativa y ágil. (¿Aquién
no le gusta ser descrito de esta manera?) Recuerde que su trabajo du-
rante la fase de control es mantener el proyecto en curso. Esto requiere
una vigilancia constante, en especial cuando ocurren riesgos y suce-
sos que lo retrasan o lo sacan del presupuesto.
Administración del equipo del proyecto
La administración del equipo se refiere a lidiar con otros individuos al
nivel personal, colaborando con el equipo para lograr los objetivos del
proyecto y simultáneamente ayudando a sus miembros individuales a
alcanzar sus metas profesionales y personales. Y mientras más peque-
ño es el proyecto, más difícil resulta esta labor, debido a que los inte-
grantes del equipo sólo trabajan en él parte de su tiempo. Es un trabajo
difícil, un trabajo que en muchos casos no es intuitivo.
Cuando describimos la fase de planeación, discutimos la impor-
tancia de seleccionar los recursos humanos apropiados para el pro-
yecto. Esto se refiere más a seleccionar a la persona adecuada que a
evaluar su experiencia técnica en el asunto. Es una buena idea discutir
la forma en que el proyecto contribuirá a cristalizar las metas perso-
nales y profesionales de los integrantes, además de su competencia téc-
nica. Cuando los objetivos del proyecto, profesionales y personales
apuntan en la misma dirección,la administración del proyecto se faci-
lita. Cuando existe descontento, es difícil que la gente ponga todo su
corazón y cerebro en el trabajo del proyecto.
Independientemente del tamaño del proyecto o de que el equipo
sea de tiempo completo o de tiempo parcial, su administración es una
de las actividades más cruciales de un gerente de proyectos. Cuando el
equipo está atareado y surgen problemas, se puede fragmentar, con un
impacto desastroso sobre el proyecto. La administración del equipo de
proyectos implica Iiderazgo, motivación, espíritu, resolución de con-
flictos, toma de decisiones y una comunicación constante.
El alcance de este libro limita la atención que podemos darle al li-
derazgo y créame, es mucho lo que todos necesitamos saber cuando tra-
tamos de convencer a los demás de que quieran hacer lo que creemos
es lo correcto. una buena fuente de mayor información iobre la di-
mensión del liderazgo es el llbro Project Leadership de James p. Lewis.
(Véase la sección de lecturas adicionales.) sin embargo, sí echáramos un
vistazo a tres aspectos importantes de la administración de equipos
de conflictos, determinación de expectativas a travéJ dé la
-manejo
constitución del equipo y recompensas a los desempeños sobresalientes.
Manejo de conflictos
una de las tareas más importantes y menos placenteras del gerente del
proyecto es el manejo de los conflictos. Si no hay suficientes conflictos,
el equipo puede estancarse. si el nivel de conflictos es demasiado ele-
vado, el equipo se destruye. En la Figura 5-4 se muestra un modelo
conceptualmente simple para lidiar con los conflictos. Hay cinco enfo-
ques para manejar conflictos, cada uno de ellos apropiado a una cierta
situación. En el modelo mostrado, el eie vertical está relacionado con
la asertividad o firmeza, también conocida como "salirse con la stJya",
mientras que el eje horizontal representa cooperación, también conoci-
da como que la otra parte "se salga con la suya',.
Alto
tr
É.
lU
o
Bajo COPERATIVO
Figura 54. Enfoque al manejo de conflictos.
Competir. El enfoque competitivo suele llamarse ganar-perder, pero
no tiene porqué ser una propuesta perdedora para alguna de las par-
tes. El gerente de proyecto es asertivo en cuanto al aspécto en cuestlón,
¡rresionando su solución con poca cooperación o involucramiento de la
 I
100 Curtis R. Cook
otra parte. ¿Cuándo puede ser apropiado este enfoque? Cuando el tiem-
po es esencial como en los desastres naturales o en la guerra. Mientras
el equipo sea consciente de este enfoque y lo apoye cuando las condi-
ciones lo ameriten, el gerente del proyecto está en lo correcto. Un exceso
de dependencia en el enfoque compeütivo conduce a acusaciones de que
el gerente es un autócrata- lo que ratavez es algo bueno.
Aceptar. En el extremo opuesto está el enfoque de aceptación. Esto
ocurre cuando el gerente del proyecto coopera totalmente con la otra
parte adoptando su propuesta de solución. Este enfoque es apropiado
cuando la otra parte es el experto y su solución es mejor. También es
políticamente apropiado cuando el asunto es de poca importanciapara
el gerente del proyecto, pero le parece importante a la otra parte. Como
reza el dicho, no es necesario ganar todas las batallas para ganar la gue-
rra. Es una buena idea permitir que la otra parte se salga con la suya,
incluso cuando usted pudiera dominar todas las decisiones.
Evitar. Cuando se evita, ambas partes se desentienden del conflicto.
Como estrategia a largo plazo, evitar no funciona. Quienquiera que
haya dicho "Evítalo y desaparecerá" no era un gerente de proyecto.
No obstante, como estrategia de corto plazo es apropiada cuando la at-
mósfera está muy cargada emocionalmente. Si usted siente deseos de
saltar sobre la otra persona sentada en la mesa y aplastarla, es tiempo
de olvidar el asunto durante un tiempo para que se enfríe. En la arena
política, los senadores y diputados a veces posponen un asunto du-
rante un cierto tiempo para que se calmen los ánimos y se pueda reca-
bar información adicional.
Colaboración. En esta estrategia, también llamada resolución de proble-
mas, ambas partes logran casi todo el contenido de sus agendas con-
frontando los temas de frente. Los hechos y los sentimientos se depositan
en la mesa y se discuten abiertamente. Esta estrategia es hermosa, pe-
ro requiere un alto grado de confianza entre las partes y un verdadero
convencimiento de que ninguno de los involucrados tratará de obtener
ventajas de la honestidad de los demás. Esto casi siempre es posible en
proyectos pequeños, pero en los grandes, mi experiencia indica que es
necesario ser muy cuidadosos de no divulgar su forma de pensar has-
ta estar absolutamente seguros de la integridad de la otra parte.
Negociar. ¡Bienvenido al mundo real! La manera más efectiva de re-
solver un conflicto es por medio de la negociación. proceso de to-
mar y ceder. En la negociación,las dos partes están -el
satisfechas de que
Control del proyecto
se han cumplido sus necesidades y ambas apoyan la decisión o resolu-
ción del asunto. No es que la negociación sea fácil y en algunos casos,
ni siquiera deseable, tal como se discutió antes. Pero con una negocia-
ción hábil por cierto es algo que puede aprenderse- casi cual-
-que
quiera puede lograr sus objetivos. ¿Es la negociación siempre el enfoque
correcto? No, como ya se ha dicho. La toma de decisiones por consen-
so forma de enfoque de negociación- consume más tiempo que
los-una
enfoques de competir o evitar. Si no se dispone de tiempo y el
equipo cree estar involucrado en un proceso de consenso, surgirán
problemas si el gerente "se empecina" y toma una decisión unilateral.
Estatuto del equipo. Un aspecto importante de cualquier enfoque que
asuma es el apoyo del equipo cuando se aplique dicho enfoque. ¿Cómo
puede estar seguro de que contará con su apoyo? Una manera es desa-
rrollar un estatuto del equipo desde la primera reunión para planear el
proyecto.
El estatuto del equipo es otro término para las reglas de juego que
su equipo seguirá cuando se reúna por cualquier razón. Los elementos
del estatuto del equipo incluyen:
Etiqueta. El equipo debe decidir las reglas para llegar a tiem-
po, quedarse durante toda la reunión, permitir que los demás
hablen sin interrumpirlos, uso de palabras soeces, faltar a reu-
niones, perturbar, etc. ¿Suena como una escuela de párvulos?
Bien,... en algunos de mis proyectos se ha necesitado este ni-
vel de detalle en cuanto al comportamiento adecuado. Usted
será el juez de cuánto es suficiente para su equipo.
Toma de decisiones y resolución de conflictos. ¿Cuál de los
modelos discutidos antes para tomar decisiones y resolver con-
flictos usará el equipo? Esto debe quedar claramente asentado
en el estatuto del equipo.
e ¿Quién puede convocar a una reunión? ¿Es el gerente del
proyecto el único autorizado para convocar a una reunión? Así
suele ser, pero para equipos más maduros usando un enfoque
colaborativo de toma de decisiones, cualquier miembro del
equipo central puede hacerlo y se espera que los demás miem-
bros respeten su decisión.
Éstos son sólo algunos de los elementos del estatuto de un equipo.
lncluso si usted no establece un estatuto formal, siempre es bueno dis-
cutir estos temas con el equipo para evitar conflictos, resentimientos y
 í
't02 Curtis R. Cook
la resultante pérdida de efectividad. Y una vez que un equipo establece
sus propias reglas, queda en manos del gerente del proyecto del
propio equipo- obligar a su cumplimiento cuando las cosas se-ycom-
pliquen posteriormente.
Recompensas a la excelencia
El gerente del proyecto también es responsable de asegurarse que se
reconozcan los desempeños estelares y que los miembros del equipo re-
ciban recompensas apropiadas por un trabajo bien hecho. Cuando us-
ted se preocupa por su gente, ellos se preocuparán por usted se
sorprenderá de lo fácil que resulta entonces motivar a la mayor-y parte
de sus integrantes. Diferiremos para el próximo capítulo la discusión de
recompensas y celebraciones, al hablar del cierre del proyecto.
Manejo de las relaciones con el cliente
Todos los proyectos empiezan y terminan con el cliente. El manejo de
las relaciones con el cliente tiene dos objetivos. Uno de ellos es estable-
cer una buena relación de trabajo y un alto nivel de confianza con el
cliente, mientras que el otro es lograr su aprobación de los entregables.
Relaciones con el cliente
A lo largo de toda la vida de un proyecto, su gerente es responsable de
mantener al cliente informado y satisfecho. En este esfuerzo, el gerente
del proyecto debe contar con todo el apoyo de todos los niveles geren-
ciales de la organización. Al enfocarse en el cliente, el gerente del pro-
yecto desarrolla las siguientes tareas:
o principal y sin é1, no nos pagarán.
Comprende los requerimientos del cliente
. Desarrolla objetivos del proyecto acordes con los requerimien-
tos del cliente los valida con él antes de iniciar el trabajo.
o -y
Durante la fase de planeación del proyecto, formula el involu-
cramiento del cliente, las comunicaciones y el manejo de las
expectativas.
o Busca la aprobación del cliente del plan del proyecto y los sub-
secuentes cambios al plan durante la ejecución.
Existen diversos métodos para mantener un enfoque en el cliente
y para los gerentes de proyecto exitosos, son un simple asunto de sen-
tido común. No obstante, conviene reiterarlos:
o Conozca al cliente y establezca una buena relación. Aprove-
che la oportunidad inherente de discutir las necesidadcs y
Control del proyecto 103
expectativas del cliente. Conozca la organización del cliente
leyendo la prensa especializada en negocios, buscando en la
Internet o simplemente preguntando.
. Establezca un diálogo continuo con el cliente. Esto va más
allá de la reunión para el reporte típico de avances o el estado
del proyecto. Literalmente significa establecer comunicaciones
personales en ambos sentidos con el cliente y con tantos miem-
bros clave de su personal como le sea posible. Escuche con
atención lo que el cliente dice y enfóquese en ello. Más allá de
la obvia conveniencia que representa construir una mejor rela-
ción, otra ventaja de este nivel de involucramiento es que el
gerente del proyecto puede captar oportunidades de servicios
adicionales y venta de productos.
o Cultive la relación. Una relación profesional bilateral con el
cliente del gerente del proyecto o punto de contacto es un re-
querimiento mínimo. La relación puede ir mucho más lejos,
convirtiéndose en un flujo de confianza mutua y buenas sen-
saciones entre las dos organizaciones.
Aprobación final del cliente
A los ojos de muchos de los interesados, la aprobación final del cliente
señala la conclusión del proyecto. Por supuesto que nosotros, los ge-
rentes de proyectos, sabemos que todavía restan por hacer algunas
tareas administrativas y gerenciales, pero la aprobación es el objetivo
Naturalmente, para obtener la aprobación, el cliente tiene que
estar satisfecho de que hemos cumplido con todos los requerimien-
tos del proyecto. Si hemos hecho un buen trabajo en mantener la re-
lación con el cliente y en manejar los cambios durante la ejecución del
proyecto, las expectativas del cliente habrán sido satisfechas y la apro-
bación formal será fácil. Si no ha sido asi es probable que existan ex-
pectativas no cumplidas y sentimientos negativos. Supongamos que
tenemos una buena relación y que los entregables concuerdan con lo
que el cliente esperaba ver.
En este punto, sólo asegúrese que se han satisfecho todos los re-
cluerimientos del proyecto y que los asuntos abiertos estén documen-
tados y asignados para su seguimiento. Revise los documentos del
¡rroyecto, las cspecificaciones, la lista de entregables y los contratos, si
('s (lu(' los lr.ry, l),ilra ('ontprobar c¡ue sc ha cunr¡rlicl<l con todos los com-
 n

104 Curtis R. Cook

promisos. Una vez terminada la revisión, prepare un documento for-

mal de aprobación para ser firmado por el cliente. Este documento de
aceptación debe constar por escrito pues constituye la base para poder
facturarle al cliente el trabajo realizado.

Transición a la fase de cierre

El proyecto está casi terminado. El cliente está satisfecho y desea conti-
nuar haciendo negocios con nosotros. Ahora ya estamos listos para
finalizar el proyecto, recompensar al equipo y reciclar esas lecciones
tan duramente aprendidas para equipos del futuro. Todo esto se dis-
Gierre del proyecto
cute en el siguiente y excitante capítulo sobre el cierre del proyecto.

I-
F
l- I cierre es la última fase del ciclo de vida del proyecto. El proyec-
to se considera completo cuando su gerente ha verificado que se ha
cumplido con todos los objetivos y el cliente ha aceptado todos los
entregables eso no es todo. ¿Recuerda el proyecto del día de
-peroEl gerente del proyecto todavía tiene algunos "que-
acción de gracias?
haceres" por realizar antes de que el proyecto esté realmente termina-
do, tal como se muestra en la Figura 6-1.
Las actividades del cierre del proyecto siempre son importantes,
cualquiera que sea su tamaño, y sin embargo son raras las ocasiones un
que el proyecto se cierra correctamente. Esto casi siempre se debe al
hecho de que la gente que realizó el trabajo puede ya haber sido asig-
nada a otros proyectos. Es simplemente la naturaleza de trabajar en
una matriz con un equipo integrado por individuos que sólo usan parte
de su tiempo. Pero también es cierto porque muchos gerentes de pro-
yectos no saben qué deben hacer para cerrar un proyecto de manera
apropiada o simplemente porque no se toman el tiempo debido a las
presiones de otros trabajos.
Cuando los proyectos no se completan de forma adecuada, per-
demos una oportunidad de oro para mejorar, y las mejoras son uno de
los motivadores humanos más importantes; todos queremos ser me-
jores en lo que hacemos. El cierre del proyecto es un mecanismo muy
poderoso para mejorar. Independientemente que el proyecto haya si-
do perfecto o tenido algunas fallas, contiene las semillas del éxito de
proyectos futuros. ¿Qué hicimos bien? ¿En qué nos equivocamos?
 II

106 Curtis R. Cook Cierre del proyecto 107

¿Cómo podemos beneficiamos de lo que aprendimos? Este capítulo lo

equipará con algunas herramientas útiles para ayudarlo a enfocarse en
estas cuestiones.
Antes de discutir el "cómo hacerlo" del cierre de un proyecto,
puede resultar interesante analizarlo desde la perspectiva opuesta.
¿Qué pasa si no cerramos los proyectos? suceden varias cosas y todas
ellas son negativas.
La moral del equipo se deteriora. Esto ocurre por dos razones:

' Primero, contar con un objetivo claro y la sensación de finali-

zación que nos embarga cuando alcanzamos el objeüvo, es un
motivador para casi todos. Si el proyecto no se cierra de ma-
nera apropiada, sino que se deja languidecer y tener una muer-
te lenta, los miembros del equipo se desintegran sin tener una
sensación de finalización. Como resultado, estas mismas per-
sonas estarán menos motivadas para dedicarse a desafíos de
proyectos en el futuro.
. Segundo, la mayor parte de la gente se siente motivada por el
reconocimiento de los gerentes y sus pares por haber realizado
un buen trabajo. Los teóricos de la motivación le llaman a esto
necesidades de estima y, de acuerdo a mi experiencia, la mayor
parte de los integrantes de equipos de proyectos funcionan a
este nivel. Cuando no cerramos los proyectos, por lo general no
le otorgamos nuestro reconocimiento a los miembroi del equi-
po por su desempeño. No se satisfacen sus necesidades de es-
tima y perdemos una gran oportunidad.
Los costos aumentan. El segundo problema que resulta de no cerrar el
proyecto está en el área de los costos. Los proyectos abiertos son imanes
para los costos, lo cual conduce a excesos. Esto ocurre por un par de
razones:
o Los miembros del equipo que todavía están o se sienten asig-
nados al proyecto continúan "pellizcando" los entregables y
acumulando costos. Estas mejoras deberían en realidad ser el
principio de un nuevo proyecto, la versión "nueva y mejorada,,
de un producto o servicio, pero, como el viejo proyecto está téc-
nicamente vivo, el trabajo continúa. Por desgracia, el cliente ya
ha aceptado el entregable, por lo que los costos de las mejoras
Figura 6-1. Diagrama de bloques del proceso destacando los pasos del ciene. no sc recuperan.
 n

108 Curtis R. Cook Cierre del proyecto 109

. En muchas organizaciones, el protocolo del proyecto contiene sido firmado y regresado por el cliente. Para clientes internos, tal como
un código de cargos contra el que se acumula el costo del tiem- una unidad de negocios actuando como cliente para un proyecto de
po de los miembros del equipo. IJna vez que el entregable ha tecnología de la informacióry quizás no obtenga una aceptación formal
sido transferido al cliente, el gerente del proyecto debe cerrar por escrito. En este caso, conviene validar los siguientes aspectos de
la cuenta. De otra manera, el proyecto será un imán para pe- la misma manera en que lo haría para un cliente externo.
queños detalles que sólo están periféricamente relacionados
con el proyecto. También hay la posibilidad de que alguien UN MODELO FÁCILY RÁPIDO
pueda cargar su tiempo a la cuenta del proyecto abierto en vez
de contabilizarlo como un gasto administrativo beso de la
muerte en una organización de servicio.
-el
Se pierden las lecciones aprendidas. Finalmente, si un proyecto no se
cierra, no se recogerán las lecciones aprendidas para ayudar a futuros
equipos de proyectos. Las lecciones aprendidas son uno de los me-
dios más importantes para mejorar nuestro desempeño. Amenos que el
proyecto se cierre apropiadamente, las lecciones aprendidas correll
el riesgo de perderse
-y esto es un desperdicio real y triste.
l^r
'"lffi"
Ahora que ya hemos visto los inconvenientes de no cerrar bien un
proyecto, CentremoS nuestra atención en cómo hacerlO correctamente.
Empiece por plantearse las cuatro preguntas que se transcriben a con-
tinuación. Si sus respuestas a estas preguntas son satisfactorias, es muy
probable que el proyecto haya sido terminado satisfactoriamente.
G
Figura 6-2. Modelo de cierre de un proyecto.
o ¿Se cumplieron las expectativas?
o ¿Se alcanzaron los objetivos? Recabe la aceptación y aprobación del resultado final. Firmada, si es
o ¿Aprendimos algo?
posible, o si no, mediante un correo electrónico como mínimo.
o ¿Hemos comunicado nuestro agradecimiento y reconocimiento? Evalúe qué tan bien se cumplieron las expectativas. Como un asunto
práctico, ¿cómo puede medir la satisfacción? Muchas organizaciones
Recuerde que usted y el patrocinador especificaron los criterios de usan una encuesta de satisfacción del cliente, con lo que se conoce
éxito y finalización en la etapa de inicio, por lo que usted puede saber como escala de Likert, para medir la satisfacción en una escala de, por
si se lograron o no los objetivos. ejemplo, del 1 al 7. Si ha mantenido una buena relación con el cliente a
través de todo el proyecto, tal como se discutió en el Capítulo 5, sabrá
Modelo para cerrar el proyecto si el cliente está satisfecho con el resultado final.
Démosle al cierre del proyecto una estructura, considerándolo como Ate los cabos sueltos. Esta es una categoría especial para conside-
un modelo de tres pasos, tal como se muestra en la Figura 6-2. rar todos los pequeños detalles que requieran atención al final del pro-
Entrega yecto. La Figura 6-3 muestra una lista de verificación de cierre de
Recordará que discutimos la aprobación del cliente como la última proyecto que es probablemente mucho más extensa que lo usted ne-
actividad de la fase de control del proyecto, por lo que en este punto cesita para cerrar su proyecto. Pero creo que en este caso es mejor
sólo necesita asegurarse que el documento de aceptación formal ha tener demasiado detalle que muy poco,
 110 Curtis R. Cook
Reciclaje
Esto se refiere a capturar las lecciones aprendidas y darles uso para
equipos de proyectos futuros.
captura de las lecciones aprendidas. En retrospectiva, cualquier pro-
yecto podría haber sido manejado en forma un poco diferente, quizás
un poco mejor, si el gerente del proyecto y el equipo hubieran tenido
más experiencia con el cliente, la tecnología o la situación particulares.
Capturar las lecciones aprendidas en el proyecto es una gran manera
de proporcionarles información a los equipos futuros. Al conjuntar las
lecciones aprendidas y ponerlas a la disposición de otros, podemos evi-
tar tener que aprender de la "manera dura".
Existen varios métodos para capturar las lecciones aprendidas,
pero discutiremos un par de ellos que deben bastar para sus proyectos.
Enfoque informal. En la mayor parte de los proyectos, para cuando
el cliente finalmente acepta los bienes o servicios, varios integrantes
del equipo han sido reasignados a otros proyectos. Esperar que pre-
paren un reporte formal de lecciones aprendidas es poco realista. una
manera fácll y divertida de lograrlo consiste en combinar el ejercicio
con una celebración del proyecto. Reúna al equipo para unos bocadi-
llos y bebidas y circule entre ellos, haciéndole a cada uno la siguiente
pregunta. se sorprenderá de las valiosas percepciones que obtendrá.
Documente las respuestas en un memorando de lecciones aprendidas
que podrá ser enviado a otros equipos.
Si usted pudiera transmitir una lección aprendida de su expe-
riencia en este proyecto a un miembro de un equipo futuro,
¿cuál sería?
se asombrará de las cándidas respuestas que surgirán cuando
actúe de esta manera. se trata de lecciones reales aportadas cuando la
gente "se suelta el pelo", que podrá usar de inmediato en la planeación
de riesgos, integración de equipos, planeación y control de proyectos,
y construcción de relaciones con los clientes. Por supuesto que no que-
rrá atribuir respuestas específicas d personas específicas.
Enfoque formal. En los proyectos grandes, el gerente del proyecto
probablemente necesitará ir más allá de este método informal y com-
pilar un documento formal de lecciones aprendidas. En la Figura 6-4
se muestra un formato detallado y formal de lecciones aprendidas.
INFORMACIÓN PARA LA PREPARACIÓN DE DOCUMENTOS
NOMBREDEL IPREPARADOPOR lr¡cHRo¡
PROYECTO I I PREPARACIÓN
PROYECTO (MARQUE EL CUADRO CUANDO SE COMPLETE)
o ¿Existen algunos entregables pendientes?
o ¿Hay algunos compromisos internos pendientes?
o ¿Se han cargado al proyecto todos los costos atribuibles al mismo?
D ¿Se ha cerrado el código contable de cargos para evitar que se le sigan
adjudicando costos al proyecto?
tr ¿Se han completado todas las tareas?
o ¿Se le ha notificado a la gerencia la disponibilidad del personal del
proyecto?
¿se le ha notificado a la gerencia la liberación de las instalaciones usadas
para el proyecto?
¿Se ha hecho algo con respecto a los sobrantes de materiales usados en
el proyecto?
¿Se ha cumplido con el plan del proyecto con toda la información de
soporte?
¿Se han notificado a los proveedores cualesquiera compromisos
pendientes?
D ¿Están enterados todos los interesados del cierre del proyecto?
o ¿Se ha transferido el proyecto a operaciones y soporte?
D (Añada aspectos específicos de su proyecto.)
PERSONAL: INTERNO
a ¿Se ha preocupado de que los miembros de alto desempeño del equipo
sean asignados a proyectos futuros?
o ¿S-e ha recompensado apropiadamente a los miembros del equipo por sus
esfuerzos si el proyecto fue exitoso?
o ¿Hubo una celebración del proyecto?
o (Añada aspectos adicionales específicos de su proyecto)
ASUNTOS EXTERNOS
o ¿se está aplicando un proceso para mantener la relación con el cliente?
o ¿Se les ha informado a los proveedores y subcontratistas el estado del
proyecto y las oportunidades futuras?
o (Añada aspectos especÍficos de su proyecto.)
Figura 6-3" Lista de verificación del cierre del proyecto
 L12 Curtis R. Cook
Incluso en proyectos pequeños, este formato proporciona una exce-
lente lista de "cosas en qué pensar" cuando se procede a cerrar el pro -
yecto. sin embargo, no pase por alto el enfoque informal sólo porque
esté usando esta lista.
LISTA DE veRITIcRcIÓN DE LEccIoNEs APRENDIDAS
El propósito de este cuestionario es ayudar a revisar los resultados del
proyecto y traducir dichos resultados a lecciones aprendidas y
recomendaciones de mejoras
¿Está orgulloso de su producto o servicio final?
¿Qué haría diferente la sigu¡ente vezpa'a
evitar esta frustración?
¿Cuál fue la parte más gratificante o profesio-
nalmente más satisfactoria del proyecto?
¿Le ayudo el proceso de adm¡nishación de proyectos
justamente suficiente? ¿Cuál de sus técnicas
funcionó especialmente bien para usted?
¿Qué técnicas resultaron frustrantes o difíciles
para usted? ¿Qué se podría hacer para mejorar
el proceso?
¿Asignamos las personas adecuadas a los papeles
del proyecto? (Considere la experiencia en
el asunto, las contribuciones técnicas, el manejo,
la revisión y la aprobación y otros papeles clave.)
Si no fue así, ¿cómo podríamos asegurarnos de
obtener las personas adecuadas la próxíma vez?
¿Participaron efec{ivamente nuestros interesados?
Si no fue así, ¿cómo podríamos mejorar
su participación?
Figura 64. Lista de verificación de las lec¡iones aprendidas. (continúa)
Cierre del proyecto 113
PTANEACIOÑ
ár"gunü. Respúesta:
¿Faltaron los miembros o los interesados
necesarios a la reunión de arranque o a otras
reuniones? ¿Cómo podrÍamos ev¡tar las ausencias
en el futuro?
tNfcro pEr p.RoYEcTo
¿ldentificó nuestra definición de requerimientos todos
los entregables del proyecto que finalmente se
obtuvieron? ¿Cumplieron los productos entre-
gados los objetivos especificados en el proyecto?
Si no fue así, ¿qué nos faltó y como podríamos
estar seguros de capturar los requerimientos
nec€sarios en proyectos futuros?
¿ldentificó nuestra definición de requerimientos
entregables algunos innecesarios? Si así sucedió,
¿cómo podríamos evitar esto en el futuro?
¿Capturó adecuadamente el protocolo del proyecto
toda la información relevante para iniciarlo
exitosamente? Si no fue así, ¿cómo podríamos
hacerlo mejor en el futuro?
FLANHé16N
¿Se delinearon y se comunicaron claramente todos
los papeles y responsabilidades de los miembros
del equipo y los interesados? Si no fue así, ¿cómo
podríamos haberlo hecho mejor?
¿Se dividieron en tareas al nivel apropiado
los objet¡vos del proyecto? ¿Se creó una
estructura completa de división del trabajo?
¿Se formuló el programa usando la EDT y se
comunicó esta información al miembro del equipo
o al ¡nteresado apropiado? Si no fue asÍ, ¿cómo
podríamos mejorar este aspecto?
¿Se generó un presupuesto del proyecto usando
la EDT? Si no se hizo así, ¿cuál fue la base
para estimar el presupuesto del proyecto?
¿Cómo podría mejorarse?
Figura 64. Lista de verificación de las lecciones aprendidas. (continúa)
Ll4 Curtis R. Cook Cierre del proyecto 115

PLANEACION CIERRE
Fregunta Rés[üésta,,:,:,,'::.:.:::,::':::::::;::t', Piégün!á Respuéstá
¿Se identificaron y mitigaron los riesgos?
¿Podríamos haber completado este proyecto sin uno ¿Fue nuestra entrega al cliente una transición tersa
o más de los proveedores y/o subcontratistas? y fácil? Si no fue así, ¿cómo podríamos haber
Si la contestación es af¡rmativa, explique cómo. mejorado este proceso?

¿Se aclararon a todos los proveedores y/o subcon- ¿Capturamos las lecciones aprend¡das por el equipo?
tratistas nuestras restricciones, limitaciones y
¿Reciclamos las lecciones aprendidas de tal manera
requerimientos desde el principio? Si no se hizo, que sean accesibles y puedan ser usadas
¿cómo podríamos mejorar nuestros enunciados por equipos futuros?
de trabajo?
¿Celebramos nuestro éxito y recompensamos
apropiadamente a los miembros del equipo?
¿Fue el proceso de asignación de recursos internos
Si no lo hicimos, ¿por qué no? ¿Cómo podríamos
adecuado para identificar y lograr compromisos
asegurarnos en el futuro de otorgar un recono-
del tipo y magnitud necesarios para el proyecto?
cimiento adecuado?
Si no fue así, ¿cómo podrÍamos mejorarlo?

CONTROL Figura 6-4. Lista de verificación de las lecciones aprendidas.

¿Cumplimos con los objetivos de nuestro programa?
Si no fue así, ¿por qué no y cómo podríamos
Recicle la información útil. lJna vez capturadas las lecciones aprendidas,
mejorar nuestro proceso de control del programa
en proyectos futuros? ¿cómo podremos asegurarnos que estén disponibles para futuros equi-
pos? Esta es, mis amigos,la pregunta de $64,000. No tiene objeto compilar
¿Cumplimos con nuestros objetivos de costos?
Si no fue así, ¿por qué no y cómo podríamos las lecciones aprendidas si no se usan. Permítame proporcionarle un par
mejorar nuestro proceso de control de costos de trucos que he aprendido en mi canera para superar este obstáculo.
en el futuro?
Establezca un sitio intranet para las lecciones aprendidas. Si
¿Obtuvimos una retroalimentación oportuna del usted trabaja en una organización de gran tamaño, ésta es una
equipo y el cliente sobre la calidad y puntualidad
opción viable. Establezca el sitio e infórmele a todos los que us-
de nuestros entregables? Si no fue así, ¿cómo
podríamos mejorar el proceso en el futuro? ted sepa que están relacionados con proyectos. Alguien tendrá
que alimentar las lecciones aprendidas, pero, como es verda-
¿Se prepararon a tiempo nuestros reportes
de avance, tanto para el equ¡po como para deramente útil para los gerentes de proyectos aprender de los
la gerencia? ¿Fueron útiles para monitorear errores de los demás, estarán motivados para incorporar sus
el proyecto? Si no fue así, ¿por qué no? resultados. Claro está, funciona mejor si existe una oficina de
administración de proyectos (OAP), pero muy pocas organiza-
¿Qué funcionó bien en el proceso de revisión
y aprobación?
ciones han establecido OAPs. Si usted tiene la suerte de que
exista una OAP, este departamento cuenta con un archivo al día
¿Fue efectivo nuestro proceso para administrar de lecciones aprendidas y actualiza la metodología (si la tie-
los cambios? ne) de la administración de proyectos, para reflejar las mejores
prácticas derivadas de las lecciones aprendidas.
Envíe correos electrónicos a todos los miembros del equipo.
Figura 64. Lista de verificación de las lecciones aprendidas. (continúa) ('olrro rrríninro, el gerente del proyecto debe enviar por correo
 1,r6 Curtis R. Cook
electrónico las lecciones aprendidas a todos los integrantes del
equipo del proyecto y a otras personas de la organización in-
volucradas en proyectos.
. El gerente del proyecto y los miembros clave del equipo de-
ben asistir a sesiones de planeación de otros proyectos para
transmitir en persona las lecciones aprendidas. Esto funcio-
na muy bien. Cuando un nuevo equipo se reúne a discutir los
riesgos, es el momento perfecto para que el gerente de proyec-
to asista y comunique los sucesos de proyectos similares.
Algunas organizaciones lo han hecho obligatorio debido a su
gran utilidad.
La acción menos útil que puede emprender es redactar un repor-
te formal de las lecciones aprendidas y guardarlo en el expediente del
proyecto, sin hacer nada más. Los gerentes de proyectos no tienen
tiempo para leer los archivos de otros proyectos. Desde luego que se
debe archivar una copia de estas lecciones aprendidas, pero eso no es
lo único que debe hacer su contenido.
pasa cuando -disemine
las lecciones aprendidas no se compilan o re-
¿Qué
ciclan para su uso futuro? seguiremos cometiendo los mismos estú-
pidos errores una y otravez. Me apena decirlo tan rudamente, pero es
la verdad. Veamos un ejemplo. Hace tiempo trabajé en un proyecto
grande para desarrollar un sistema de comunicaciones a prueba de
interferencias para ser usado por nuestras tropas en combate. claro
está, la idea consistía en lograr un sistema que impidiera que nuestras
comunicaciones fueran escuchadas por los "malos". Esto, por cierto,
sucedió hace un par de décadas.
Al principio del programa, la Fuerza Aérea y la Marina estaban
desarrollando tecnologías competidoras. Esto se hizo a propósito para
poder seleccionar la tecnología más promisoria e incorporarla al siste-
ma. Las primeras pruebas mostraron que uno de los enfoques técni-
cos era superior y que estaría listo anteJque el otro. Lo más inteligente
que se podría haber hecho en ese momento era tomar la decisión de
cancelar el desarrollo de la tecnología menos promisoria y seguir con
un solo enfoque. Pero esto no sucedió.
Pasamos a la fase de construcción de prototipos. se desarrollaron
y probaron ambos prototipos. Antes de eso habíamos experimentado
que el desarrollo de dos enfoques paralelos se comería nuestro pre-
supuesto y causaría problemas de recursos humanos, pero no aprendi-
Cierre del proyecto L17
mos de esa lección. Uno de los prototipos (el de mejor tecnología) era
superior, pero, debido al involucramiento de la política, se permitió
que ambos programas continuaran.
¿Qué sucedió como resultado de no aplicar esta lección obvia? En
última instancia, ambos sistemas pasaron a producirse a un ritmo bajo
y se usaron en el campo. La Marina usó uno, las otras fuerzas armadas
el otro. En un escenario real de una zona alejada del mundo, sucedió
que los pilotos de la Marinay la Fuerza Aérea usaban diferentes siste-
mas y en algunos casos ni siquiera podían comunicarse entre ellos. La
triste realidad es que tuvieron que intercambiar información Por me-
dio de discos blandos antes de iniciar las operaciones del día. Como
resultado de este fracaso, el Secretario de la Defensa descontinuó uno
de los programas sólo después de mucho sufrimiento, desper-
-pero
dicio de dinero y dificultades operativas. En la actualidad, el problema
ya está arreglado, pero hubiera sido todo mucho más fácil si se hubiera
aplicado antes la lección aprendida.
Celebre. La tarea final del gerente del proyecto consiste en recomPen-
sar a los miembros de su equipo y proceder a una pequeña celebración
para proceder al cierre del proyecto y la disolución del grupo' Es ex-
traño, pero algunos gerentes de proyectos no celebran sus éxitos ---casi
como si fueran alérgicos a la diversión. ¿En dónde está escrito que la
administración de proyectos tiene que ser desagradable? Salga y cele-
bre cuando logre algo que haya valido la pena. Es también una buena
práctica en la vida.
Proceda al cierre
Ya hemos discutido esto como una necesidad humana básica. La cele-
bración del proyecto, el ejercicio de lecciones aprendidas y unas cuan-
tas palabras del patrocinador y del gerente del proyecto sirven muy
bien a este propósito. El patrocinador cebe hacerle sabe al equipo lo
mucho que se aprecian sus esfuerzos y lo mucho que el proyecto influi-
rá en la organización.
Gomunique los logros
Hay una vieja canción folclórica con una letra que dice más o menos
lo siguiente: "No puedes ser un faro si tu luz no brilla". No importa lo
bien que se hayan desempeñado los miembros del equipo si usted no
se lo cuenta al mundo. ¿Recuerda la discusión sobre las necesidades
de estinra cit' la nrayoría de los participantes de un proyecto? Llegó el
118 Curtis R. Cook
momento de dejar que brille su luz. Le sugiero que Intente usar estas
técnicas simples:
' Publique los resultados del proyecto en la revista o boletín de
la empresa, completos y con fotografías.
' Publique proyectos notables redactando artículos para ser so-
metidos a la consideración de los editores de revistas y pe-
riódicos especializados. Por ejemplo, el project Management
Institute publica en forma rutinaria los resultados de proyectos
importantes.
Pídale al patrocinador que hable sobre el proyecto en la si-
guiente reunión pública de la empresa.
' si su compañía tiene transmisiones internas en un sistema de
video, pídale al patrocinador que reconozca el esfuerzo del
equipo en ese foro.
Demuestre su aprec¡o a todos los involucrados
Finalmente, demuéstrele al equipo que aprecia sus esfuerzos. Hay
varias maneras efectivas de hacerlo:
' organice una fiesta. Hemos hablado de esto a lo largo de todo
el libro; ahora es el momento de hacerlo. por lo general, a la
gente le gusta divertirse y ya hemos discutido la forma en que
valora el cierre y desea que se reconozcan sus esfuerzos. Como
una celebración del proyecto (por favor, no lo llame ,,postmor_
temz quién le gusta ir a una fiesta con un nom6re como
-¿a
éste?), usted, como gerente del proyecto haga un discurso corto
reconociendo las contribuciones de todos, presente al patroci-
nador para que haga lo mismo y después relájese, circule y, como
ya se dijo, capture conversacionalmente unas cuantas leccio-
nes aprendidas. Acuérdese de divertirse. Aunque se dé el caso
de que su organización no permita celebraciones de proyectos
pagadas por la empresa, los mejores gerentes de proyeclos las
hacén por su cuenta.
' Escriba cartas. Tómese tiempo para escribir cartas de agrade-
cimiento a los supervisores de los miembros del equipó, con
copia para el individuo en cuestión. Esta técnica simplé persi-
gue dos propósitos. Primero,le inyecta al individuo una bre.ru
dosis de estima. Segundo, le proporciona a sus jefes, quienes
probablemente son gerentes funcionales, algo para añadir al
reporte de desempeño de su subordinado. Se lo agradecerán.
Sin embargo, debe ser cuidadoso de no escribirle una carta a
todos o de elogiar a todos por igual cuando no lo merezcan.
Cuide muchos a los de alto desempeño y trabaje con los demás
para darles una retroalimentación honesta y sugerencias para
mejorar. Esto es también un regalo.
Transición a operac¡ones, apoyo
y mantenimiento
El proyecto está terminado. Ha recompensado al equipo y ha cerrado
las cuentas, y se ha asegurado que el cliente esté satisfecho. Una últi-
ma verificación antes de pasar a su siguiente asignación es reasegu-
rarse que el entregable y el cliente están siendo apoyados por la
división de operaciones de la empresa.
¿Cómo hacer esto? Si ésta es la primera vez que surge el tema a
colación, está en problemas. Las personas de operaciones deben haber
identificado al interesado clave al crearse el protocolo del proyecto y
haber tenido la oportunidad de participar en las fases de planeación
y control.
Quizás no asistieron a todas las reuniones, pero cuando apareció
en la agenda el tema de apoyo postproyecto por primera vez, deberían
haber estado presentes.
Pero, suponiendo que han participado en el proyecto hasta este
punto, su principal tarea será asegurarse que se haya hecho la transi-
ción y que no existan cabos sueltos. Su mayor desafío consistirá en
lograr que el cliente se acostumbre a no contar ya con la atención cons-
tante que usted le ha estado dando y prepararlo para la clase de
contactos y apoyos que recibirá después del cierre del proyecto. Por
fortuna, la mayor parte de nosotros trabajamos con gerentes de cuenta
que cuidan las relaciones con el cliente antes, durante (hasta cierto
punto) y después de la ejecución de un proyecto. La mayoría de las
organizaciones maneja muchos proyectos para clientes de larga rela-
ción con la empresa, por lo que los gerentes de cuenta son esenciales
para mantener relaciones que impidan que el cliente se sienta menos-
preciado una vez que se disuelve el equipo del proyecto.
Cuando usted y el patrocinador ya estén totalmente seguros que
l¿r trilrrsicir'rrr st' ha llevado a cabo completamente y sin problemas, es
120 Curtis R. Cook

tiempo de levantar su tienda de campaña y pasar al siguiente proyec-

to. ¡Buen trabajo!

Administración de proyectos múltiples

usando los principios de Los cuatro pasos indispensables para adminis-
trar proyectos con base en una administración justamente suficiente, sin
duda podrá salir triunfante en el manejo dé proyectos únicos. pero,
desgraciadamente, la mayoría de nosotros manejamos más de un pro-
yecto al mismo tiempo. ¿C9mo podemos lidiar con esta sobrecarla y
malabarear exitosa y simultáneamente muchos proyectos? Éste es ét
Manejo de proyectos
tópico del capítulo final
ayuda para una situación-por
lo que le conviene ieeilo como una gran
muy desafiante.
múltiples y sobrecarga
de proyectos

ejanos están los días cuando se iniciaba y terminaba un proyecto

antes de empezar con otro. Esto no sucede ni en nuestra casa, ni en la
iglesia, ni en la escuela y ni en el trabajo. Nos guste o no, nuestra reali-
dad implica manejar simultáneamente proyectos múltiples. ¿Qué po-
demos hacer en la práctica para copar con esta situación? Tenemos que
encontrar la manera de manejar esta sobrecarga o correremos el riesgo
de quemarnos, frustrarnos o ser despedidos.
Este capítulo le proporcionará las herramientas y técnicas simples
para manejar varios proyectos al mismo tiempo y hacerlo bien
poco de administración, fijación de prioridades y aprender cómo decir
-un
no de buena manera. Estas técnicas bien conocidas contribuyen a lo-
grar un nivel de estrés más bajo y en última instancia resultan en una
mejor administración de proyectos en toda la organización.

La sobrecarga como norma

La sobrecarga se ha convertido en norma en casi todas las organizacio-
nes. La sobrecarga de comunicaciones,la cultura corporativa de sobre-
tiempo y la incapacidad o renuencia de decir no, nos meten en problemas.
Para iniciar esta discusión, puede resultar útil y revelador pensar en la
forma cn qr.rc rnarreiamos actualmente la sobrecarga de trabajo.
 r22 Curtis R. Cook
Todas las organizaciones con las que he trabajado desde prin-
cipios de siglo (el siglo más reciente) han incrementado la carga de
trabajo de sus empleados. Esto se debe primordialmente a la intensa pre-
sión competitiva en casi todos los países del orbe, acoplada con la presión
de los accionistas y del mercado para lograr un desempeño financiero
y un crecimiento siempre crecientes.
En su esfuerzo por mantener controlados los costos, la gerencia
anabza primero la mano de obra directa y su carga asociada o gastos
indirectos. Los beneficios para los empleados son costosos. Todo em-
pleado debe contar con prestaciones que incluyen planes de jubilación,
seguro de enfermedades, atención dental, cuidados de la vista, seguro
de vida, seguro de incapacidad, vacaciones con goce de sueldo, etc.
Sólo los cuidados de la salud han crecido dramáticamente cada año
durante varios años y no muestran indicios de disminuir. Como resul-
tado, la presión sobre la gerencia para reducir los costos de la mano de
obra directa, con sus costos indirectos asociados, ha sido muy intensa.
En compañías de bajo crecimiento, la cantidad de despidos ha sido
dramática. En empresas con un crecimiento sostenido, se han creado
pocos empleos o ninguno para manejar el trabajo adicional. La fuerza
laboral existente tiene que absorber una carga mayor. No sorprende
por ello que muchas compañías subcontraten algunos de sus trabajos
en el extranjero, donde las expectativas y demandas de la fuerza la-
boral son menores.
Como presidente de una empresa, yo mismo he experimentado
esta presión de primera mano. Para mantener o incrementar la partici-
pación de mercado, los productos y servicios de nuestra compañía
tienen que ser cuando menos tan buenos como los de la competencia y
en muchos casos mejores. En la actualidad,la mayor parte de las deci-
siones de compra están basadas en el mejor valor mejor solución
-la maduro,los
técnica con el mejor servicio. Sin embargo, en un mercado
compradores no diferencian entre los productos competidores- supo-
nen que todos son suficientemente buenos para satisfacer sus necesi-
dades. Esto nos lleva intensas presiones en precios y la administración
de los costos.
La consecuencia de todo esto es que la gerencia es renuente a aña-
dir personal a su fuerza laboral. Cuando el negocio mejora, el trabajo
es realizado por la misma fuerza de trabajo y, como resultado, todos tie-
nen más responsabilidades que las que tenían en "los buenos viejos
Manejo de proyectos múltiples... 723
tiempos". Necesitamos algunas herramientas prácticas para ayudar-
nos a manejar nuestras crecientes cargas de trabajo. Por sí misma, Ia
adopción de la administración de proyectos es una manera de hacer
más con menos. Los equipos de proyectos son más eficientes y efecti-
vos que los equipos funcionales para manejar el trabajo de proyectos.
Suponiendo que usted utilice las técnicas descritas en este libro para
administrar los proyectos individuales, ¿qué otra cosa puede hacer pa-
ra ayudarlo a malabarear proyectos múltiples y un programa sobre-
cargado?
Es posible aplicar algunas técnicas simples para que primero re-
conozca y después maneje la sobrecarga. El enfoque de justamente lo
suficiente no está basado en softwares complicados diferentes a los que
casi todos nosotros usamos coüdianamente. Con un block de notas au-
toadheribles y una evaluación honesta de la sobrecarga, usted podrá
aplicar este marco de referencia práctico para administrar su tiempo
sus proyectos. Estas técnicas funcionan- depende de usted que
-y
las lleve a la práctica.
La interconex¡ón de todo
El primer paso para manejar proyectos múltiples es darse cuenta de
que sus proyectos estén realmente interconectados. Durante años,
los que nos dedicamos al negocio de la educación en la administración
de proyectos nos desvivimos por ayudar a la gente y a las organizacio-
nes a manejar proyectos aislados con mayor efectividad. Ahora esta-
mos en la era en la que se enfatiza la administración de un portafolio
en muchas organizaciones.
El tratamiento detallado de la administración de portafolio- o
programas múltiples- queda fuera de los alcances de este libro, pero
podemos aplicar algunos pasos de sentido común que nos ayudarán a
manejar nuestra carga de trabajo desde la perspectiva de que casi todo
lo que hacemos está relacionado con algo más en lo que estamos traba-
jando. Las diversas relaciones entre nuestros proyectos y tareas pue-
den describirse como separadas, dependientes e interdependientes.
Separados
En este escenario, consideramos cada proyecto como una entidad se-
parada, tal como lo ilustra la Figura 7-1.Esta perspectiva tiene las si-
guien tcs c¿r ractcrísticas:
t24 Curtis R. Cook
a Cada proyecto está completamente separado.
a No hay relaciones de dependencia.
a No hay recursos comunes.
a Tienen programas separados.
a Los proyectos sólo tienen en común el hecho de ser resPon-
sabilidad de un mismo gerente de proyectos.
Figura 7-1. Proyectos separados.
Este escenario rara vez es preciso y nos puede causar problemas
cuando descubramos, por ejemplo, que nuestros proyectos realmente
comparten recursos. Cuando una persona clave se atrasa en un proyecto
y dicho retraso tiene un impacto en otro proyecto, vemos que esta pers-
pectiva no refleja la verdadera relación entre proyectos.
Dependientes
En este escenario, los proyectos están relacionados al nivel de proyec-
to, tal como lo muestra la Figura 7-2. Bajo este punto de vista, los pro-
yectos A, B, C y D son todos separados, pero están relacionados de
otras maneras:
:t::::::
:,,,::,
A B,,
'....i.::..'---.llll ii,::::i:,:;i::,,,:i
\ construir un cobertizo pata almacenamiento. El proyecto A
iiiiiiiiiiiiiiiiiiiiiiiii:iii::iiii
:Gt:i;.:::..:..:...:,:.:.:;
Figura 7-2. Proyectos dependientes.
Maneio de proyectos múltiples... 125
o Los proyectos pueden tener una relación de dependencia con
otro proyecto. Por ejemplo, quizás la nueva tecnología que se
está desarrollando en el proyecto A se usará en el proyecto B.
Si A se retrasa, B también lo hará.
o Los proyectos puede tener una fuente común de recursos hu-
manos. Si los cuatro proyectos dependen de la mima reserva
de talentos, existe el riesgo que un recurso clave no está dispo-
nible cuando se le necesite.
Interdependientes
Las tareas de uno o más de los proyectos están relacionadas como prede-
cesoras de tareas de otros proyectos, tal como se muestra en la Figura
7-3. Si ésta es su realidad, está trabajando en una situación realmente
complicada. Prevalecen las siguientes condiciones:
Figura 7-3. Proyectos interdependientes.
¡::,,
r
,, ,,,ii1iii| ,,,,,,,',,,,',,,,,,,,,,,,,
Las tareas entre los proyectos están relacionadas. En la Figura
--------D D.i.,iii.iii.
7-3,puedeverse que A'2 y 8L están relacionadas Podría ser una
: :':;:':':':
relación física, una dependencia de recursos, un punto de revi-
sión cosas. Quizás A2 es una tarea de colar cimien-
tos de-muchas
concreto para una cancha de básquetbol y la tarea BL es
es la superficie, el proyecto B es la construccióny M y 81 son
tareas relacionadas. Si A2 se retrasa, 81 no podrá emPezar a
tiempo y así sucesivamente.
o Los proyectos pueden compartir la misma fuente de recursos,
tal como se describió en el segundo escenario.
 126 Curtis R. Cook

Esta situación es compleja y difícil de manejar, y por lo general
requiere un enfoque más sofisticado, incluyendo un software capaz de
monitorear estas relaciones.
conceptualmente, la mejor manera de considerar este escenario
es Ia que se muestra en la FiguraT-4. Aplicando este enfoque, el gerente
del proyecto siempre está al tanto de las interrelaciones éntre lós pro-
yectos y las tareas. Las reuniones del equipo se dan en otro tono, pues
los responsables de tareas y los gerentes de los proyectos discuten los
avances a diferentes niveles. Se incrementa la sensación de concienti-
zación y el éxito es más probable.
Paso 1.. Liste todos sus ptoyectos. El primer paso consiste en identi-
ficar su carga de trabajo actual. Si todavía no lo ha hecho, complete una
hoja de trabajo de tareas para cada proyecto, pero manténgalo a alto ni-
vel en este momento. ----en la mayor parte de los cinco siguientes pa-
sos, tendrá que seguir avanzando el proyecto. Si ya ha completado las
hojas de trabajo, eso es muy bueno.
A continuación, transfiera el nombre de cada proyecto a una nota
adherible y la fase o etapa en la que está actualmente el proyecto (ini-
cio, planeación, control o cierre). Adhiera las notas a un muro donde no
se desprendan ni sean retiradas hasta que usted decida hacerlo. Use
unapizarra en su oficina o incluso una mesa separada importante
es que despliegue físicamente las notas enfrente de -lo
usted. Incluya la
información que se muestra en la Figura 7-5.
| ,;tlt.

Pfétéóro;
Mi papéf; Prloridad: '

tl iiilhioiu i i ii:.;.'.......ii:.'....

n., npneaeio"n
tI Contio!::i.¡,:¡,¡,,,

Ú,:,,ó iáir; :':'.:',.,.,.:.:'::]

Figura 7-5. Nota adherible.

Figura 7.4. Proyecto maestro.
¿Cómo podemos tratar todos nuestros proyectos y tareas de la
misma manera sin invertir en softwares o sistemas costosos? Resulta
que la respuesta es más fácil de lo que se imagina.
Ginco pasos para manejar
la sobrecarga de proyectos
La ayuda está en camino. Los cinco siguientes y fáciles pasos lo ayu-
darán a manejar la sobrecarga de tareas yuxtapuestas. Cubriremos
cada paso con suficiente detalle para que pueda aplicar este modelo de
manera inmediata.
No tiene mucho objeto registrar más de sus cinco o seis principa-
les proyectos. Operaremos bajo el Principio de Pareto conoci-
-también
do como la regla 80-20. Este principio enuncia que el20"/" de nuestros
proyectos toman el 80% de nuestro tiempo, causan el 80% de nues-
tros dolores de cabeza, etc. Al concentrarse en el 20% de sus proyectos
para controlarlos, logrará un 80% de mejoras en los resultados globa-
les (y mucha tranquilidady paz mental en su vida).
Paso 2. Identifique el siguiente paso para cada proyecto. Si ha usado
la hoja de trabajo de tareas para crear la EDT tendrá frente a usted to-
das las tarcas de cada uno de los procesos que acaba de identificar.
Carla t.rrt',r rr'prt'st'nta un paso hacia la finaliz.ación del proyecto. Si no
r28 Curtis R. Cook Manejo de proyectos múltiples... 129

ha usado la hoja de trabajo de tareas, prepárelas ahora, tal como ya se
discutió. Mantenga el nivel de detalle relativamente alto, pues estaremos
analizando un horizonte de tiempo bastante corto en nuestros esfuer-
zos de planeación. En este punto, quizás experimente una sensación
interesante sobre su manera de ver la carga de trabajo.
En las ciencias de la decisión se habla del fenómeno mr"ty conoci-
do de que la estructuración de un problema constituye la mitad de su
resolución. Cuando se trabaja con sobrecarga de proyectos, es posible
beneficiarse de este mismo efecto. El sólo hecho de considerar los si-
guientes pasos reduce la sobrecarga a un tamaño manejable. Algunas
veces, el trabajo que todavía no hemos comenzado se convierte en
nuestra imaginación en una labor de enorme magnitud. Al sacarlo a la
luz vemos su tamaño real y los verdaderos desafíos.
Un segundo punto en la identificación del siguiente paso en cada
uno de sus proyectos principales consiste en determinar con exactitud
qué se necesita hacer a continuación. Anote en una nota adherible un
par de los siguientes pasos de cada proyecto que haya identificado, tal
como lo ilustra la Figura 7-6. Es una buena idea escribir cada uno de
estos "siguientes pasos" en una nota separada, para que las pueda mover
posteriormente.
Paso 3. Encuentre los "éxitos rápidos". Usando los siguientes linea-
mientos, identifique cuáles de los pasos identificados podrían resultar
en las ganancias más inmediatas. Use el enfoque de Pareto: Entre las ta-
reas que ha identificado, vea cuál es el20% que de realizarse,le daría un
empuje sustancial inmediato a sus esfuerzos para controlar la sobrecarga.
1. ¿Se logrará que avance el proyecto con una pequeña inversión
de tiempo?
2. ¿Está el proyecto cerca del cierre?
3. ¿Está detenido porque necesita una decisión o debido a la falta
de claridad?
Si la respuesta a cualquiera de estas preguntas o a todas es afirma-
tiva, colóquelas al principio de su lista. Literalmente, tome las notas
auto adheribles y comience a construir una lista de los pasos a tomar.
Al hacer esto, estará cruzando fronteras de productos y en un sentido
muy real, administrando la totalidad de la carga de trabajo del proyec-
to como un portafolio de tareas interconectadas.
Paso 4. ferarquice los pasos restantes. Lo primero que debe pregun-
tarse es si después de lograr los éxitos rápidos de la mezcla (sabemos

3. Estos son una ilusión 1. Ataque éstos

primero muy
-no importantes
pero urgentes.Se
-
importantes y
1 comen su t¡empo urgentes

HI

4. Lo que hacemos 2. Estos son los

cuando nos siguientes todavía
sentimos abrumados
-
¡mportantes pero no
muy urgentes

Baja<lmportancia>Alta

Figura 7-6. Nota adherible. Figura 7-7. Malriz

130 Curtis R. Cook Manejo de proyectos múltiples... 131

que podemos tener mucha mejora atacando éstos inmediatamente) hay El paso final consiste en desplegar su carga de trabajo, ya s('a cn
algunos pasos remanentes que podemos eliminar o mantener en sus- una gráfica o en su computadora, usando una herramienta corrro t'l
penso que no son tan importantes como creímos al princi- outlook de Microsoft. Personalmente uso la función de lista de t¿rrcas
pio. Por-aquellos
el lado opuesto, ¿edsten algunos que sean realmente urgentes de Outlook en mis proyectos y la actualizo continuamente cuando st'
e importantes y tengan que hacerse ahora mismo? Usaremos una ma- añaden o se eliminan tareas. He visto a otros usar una pizarray un plu-
triz para aclararlo. món. Otros más prefieren un documento Word o una hoja de cálculo
La Figura 7-7 representa una matriz de urgencia en una de las es- Excel. Realmente no importa, siempre y cuando pueda "probarle" a
calas y la importancia en la otra. Su siguiente paso es tomar todos los cualquiera que entre en su oficina con otro proyecto urgente, que usted
siguientes pasos y jerarquizarlos por medio de la matriz que se mues- está saturado. Si le es posible mostrar su lista acfual de tareas y pasos es-
tra en laEigura7-7. pecíficos, podrá discutir lo que habrá que sacar de la lista si se añade
Abóquese primero a las tareas del cuadrante 1 pasos más otro proyecto nivel discusión completamente diferente que las
-los que está
importantes y urgentes. Incorpórelos a la lista de prioridades -un que adeveces
frases emocionales nos vemos obligados a decir cuando
desarrollando. Después, idenüfique los pasos importantes del cuadran- estamos sobrecargados y se nos enfrenta a más trabajo. LaFiguraT-9
te 2 que no sean tan urgentes. Si ignoramos éstos, muy pronto pasarán muestra una tabla que despliega la carga de trabajo de una persona.
a ser críticos. Tercero, analice los pasos del cuadrante 3 que podemos
clasificar como urgentes pero no importantes. Se trata de tareas que
no nos preocupan tanto porque no tenemos tiempo para el trabajo im-
portante- parecen demasiado grandes para atacarlas en vista de las
pequeñas ventanas de üempo que tenemos disponibles. La belleza de
estas tareas es que generalmente podemos ignorarlas, pues no son im-
portantes. Finalmente, entre a los pasos del cuadrante 4 importan-
-no
te y no urgentes. Cuando nos sentimos realmente abrumados, jugamos
solitario en nuestra PC de bolsillo o contestamos correos electróni-
cos que a nadie interesan, o quizás navegamos por la Red Mundial. Si
usted gasta algo de su tiempo en el cuadrante 4, realmente necesita
estudiar administración del tiempo.
Cuando haya terminado con este proceso de jerarquización, de-
berá contar con un desplegado de todos los pasos, tal como se muestra
en la Figura 7-8.
Paso 5. Programe su tiempo semanalmente y logre desplegar su carga
de habajo. Ahora que ya tiene jerarquizados todos los pasos en una sola
lista o conjunto de notas adheribles, es el momento de ponerse a traba-
jar. ¡Pero espere! Una paso más antes de que proceda a la acción. Esto
funciona para su lista actual de proyectos y siguientes pasos, pero ¿que
ocurrirá la semana entrante? ¿Y qué sucederá cuando su jefe le ponga
en el escritorio otro proyecto? ¿Podrá funcionar este modelo? La res-
puesta es afirmativa, pero debe ser capaz de demostrar cuál es su carga
de trabajo para poder sostener una discusión racional.
Figura 7-8. Pizarra de proyectos y siguientes pasosatriz.
r32 Curtis R. Cook

Nótese en la FiguraT-9 que se ha agregado al calendario un tiem- Diario de trabajo (o calendario Outlook)
po de reposición el jueves. Es tan importante incluir un colchón en su
programa personal como lo es hacerlo en su programa del proyecto. Scott Cook
De lo contrario, no tendrá tiempo para recuperarse de los problemas Semana del 16/11
inesperados que erosionará su plan. Proyecto Logros planeados Real
una cosa más: Asegúrese de incluir en el calendario los trabajos Folleto 1. Obtener oportunidades de entre-
no relacionados con el proyecto, pues si usted es como la mayoría de namiento
nosotros, tendrá obligaciones que son una mezcla de proyectos y otros Folleto 2. Redactar/conjuntar descripciones
Calendario 3. Finalizar calendario de entrena-
trabajos. Como se discutió antes, quizás deba considerar una lista con- miento
solidada de todos los proyectos y otros trabajos que requieran de su Metas 4. Reunión con ventas
tiempo, tal como se muestra en la FiguraT-'1.0. Esta perspectiva de alto Plan diario
nivel es de gran ayuda en la discusiones de negociación a medida que Lunes Martes Miércoles Jueves Viernes
se le presente más trabajo en su ya sobrecargado programa.
La siguiente lista resume los cinco pasos fáciles para manejar la Reunión con #4
Cita con
Reunión #2 proveedores Revisión
sobrecarga de proyectos y malabarear proyectos múltiples: Médico
del calen-
sobre Planeación
1. Liste todos sus proyectos. problemas #3 con el
dario de
44 Tiempo de
personal entrena-
2. Identifique el siguiente paso de cada proyecto. reposición
miento
3. Encuentre los "éxitos rápidos".
4. Jerarquice los pasos restantes.
5. Programe su tiempo semanal para poder desplegar su carga de
trabajo. Figura 7-9. Calendario de actividades.

Como las demás técnicas de este libro, estos pasos verdadera-

mente funcionan. En la primera ocasión en que su jefe le hable de una
Sémána 1 $emana 2 Sémana 3
nueva y gran "oportunidad" y pueda sostener una discusión racional
basada en la demostración de su carga de trabajo, sentirá que quizás PréyectoA 16 hr ,10hr..
,-
'
:

está logrando controlar su vida laboral. Provecto B 8hr :¿ h; 14hr

Una rápida historia más y terminamos. Recientemente, mi jefe me 20hr 20 hr
Proyecto C
llamó para presentarme un escenario de buenas noticias/malas noti- :...
cias. Las malas noticias eran que uno de los presidentes de división
Supérvisión
::)
¡ l0hr
'' 10 hr 10 hr,

había renunciado inesperadamente y como resultado, se descubrió que Reportes ,','3hr :

,5 hr 3hr
muchos de los proyectos de su grupo tenían defectos; algunos estaban Y¿f¡65 ', 5 h'1, 5 hi' ,!i
, :: ,$ f¡¡:: :

atrasados, otros habían sobrepasado el presupuesto y otros más no es- rórÁr-, 42hr , 52h¡ 52 hr
taban logrando sus objetivos técnicos. Se me pidió ayudar y aplicar el (Dejé cúe lai cifras séan las que digan no én vez dé usted)
contenido de este libro a dichos proyectos, conducir entrenamientos y
colaborar con la división para poder controlar todos esos proyectos.
Otras malas noticias eran que ya tenía una considerable carga de tra-
bajo y no tenía tiempo para esta tarea adicional. Figura 7-'t0. Resumen
134 Curtis R. Cook

Las buenas noticias e¡an las siguientes: Como siempre lo hago, es-
taba usando las técnicas de este libro con base diaria. pór ende, ó.r rre,
de necesitar hacer exclamaciones de que no me era posible absorber
más trabajo, abrí mi lista de tareas (que mantengo rigurosamente ac-
tualizada en outlook) y d jefe y yo tuvimos un aiatógo constructivo
sobre qué proyectos podrían asignársele a otros, cuáiós podían sus-
penderse por el momento y cuáles ya no tenían una alti prioridad.
Excelente discusión sin sentimentalismos y se realizó el tratajo nece-
sario en la división hermana.
una vez más, para cerrar, lo invito a poner en acción estos pasos
Glosario
simples. obtendrá mejores resultados y podrá controlar sus proyéctos.

T-
F
L ste glosario contiene una gran variedad de los términos usados
en la administración de proyectos, muchos de los cuales no aParecen en
Los 4 pasos indispensables para administrar proyectos. Los lectores que se
involucren en proyectos más complejos en los que se use la jerga co-
mún en este campo, encontrarán todas las definiciones necesarias.
Acción correctiva. La acción necesaria para corregir una variación con
respecto al plan del proyecto.
Actividad. Un elemento del trabajo realizado durante el desarrollo de
un proyecto. Normalmente, una actividad tiene expectativas de dura-
cióñ, costo y requerimientos de recursos. En este libro, los términos
actiaidad y tarea se usan indistintamente.
Administración del tiempo. El conocimiento necesario para garanti-
zar la finalización del proyecto ---<onsistente en definición de tareas,
secuencias, estimación de sus duraciones, desarrollo del programa y
control del mismo.
Administración de proyectos. Definida informalmente como "hacer el
trabajo a tiempo, en presupuesto, de acuerdo a las especificaciones".
Una definición más formal es "la aplicación de conocimientos, habili-
dades, herramientas y técnicas a las actividades del proyecto, para qrre
satisfagan o excedan las necesidades y expectativas de los interesados
en el proyecto".
Administración de riesgos. El arte y ciencia de identificar, analizat y
responder a los factores de riesgo durante la vida de un proyecto.
136 Glosario
Alcance. El contenido y productos del trabajo resultante de un proyecto
o del componente de un proyecto. El alcance menciona todas las acti-
vidades desarrolladas, los recursos consumidos y los productos fina-
les que resultan, incluyendo los estándares de calidad.
Cambio. Una alteración de cualquiera de las características del pro-
yecto.
Cambio en el proyecto. Una modificación aprobada de un elemento
del trabajo del proyecto.
Ciclo de vida del proyecto. Un conjunto de fases por las cuales trans-
curre el proyecto. Nótese que el número de fases y su división en tareas
dependen de la metodología usada. El ciclo de vida de la administra-
ción justamente suficiente de proyectos consiste de inicio del proyecto,
planeación del proyecto, control del proyecto y cierre del proyecto.
Cierre del proyecto. Un proceso que da lugar a la aceptación del pro-
yecto por parte del patrocinador, el reciclaje de las lecciones aprendi-
das en el proyecto y las recompensas y reconocimientos por los logros
alcanzados.
Colchón. También llamado flotador. La cantidad de tiempo que una
tarea puede retrasarse desde su inicio sin afectar a la fecha de termi-
nación del proyecto.
Compresión. Acción usada para disminuir la duración de una acti-
vidad de la ruta crítica, por medio del aumento de aplicación de re-
cursos.
Contrato. Un acuerdo obligatorio y firmado entre dos o más partes que
establece los requerimientos de los productos y servicios que deberán
proporcionarse.
Descripción de actividad. un nombre que identifica claramente una
actividad cpn un elemento de la EDT.
Diagrama de red. Un despliegue esquemático de la relación secuen-
cial y lógica de las tareas de la EDT.
Duración. La cantidad de tiempo consumido en una tarea o en el pro-
yecto, ya sea planeado o real. La duración puede expresarse con o sin
la inclusión del tiempo dedicado a no trabajar en el proyecto.
Glosario I r;'
Duración del proyecto. El tiempo transcurrido desde la fecha clt' irri
cio del proyecto hasta la fecha de finalización.
Entregable. Un producto o servicio tangible que satisfaga uno o nr¿is
de los objetivos del proyecto.
Estimación. Evaluación de todos los elementos de costo de un proyec-
to, tal como se define en el alcance.
Estimación actualizada. El pronóstico de fechas de inicio y terminación,
horas de trabajo y costo, que se hace en cualquier momento después
de haber sobrepasado la fecha de la línea base.
Estimación ascendente. El proceso de obtener un estimado en el que el
total es la suma de los estimados de todas las tareas de la ¡or.
Estimado de finalización. El valor (expresado en dólares y/u horas)
obtenido como evaluación realista del costo una vez terminado. Toma
en cuenta los costos reales más los costos proyectados y constituye una
expresión del esfuerzo total del proyecto.
Estrategia. tln marco de referencia que sirve como guía para las op-
ciones que determinan la naturaleza y dirección necesarias para alcan-
zar un objetivo.
Estructura de división del trabaio (¡or). Descripción de las acüvidades,
jerarquizada y orientada a las tareas, que organiza, define y despliega
el trabajo total que deberá hacerse para alcanzar los objetivos de un
proyecto. Cada nivel descendente representa una definición más deta-
llada del objetivo del proyecto. La EDT incluye todos los trabajos del
proyecto y es una herramienta para subdividirlo en elementos de tra-
bajo manejables que puedan asignarse a personas o entidades organi-
zacionales que deberán rendir cuentas de su desempeño, tal como se
detalla en el plan del proyecto.
Estudios de factibilidad. Los métodos y técnicas usados en el análisis
de los datos técnicos y de costos para determinar el potencial econó-
mico y la valía práctica de un proyecto.
Evento de riesgo.I-Jn suceso pueda afectar negativamente al proyecto.
Expediente del proyecto. Thmbién llamado archiao del proyecto. La
localización física de toda la documentación específica del proyecto,
incluyendo el protocolo, el plan, los reportes de avances y el contrato
cuando existe. Puede ser total o parcialmente electrónico.
138 Glosario
Factores críticos para el éxito. Los factores necesarios para garantrzat
el éxito del diseño, desarrollo e implantación de un proyecto. Se basan
en el punto de vista del cliente del proyecto.
Fecha real de finalización. La fecha de calendario en la que realmente
se terminó el trabajo de una actividad. Debe ser igual o posterior a la
fecha de inicio.
Fecha real de inicio. La fecha de calendario en la cual se inició real-
mente una actividad. Debe ser anterior o igual a la fecha de inicio pro-
gramada.
Flotador. Véase colchón.
Formación del equipo. El proceso de influir en un grupo de individuos
diversos, cada uno con sus metas personales, necesidades y perspecti-
vas, para trabajar juntos y lograr un objetivo programado.
Gerente de proyecto. La persona designada para ser responsable del
éxito global del proyecto.
Gerente funcional. Un gerente responsable de las actividades en un
área o departamento especializado.
Gráficas de Gantt. Representación gráfica del programa de un proyec-
to que muestra cada trabajo como una barra cuya longitud es propor-
cional a su duración. Las barras aparecen en filas e indican los tiempos
de inicio y finalización de las tareas, así como las yuxtaposiciones con
otfas tareas.
Impacto. La pérdida o efecto sobre el proyecto cuando se materializa
un riesgo.
Inicio del proyecto. El proceso de empezar formalmente un proyec-
to. Este proceso consiste en verificar que se han identificado todos los
interesados, que toda la información necesaria para comenzar el pro-
yecto está documentada en el protocolo, que se ha designado un ge-
rente del proyecto, a quien se le ha otorgado toda la autoridad para
desarrollarlo y que el protocolo ha sido aceptado por el patrocinador.
Interesados. Individuos o entidades organizacionales involucrados en
las actividades del proyecto o que pueden ser afectados por dicho pro-
yecto.
Lecciones aprendidas. Información documentada generalmente re-
cogida en las reuniones, discusiones o reportes escritos, para capturar
Glosario r39
las percepciones de éxitos y errores del proyecto, así como los proccsos
que funcionaron bien o lo que necesitan atención.
Línea base. Un plan del proyecto con aprobación gerencial fijado en
un punto específico del tiempo en su ciclo de vida, usado como medi-
da del progreso del proyecto. Un conjunto de datos usados para com-
paraciones o control.
Manejo de conflictos. El proceso que el gerente del proyecto usa para
lidiar con las inevitables diferencias que se presentan en el seño del
equipo del proyecto.
Miembro del equipo. Cualquier individuo que reporte a tiempo com-
pleto o parcial al gerente del proyecto, responsable de algún aspecto
de las actividades del proyecto.
Objetivos del proyecto. Descripción de los resultados específicos que
el proyecto intenta generar. Los objetivos de un proyecto deben ser
específicos, medibles, acordados, realistas y con restricciones de tiem-
po. (EMARR)
Organización de matriz. Un formato para organizar el proyecto en el
que se "prestan" recursos al proyecto de forma temporal. El gerente
del proyecto y el gerente funcional comparten la autoridad sobre los
recursos humanos. El equilibrio de poder en una matriz depende de
que sea fuerte o débil. En una matriz fuerte, el gerente del proyecto
ejerce más control, mientras que en una matriz débil, el poder recae en
el gerente funcional.
Organización funcional. Cualquier grupo externo al control del ge-
rente del proyecto, responsable de tareas en la estructura de división
del trabajo.
Patrocinador del proyecto. Gerente individual para el que se va a de-
sarrollar el proyecto. Esta persona es responsable del compromiso de
los recursos requeridos para realizarlo, presupuestar los fondos y ejer
cer la autoridad de la decisión final del proyecto.
Plan del proyecto. Documento formal y aprobado usado para admi-
nistrar y controlar las tareas y actividades del proyecto.
Planeación de contingencias. Proceso de identificación y planeación
de las respuestas apropiadas que deberán adoptarse cuando un ries-
go ocurra en la realidad.
t40 Glosario
Planeación de recursos. Determinación de los recursos (humanos, equi-
po, materiales) necesarios y en qué cantidades , para ejecutar las tareas
del proyecto.
Planeación del proyecto. Identificación de los objetivos, tareas, pro-
grama/ recursos/ costos, riesgos, comunicaciones y otros elementos ne-
cesarios para completar un proyecto.
p¡¿nox@ Guiile.Iniciales en inglés del cuerpo de conocimientos de la
administración de proyectos. Es un término inclusivo que describe
la suma de conocimientos en la profesión de administración de pro-
yectos, tal como la describe el Project Management Institute (PMD.
Presupuestación. Parte de la función de planeación y mecanismo de
control de un proyecto.
Presupuesto. Estimación de los fondos planeados para sufragar el pro-
yecto o un lapso de tiempo específico en el futuro.
Presupuesto del proyecto. La cantidad y distribución de dinero asig-
nado a un proyecto para su desarrollo en un tiempo dado.
Probabilidad. Las posibilidades de que se presente un evento de riesgo.
Proceso. El conjunto de actividades desarrolladas para un propósito
específico.
Proceso de administración de cambios. Conjunto de tareas o procedi-
mientos establecidos para garantizar que los cambios son revisados,
aprobados o rechazados con una actualización de la línea base.
Producto. Término general usado para definir el resultado final de un
proyecto entregado a un cliente.
Programa. Grupo de proyectos interrelacionados manejados como una
entidad de forma coordinada. Aunque los programas también tienen
fechas de inicio definidas, pueden durar años o indefinidamente.
Programa del proyecto. Representación gráfica de la predicción de ta-
reas, referentes, dependencias, requerimientos de recursos/ duración
de las tareas y fechas límite.
Programa detallado. Programa usado para comunicar las tareas dia-
rias a los miembros del equipo del proyecto que trabajan en el mismo.
Glosario t,1l
Programación. Llamada también calendarización. Reconoci nr it'r r o n'.r t
lista de las restricciones de tiempo y recursos que de algurra r)r,ur('r'.1
influirán en la ejecución del plan.
Protocolo del proyecto. Llamado también estatuto del proytclr¡. lrs r'l
formato entregable del proceso de inicio. Documento que dcst'ril'r' rlc
manera concisa el proyecto, anuncia la designación de su gercntt', Irro
porciona la autoridad organizacional para aplicar recursos al proyt'. trt
y otorga la autoridad para proceder con la planeación.
Proyecto. Cualquier trabajo con un inicio y final definidos con olyr'lit,u;
específicos y bien definidos que, cuando se alcanzan, identifican l¿r f irr,r
lización.
Referente. IJn suceso o una tarea con duración cero que no requiert'
recursos, usada para medir el avance de un proyecto y representar la
finalización o inicio de un esfuerzo para generar un entregable.
Reporte de avance. Reporte que compara el avance real con la línea
base actualizada y aprobada.
Reporte de estado. Reporte generado a intervalos periódicos para pro-
porcionar información del proyecto.
Reserva gerencial. Cantidad de tiempo o fondos apartados para con-
tingencias.
Resolución de conflictos. El proceso de búsqueda de la solución de un
problema.
Restricciones. Factores que limitarán las opciones del equipo de ad-
ministración del proyecto ejemplo, un presupuesto predefinido,
-por
fechas límite, alternativas tecnológicas o acciones legislativas.
Retroalimentación. Información extraída de un proceso o una situa-
ción, usada para controlar, planear o modificar de inmediato las en-
tradas del proyecto.
Riesgo. Un evento o condición que, de ocurrir, podría tener un efecto
adverso sobre los objetivos planeados. (Nota, el p¡vtsox Guide menciona
que el impacto puede ser positivo o negativo.)
Ruta crítica. Una rrrta de secuencias de actividadcs en un programa de
red, tltrt'rt'¡rrt'st'nt.r lir clurircitin nrás larga clc tttr proyt'c'to. Ctralquicr
't42 Glosario
falla en una de las tareas de la ruta crítica aumenta la duración del
proyecto, a menos que se apliquen acciones correctivas.
Solicitud de cambio. Una petición formal por escrito para hacer una
modificación a algún elemento del plan del proyecto o a las especifi-
caciones.
Suposición. Algo que se percibe como correcto en el momento de
expresarlo.
Tarea. Véase Actiaidad.
Técnica de revisión y evaluación de programas (prnr). Técnica de
programación de proyectos orientada a las tareas, usada para esti-
mar la duración total del proyecto cuando existen incertidumbres en A valor subyacente de
los estimados de las actividades individuales. El p¡nr usa duraciones
Acciones correctivas
calculadas con base en los promedios ponderados de los estimados
definición,135
optimista, pesimista y más probable. Con el uso del PERT, la fecha de
finalización del proyecto puede fijarse en términos probabilísticas y para problemas de ProYectos,
los intervalos de confianza pueden definirse de acuerdo a las desvia- 91-94
ciones estándar de las tareas de la ruta crítica. para variaciones, 87, 89-90
Aceptación
Variación. La diferencia entre los resultados planeados y los reales, de riesgos, TT
expresado con la fórmula V : P - R. Una variación puede ser positi-
del proyecto, 108-109
va o negativa. Aceptación enfoque de (manejo
de riesgos), 99-1-00
Actividad, definición de, 135
(Véase también Tareas)
Administración de ProYectos
de proyectos múltiPles (Véase
Administración de ProYectos
múltiples)
como Proceso, 18-19
definiciones de, 20, L35
ejemplos de exceso de,24-27
múltiples como Proceso, 4-5
pasos en Ia,17-19
software parala,59-61
valor añadido por La,26
valrrr dc la,20-24
lndice analítico
La,13-L4
Administración del tiemPo, 135
(V éase también Programación )
Administración/manejo de
riesgos, 23,76-78
definición,135
en la fase de control, 97-98
formato para,97-98
Agenda de trabajo, 13L-133
Alcance,20,22
cambios/reducciones
del,92-93
definición,135
deslizamiento del,22,
83,95-96
Aprecio, 11.8-119
Aprobación del ProYecto, 108-109
Archivo del proyecto, 35-36,
L37
Arranque del proyecto, 29, 3I-35
Arranque, reunión de, 51., 53-56
Asignación de recursos, 47,59-62
Aspectos
definición, 97-98
maneio de los,97-98
 1,44 Indice analítico
Índice analítico 145

que afectan a la programacióry Cierre del proyecto,1,36 (Véase

62-63 durante la fase de control, Diálogo con el cliente, 103
tnmbién Fase de cierre)
Autoridad,21,34 95-97 Disminución del alcance, 92-93
Clientes
Avances,/estado del proyecto planeación de los, 47 -48 Duración
decisiones de compra de los,
comunicación de los,90 1,27_123
técnicas avanzadas para ef definición,136
¡euniones sobre los, 90-91 81-84 del proyecto, 136
comunicación con los, 89,90
Avances, reportes de, 87, Bg,'J.4'1. Convergencia de rutas, 73-7 4
necesidades y expectativas de E
Correos electrónicos, LL5
B Ios,22,1,09
Costos EDT,55, 57-59,63
Código de cargos, 108
Beneficios, costos de los, 12I-IZ2 cálculo de,75 EDT gráfica,55,57-58
Colaborativo, enfoque (manejo
de beneficios para Ejecución del trabajo, 1.7, L8
c de conflictos), 100
Colchón,definición de, 136
empleados, L22 EMARR, objetivos, 4L-42, 139
de variaciones,g2-94 Entradas,29
Cabos sueltos, 109-110 (Véase también Flotador)
estimados al finalizar, 137 Entrega, 19, 108-11,0
Calendario Competitivo, enfoque (manejo de
Credenciales,l2;J.4 Entregable(s)
de sobrecarga de trabajo, conflictos), 99-100
definición,136
131-133 Compresión del programa, D del paso de planeación, 49
software para crear ef definición,136
Decisiones por consenso, 100-102 en el protocolo del
63,65-66 Comunicación
Decisiones, toma de, proyecto,42
Cambios con el cliente, 87,89-90
por consenso, 100-102 protocolo del proyecto
definición, 135 cuando se aplica presión como,29
en el alcance del trabajo, 93 por los clientes, 121-1,23
sobre el programa, 70-27 Equipo de proyecto, 23
en proyectos, 136 reglas de protocolo del
de avances técnicos,89 actividades del, en la fase de
Cambios en el proyecto, definición, equipo para la, 101
de logros, 90-97,117 control,8T
735 (Véase también Control y estructuración de
del estado del proyecto, administración del, en la fase
de cambios) problemas, 127-128
80, 90-91 de control, 98-L02
Camisetas,38,40 Descripción de actividades, 136
memorando de avances del comunicación y tamaño
"Campeón" (V éase patrocinador Descripción de la EDI 55,57-59
proyecto,8L del,80-81
del proyecto) Desempeño,22,23
planes de,47 comunicaciones en el, 78-83
Carga de trabajo, despliegue de medidas clave del, 91-92
retroalimentación, L4L confianza y respeto eneL,87,89
la, 131-133 PERT (Véase Técnica de
sobrecarga de,121, desarrollo del plan del
Cartas de agradecimiento, 11.8-119 revisión y evaluación del
técnicas avanzadas de proyecto por parte del, 99
Celebración, 79, I17 -1Ig programa) en la administración de
planeación de la, Z8-g3
Certificación, programas de, 12-1,3 técnico, administración riesgos,/aspectos, 98
Confianza, Sg
Ciclo de vida del proyecto, 136 del,87,89-90 falta de cierre y baja moral
Contingenc ias (V éase planeación
definición,136 Desempeño técnico, del,107
de contingencias)
Cierre, 19,22-23 administrac ión del, 7 3-7 4 formación de la identidad
Contrato, definición de,'1.36
necesidad del,177-178 Deslizamicrrto dt'l ir lcancc, del,38, 40,I38
Control de cambios,22
sensación de,707 9,66,8022, U3, 95-9(r formación del equipo central,
como actitud mental,82
I)t'sviacitin t'stiirrtl.rr; 711, 7,1 50-51
 746
lecciones aprendidas
enviadas por correo
electrónico al, 115-116
papeles / responsabilidades
del,36,38
protocolo del, 101-102
reuniones del,90-9L
Equipos, identidad de los,38,40
Estatuto del equipo, 101
Estimación ascendente, 1.37
Estimación presupuesta ria, 75
Estimaciones rinicas, 70-77, 73-7 4
Estimados actuales,
definición, 137
Estimados/estimación
actuales, 1.37
ascendentes , 75, 737
de programactón,70-73
definición. 136
descendente s,74-75
en la finalizaci6n,737
niveles de precisión
en los,74-75
presupuesta rios, 7 4-7 5
Estrategia, definición, 137
Estructura de la división del
trabajo (EDT), 47,737
cantidad de detalles enla, ST
creación de La, 55, 57-59
definición, 55,737
descripción de la, 55, 57-59
ejecución dela,77
gráf.ica, 57, 58-59
Etiqueta (en el protocolo del
equipo), 101
Evaluación de riesgos, 47
Evaluación del proyecto, 109
Evento de riesgo, definición, 132
Indice analítico
Evitar riesgos en el manejo de
conflictos, 76, 77,'],,00
Excelencia, recompensas por, 102
Exitos rápidos,729
Expediente del proyecto, 35, 137
F manejo de las relaciones con
Factibilidad, definición de
estudios de,737
Factores críticos para el éxito,
1,37
Fase de cierre, 19
captura de las lecciones
aprendidas, 11.0, 11,2-71.s
celebración/recompensas,
1,02-104
entrega del proyecto, 108-110
importancia de la, 105
lista de verificación para la, 111
modelo parala,108-119
pasos en la, 106
reciclaje de información útil,
775-777
reciclaje en la, 110, 172-717
transición ala,104
Fase de control, 78-19,87-704
actividades del gerente del
proyecto, 87-90,95-96
actividades involucradas en
La,87-88
administración de costos,/
programa/recursos
en la, 91-95
administración de riesgos,
97,98
administración del desempeño
técnico, 87,89-90
administración del equipo
del proyecto, gS-702
Índice analítico
aspectos gerenciales, 97-98
comunicación de logros/
estado del proyecto, 90-97
control de cambios durante
La,94-97
manejo de conflictos, 99-I0Z
el cliente en la, 102-104
pasos de La,87-88
recomPensas y
reconocimientos, 102
reuniones del equipo durante
Ia,90-97
transición a la, 85
Fase de inicio, 78,29-45
creación del protocolo del
proyecto enla,37-45
establecimiento del expediente/
archivo en la, 35
gerente del proyecto
en la,32-33,34-35
identificación de jugadores
clave en La,29,37-32
interesados en el proyecto en
la,32-35
pasos de Ia,30
patrocinador del proyecto en
la,31-34
preguntas a contestar durante
Ia.35-36
y arranque del proyecto,
29,37-35
y definición de un proyecto,
29,37
Fase de planeación, 18,47-63
aclaración de papeles/
responsabilidades en, 51-63
actividatlt's dcl gerente del
t,t7
proyecto en Ia,51-63
asignación de recursos en
La,59-62
creación del programa del
proyecto en la, 60, 62-63
estructura de división del
trabaio, 55,57-59
formación del equipo central,
50-51
pasos de Ia,52
proceso dela,48-49
reunión de arranque en la,
53-56
revisión de los requerimientos
del proyecto en Ia,51
técnicas avanzadas para la,
65-85
tiempo dedicado a la, 44-45
transición aLa,44-45
y software de administración
de proyectos,5T-67
Fecha de terminación del
proyecto,42
Fecha real de finalización,1,37
Fecha real de inicio, 138
Fechas de terminación, 42, 62-63
de tareas, 63-69
del proyecto,42
diagramas de red para
monitorear las,67-69
estimaciones de,70-72
fechas reales,737
gráficas de Gantt para
monitorear las,66-68
red lógica para monitorear
las,67-69
software de calendarizaciórr
para monitorear las, 65-(r(r
1,48 Índice analítico
Fiesta de cierre, 118-119
Flotación, 67 (Véase también
CoIchón)
G
Ganar-perder, manejo de los
conflictos,99
Gantt, gráficas de,65-68, 138
Gerente de proyecto
actividades del, en la fase de
control, 87-90,95-96
actividades del, en la fase de
inicio, 32-33,34-35
actividades del, en la fase de
planeación, 5L-63
autoridad del, 27, 34-35
características de un buen, 33
como único punto de
contacto,20-22
confianza y repecto del
equipo,87,89
defirición, 138
en el protocolo del
proyecto, 40
optimismo natural del, 7 7-73
plan de reunión de arranque
del,53-54
rendición de cuentas del,
20-22
responsabilidades de relaciones
con el cliente del, 102
responsabilidades del, 21, 34-35
reuniones planeadas/
dirigidas por el, 90-91,
transmisión de las lecciones
aprendida por parte
del, 115-116
y formación del equipo
central, 50
Gerente funcional, definición, 138
Great Projects (James Tobin),
12-t4
Guide to the Project Management
Body of Knowledge
(PMBOK Guide), t2-14
H 32-33,34-35
Habilidades de la gente,50
Hoja de trabajo, despliegue
de la, 132-133
Hoja de trabajo de tareas del
proyecto,5T-60
actualización de la, 93-95
fechas de terminación en
La,63
para proyectos múltiples,
1.27-128
I 1t2-115
Identidad de los equipos,33
Impacto, 76,77-78,138
Información reutilizable, reciclaje
de,115-tI7
Inicio del proyecto, definición,
138, (Véase también Fase de
inicio)
Interconexión (de proyectos
múltiples), 123-127
Interdependencia de proyectos/
tareas,725-127
Interesados en el proyecto
definición,138
en el protocolo del
proyecto,40
en la fase de inicio, 33-36
Índice analítico 14()
responsabiüdades de comunicación de, 90, 177 -778
los,40-41 reconocimiento de, 102
Lrtranet, 1L5
M
T Manejo de conflictos, 98-\02,'1.39
jerarquización, matriz de, 129-131. Manejo de las relaciones con el
Jugadores clave cliente, L02-704
gerente del proyecto, establecimiento de las
relaciones, 1-02-103
identificación de los, 29, y aprobación, L02-104
37-32 Matriz débil, 139
impacto del retraso por, Matriz de jerarquización,
123-124 L29-I3I
interesados en el proyecto, Matriz fuerte, 139
31.-32 Mejoras, '1,05,1,07
patrocinador del proyecto, Mejor valor,12L-122
3L-33 Memorandos del estado del
proyecto, 80-8L, 90
L Microsoft Word, Excel, P owerP oint,
Lecciones aprendidas, 108, 110, Out\ook,74,59,131.
Miembros del equipo
definición,138 (Véase también Equipo del
enfoque formal para capturar proyecto)
las, LL0, I12,175-776 definición,139
enfoque informal para transferencia de las lecciones
capturar las,Il0,1\2 aprendidas por los, 115-116
lista de verificación para las, Mitigación de riesgos, 77 -78
112-11.5 Moral, 23,107
sitio intranet para las, 114-116 Motivación,107
Lewis, James P.,50,99
Lider azgo, habilidades de, 50-51
N
Likert, escala de, 109 Necesidades de estima, 107
Línea base, 48, L38 Negociación, 100
Lista de tareas, 48,127-131. (Véase Negociador, enfoque (manejo rlt'
también Estructura de conflictos), 100-102
división del) Ni hablar de hojas de cálculo
Logros (Tom Peteres),17-12
 150
Nombre del proyecto,38
Notas adheribles
diagramas de red con,67-68
EDT con, 55,57-59
para listados de proyectos
múltiples, 127
para "siguientes pasos" con
proyectos múltiples,
127-128,729-731
o aprobación deI,83,85
OAP (Oficina de administración
de proyectos), 115
Objetivos,22-23
de negocios, 41
del proyecto, 47-42, 739
EMARR, 47-42,739
Objetivos de negocios, 41
Objetivos del proyecto, 47-42, 739
Oficina de administración de
proyectos (OAP), 115
Operaciones/ apoyo/
mantenimiento, transición
a la fase de,179-120
Optimismo (en la programación),
77-73
Organización de la matriz, 139
Organización funcional,
definición, 139
P para ri'esgos,75-79
PAP (Profesional de
la administración
de proyecto s),12-73
Pareto, enfoque de,129
Participante s (V éase Jugadores
clave)
Patrocinador del proyecto
Índice analítico
definición,139
en el protocolo del
proyecto,3T-40
en la fase de inicio, 32-33
firma del, del protocolo,43
presión del,70
responsabilidades del, 43
Peters, Tom, 11-12
Plan del proyecto
definición del, 139
desarrollo del,48
elementos en el, 47
planes subordinados del,
48-49
revisiones del,97-92
Planeación de contingencias
de presupue stación, 7 5-7 6
definición, 139
reserya gerencial, 141
Planeación de recursos, definición,
739
Planeación de riesgos, 76-79
Planeación del proyecto, 139
(Véase también Fase de
planeación)
Planes
de comunicación, 78-8L, 83
para contingencias, 75-76, 1,39
P MBO K Guíde, 1.3-14, 1,40
PMI (Project Management
Institute), 12-13
Precedencia, diagramas de,
65,67
Presión
para comprimir el programa,
68.70-77
por sobreca r ga, 727-734
Presiones del mercado, 70
Presiones p olíticas, 70-7 7
Presupuestación ascend ente, 66-75
Presupuesto del proyecto,
42-43,47,740
Presupuesto descendente, 74
Presupuesto detallado, 65-66
Presupuesto/ presupuestación
ascendente, 66
definiciones, 140
de proyecto s, 42, 47, I40
descendente, 74
detallado,66
técnicas avanzadas de, 74-75
Probabilida d conjunta, 7 3-7
Probabilidad,73-74
definición, 140
de riesgos, 76,77-78
Proceso de administración de
cambios, 140
Proceso, definición, 140
Procesos burocráticos, 11
Producto, definición, 140
Profesional de la administración de
proyectos (PAP), 12
Programa, definición, 125
Programa del proyecto, 47
(Véase también Programación)
creación del,47-48
definición del,727
Programa detallado, 123
Programa semanal, 115-119
Programación
(Véase también Programa del
proyecto)
dcfiniciórr, 140
clt'l ticrl ¡ro st'rtriru;rl, 131-134
Índice analítico t5l
optimismo enla,77-73
presiones políticas sobre
la,70-77
reservas/reguladores en
La,74-75
técnicas avanzadas de, 68-7,1
y convergencia de rutas,
73-74
y estadística,73-74
Programas académicos, 6
Project Leadership (James Lewis),
50,99
Project Managentent Body of
Knowledge (PMBOK Guide),
740
4 Project Management I¡rstitute
(PMI),72-74,20
Promedio ponderado, 72
Protocolo
del equipo, 101-102
del proyecto,29,37-45
Protocolo del proyecto, 29, 37 -45
código de cargos en el, 108
como entrada principal dc
la planeación,48
definición, 140
distribución del,44
documentación de suposicior r.,s
en eI,43
elementos principales
del37-39
entregables en eI,42
fecha de terminaciítrr
en el, 42
gerente del proyecto
en eI,40
interesados en el, 40
nombre del proyecto, 3,8
 Írrtl i.'t',r tt,r I t t itro i'; r
1.52 Índice analítico

Respeto, 38-89 Soltwi¡rc

objetivos de negocios en de lecciones aprendidas,
Responsabilidad, 21, 34-35 1'ara administraciólr tltr
eL,41. 11,0,712-11.5
Responsabilidades gerenciales proyectos, 59-61.
objetivos en el, 41.-42 Recompens as, 102, 7L6-179 del gerente del proyecto, parir diagramas de red, trtl, frJ
patrocinador en el, 40 Reconfiguración de proyectos, 21.-22 Solit ittrd de cambio,83
presupuesto del proyecto en 92-93 Restricción triple, 19-20, 60 tlt'firrición, 141
el,42-43 Reconocimiento, 707, Restricciones, 19-20 lrrrmato patala,M
relaciones estratégicas en el, 118-119 como desafíos de Sr r¡rosiciones, 43, 63
43-44 Reconocimientos, 102 desempeño,23
responsabilidades de los Recursos definición,141 T
interesados en el, 40-41 disponibilid ad de, 92-93 en la disponibilidad de 'I.r
n.,rs
responsabilidades / firma del fuente común de, 125 recursos,60-61
tlt.¡rcndencias entre las,
patrocinador en el, 43-44 reasignación de,92-93 estimaciones descendentes .t8,60,62-63
Proyectos como,74-75
uso de los,9L rf t: pcndiente s, 123-125
definición de, 29, 31. 1.41. Resultados, 22,23
Red, diagramas de, 67-69,1,36 It'ch¿rs de terminación de,63
dependientes, 124-725 Resumen del proyecto, 47
Redes lógicas,65-67 llotirdor para, 67
éxito de los, 13 Retroalimentación, definición,
Referentes, definición, 141 i rr tc rconexió n de, 123-127
interconexión de los, 723-127 r47
Reguladores, T4-75 i rdependientes, 125-126
rr tc
interdependientes, 125-726 Reuniones del equipo
Relaciones estratégicas, 43 nrorritoreo de la terminación
lista de, 726-127 durante la fase de control,
Rendición de cuentas, 20-22 de ,65-69
reconfigura ci6n de, 92-93 90-9',1.
Reporte semanal de estado, rcfcrcntes para, L35, 141
separados, 123 reglas de protocolo para
87,82-83 las, 101-102 scparadas, 123-124
Proyectos múltiples, administración
Reportes Riesgo, definición de, 76, 97, 747 l'ócnica de revisión y evaluación
de, \2'J.-124
de avances,/progreso/ Roddick, Andy, 38 del programa (PERT),
enfoque de proyecto maestro
89,1.41, Ruta crítica,67 65-67,70-73
enla, 126
de estado del proyecto, 81, definición,141 definición,140
interconexión en los, 123-727
82-83,90,147 origen,48 desviación estándar en la, 73
manejo de la sobrecarga en,
Reportes de estado,90 estimacione s en la, 71-73
726-734
definición, 141
S Tecnologías avanzadas de
y sobrecarga, T2l-1M
semanales,81, 82-83 Salidas,29 planeación, 65-85
Proyectos / tareas dependientes,
Requerimientos del proyecto, Sobrecarga, 721-1,34 aprobación del plan del
60, 62-63,123-726
revisión de los, 51 causas de La,1.21.-122 proyecto, 83,85
Proyectos / tareas separados,
e interconexión de los para la calendariza ción, 68-75
123-724 Requerimientos, revisión de los,
proyectos, 123-127 para monitorear la
del proyecto, 51
R Reserva gerencial, 141 ganancias inmediatas contra terminación de tareas,
La,729-737 65-69
Reciclaje, 19 Reservas, 74-75,'J.41.
pasos para copar con la, planeación de la
de la información reutilizable, Resolución de conflictos,
726-131 comunicación,78-82
71.5-177 700,701,147
L54 Indice analítico

planeación de riesgos, 7 6-79 Variación de la programación,

presupuesta cíón, 7 4-7 5 91.-92
proceso de control de Variaciones
cambios,83-84 acciones correctivas
Tobin, ]ames, 12-13 de las, 89-90
Trabajo desafiante, 29 administración de
(trabajo) las,9'J.-95
costo de las,97-92
V definición,142
Variable de evento (riesgo), programa,9T-92
76,77-78 Variaciones de costos, 91

GERENCTA Y DESANNOIIO E.'ECUTIVO

INTERÉs GENENAT

TEMAS MUNCANOS

:?TD,OJS[g"EDJT9$I*I.SJ:9,$AMA
,Il9-3t\ ss46-2699, ss92-2019 y ss35-9348 ext. I I ó
venf os@Ponoromoed' com' mx
',V/..é
 +/¡á*-r'7
Otros tltulos afines publlcados
por Panorama Edltorial
. Cómo destruir una empresa en
12 meses... o antes
. Cómo planear y dirigir un
negocio de tecnologfa exitoso
. lmplementación
¡ Los secretos gerenciales de
Disney
. Planeación e implementación
de la ventaja competitiva de su
empresa
. Visión viable

Si desea recibir información

gratuita sobre cualquiera
de estas obras,
favor de comunicarse a:

nE* cRUPo EDtToRtAL

',I98 PANoRAMA
Dlrecclón Comerclal
ventas @ panonmaed. com. m x
rmpreso en: Tels.:55-46-17-13 o 55-35-92-02 ext. 107
Programas Educalivos, S.A. de C.V. Fax: 55-35-92-02
Calz. Chabacano No.65 Local A Gerencla de Mercadotecnla
Col. Astur¡as 06850 - Máxico, D.F.
m e rc adotecn ¡ a @ pano ramaed. c o m. m x
Febrero 2006
Emprósa Certificada por el Tels.: 55-35-45-97 o gg-46-26-99 ext. 1 1 6
Inst¡tuto Mexicano de Normalización www.panonmaed.com.mx
y Cerlil¡cación A.C., bajo la Norma tienda panoramaed.com. mx
@
ISO-9002: 1 994/NMX-CC-004: 1995
con el Núm. de Registro RSC-048,
y bajo la Norma ISO-14001: 1996/5AA-1998,
con el Núm. de Reg¡stro RSAA-003