f' l7

o
- Curtis R. Cook
=
(n a

P
o
o i l, )

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

o
F
vr/
, r ot I r t it'ntltl rcstr I ttdos cspectaculares terminados
-proyectos
,
'rr rrr,is rirriclcz y c()11 un costo ms razonable que antes. El pro-

'lr,rrr,r ('s (lLrc cl pnrceso de administracin usado para proyectos

ir',ur(l('s t's demasiado complicado y burocrtico para los pro-
i::i)'
, t't tos tluc casi todos nosotros manejamos y suele ser ms 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 inlorrnacin y herramientas actuales ms efectivas para la ad-
rrirristracin de proyectos en un proceso especialmente disea-
lo P'1 rnanejar proyectos pequeos o medianos. Este valioso
)r,uu.rrl le ahorrar tiempo y le proporcionar:
posos
Un proceso verstil 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 mnimo de desperdicio
de esfuerzos.
indispensobles
Consejos, tcnicas e historias reales surgidas de la ad-
ministracin contempornea de proyectos.
l,l olrjt.tivo fundamental de la administracin de proyectos es
pctrq
I'rotltrcir los resultados deseados, a tiempo y en presupuesto.
I 'r'r'rn ita que esta obra le muestre cmo centrarse en este objetivo

v rnarrcjar los proyectos que transformarn 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
irrrcrilciu 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-
lrcrn de proyectos, gente y procesos.
indispensables para
Sus antecedentes laborales incluyen la
responsabilidad por utilidades en varias
administrar proyectos
empresas de consultora y capacita-
cin, as como organizaciones del go-
[-lierno federal. Es conocido por su
capacidad tcnica y su experiencia en
consultora, mentora, coaching, entre-
namiento, planeacin estratgica y de-
sarrollo organizacional. El Dr. Cook ha
presentado seminarios en 35 pases a
rniles de ejecutivos, gerentes y miem-
bros de equipos en virtualmente todos
los sectores empresariales, incluyendo
tecnologa de la informacin, arquitec-
tura/ingeniera, gobierno, aeroespacial/
defensa, productos farmacuticos, bio-
tecnolog a, construccin, petrleo/ener-
ga, desarrollo de productos y servicios
generales. En total, el Dr. Cook tiene
ms de 30 aos de experiencia en la
administracin de organizaciones de
los sectores pblico 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
administracin de proyectos (PAP)y un
profesional certificado en la administra-
cin de contratos (PCAC).

Pon re Supnuclri or Srn Huuluo y sus l{snrucroNs

 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 aos me ha apoyado y crey e1m cuando
AI )MINISTRAR PROYEC IO$
ie, " sabes? voy a escribir un libro sobre ad'ministracin
lftulo original en Inglt: 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 espaol por:

Antonio Eroles G.

Primera edlcin en sDaol: 2006

@ Panorama Edltorial, S.A. de C.V.
Manuel Ma. Contreras 45-B
Col. San Rafael 06470 - Mxico. 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 Mxico
lsBN 968-38-1491-3

Prohibida la reproduccin parcial

o lotal por cualquier medio sin autorizacin
por escrito del editor.
 lndice
Prlogo .----.9
Introduccin ..'...11
Es para usted Los 4 pasos indispensables para administrar
Reconocimientos proyectos? ......'.13
Formatosylistasdeverificacin.. ......;l'4
I
Quiero expresar mi agradecimiento a mi t'clitor, Lisa O'Connor, por su Panorama cle la admlnlstracln de proyectos . . . . . .t5
entusiasta apoyo a este proyecto. Como gt'rerrte de proyecto de un li- Da de accin de gracias en Beech Mountain . . . .15
bro sobre administracin de proyectos, rlur)ca dcj de expresarme que Administracin justamente suficiente de proyectos . . . . . . . . . .16
el matcriar era interesante y til para ella, rroporcionndome un gran La administracin de proyectos como Proceso . . . . . . . . .18
alierto como autor. Algunos fundamentos antes de seguir . . . .1'9
Craig Sawin, presidente de Novatiorrs Group, me motiv a es- El valor de la administracin de proyectos . . . . . . . . . . . -20
cribir este libro desde el momento en que lc present un modelo de la Ejemplos de demasiada administracin de proyectos . . . - . . . . .24
prrrtada. Le agradezco a l y a muchos de los amigos y colegas de Todos los proyectos necesitan ser administrados-pero
Novrtions Group su entusiasta apoyo. slo 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 disposicin a usar Esestounproyecto?... .........29
tuna administracin 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
Qunecesitasaberantesdeproceder? ...'.....35
ElProtocolodelproyecto.. .....'.38
Transicinalafasedeplaneacin.. ... '..45
3
planeacln
Fundamentos de la .. .. . ..47
Elprocesodeplaneacin.. .......48
Cunto tiempo debe dedicrsele a la planeacin? . . . . .49
Formandoelequipocentral .......50
Actividadesdeplaneacin. ... ' '..51
Planpara monitorear la finalizacin de tareas ....... .'63
 ndice

4
Tcnlcs avanzadas de planeacln . . . .65
Maneras de desplegar el programa del rroyecto
ymonitorearlafinalizacindetareas ........65
Programacin"avanzada" . .......68
Presupuestacindeproyectos... ........74
Planeacinderiesgos ......76
Planeacin de la comunicacin
Proceso de control de cambios
. . . .78
. . . .83 Prlogo
Aprobacindelplandelproyecto .......83
Transicinala fasedecontrol .....85
5
Controldelproyecto... .......87 I-
....
Actividadesdecontrol .......87 L- n Los 4 pasos indispensables para administrar proyectos, Curtis Cook
Administracindeldesempeotcnico .........87 ha traducido con xito un gran de conocimientos destinados a
cmulo
Comunicacin de logros yestado del proyecto . . . . . . . .90 proyectos grandes y complejos, a un lenguaje que todos los involucra-
Reunirse o no reunirse-sa es la cuestin . . . . . . . . . . . .90 dos en este tipo de actividades podrn entender y aplicar a su trabajo
Administracin de variaciones de costos. diario en proyectos. Aunque es consistente con A Guide to the Project
programacinyrecursos.. .....91, Management Body of Knowledge (prtnox Guide), el estndar del Ameri-
Controldecambios ........95 can National Standards Institute para la administracin de proyectos,
Administracin de riesgosyasuntos .....97 el libro reduce muchos procesos a cuatro pasos prcticos fciles de
Administracin del equipo delproyecto ... ....98 entender.
Manejo de las relaciones con el cliente . . .1.02 Los 4 pasos indispensables para administrar proyectos incluye forma-
Transicinalafase decierre .....104 tos y listas de verificacin que pueden ser usados de inmediato. Por
6 consiguiente, es una gua muy til para cualquiera que desarrolle ac-
Cierredelproyecto... ..tO5 tividades de corto plazo con resultados especficos medibles otras
-en
Modelo para cerrar el proyecto . . .108 palabras, proyectos.
Transicina operaciones,apoyoymantenimiento ...,119 Empezando con una excelente introduccin a los proyectos y su
AdministracindeproyectosmItiples ........120 administracin, este libro pasa de inmediato a los aspectos prcticos.
El Captulo 2 sobre el inicio del proyecto, proporciona un formato del
7
protocolo del proyecto claro y conciso, incluyendo instrucciones de c-
Manejo de proyectos mltlples 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 planeacin del proyecto en el Captulo 3, como a
Lainterconexindetodo ........123 conceptos de planeacin ms avanzados en el Captulo 4. El Captulo
Cinco pasos para manejar la sobrecarga de proyectos . . . . . . .126
4 en especial, proporciona excelentes lineamientos de la forma de crear
Glosarlo ....135 programas realistas, cmo vencer las presiones polticas, cmo antici-
ndlceanaltico ...143 par los riesgos y cmo tomar en cuenta las realidades estadsticas Para
l0 Curtis R. Cook

gcnerar un plan del proyecto que realmente tenga xito (algo raro en
rrucstra sociedad).
El Captulo 5 penetra en las realidades del control del proyecto una
vez que se ha aprobado el plan bsico. Aqu, el lector encontrar de-
talles sobre control de cambios, manejo de los desafos de los equipos,
idministracin de la relacin con los clientes y mantener el proyecto en
curso. El Captulo 6 contina el tema prctico del libro proporcionan-
do un proceso simple y fcll de seguir para lograr la aceptacin del
cliente de los entregables, capturando las lecciones aprendidas, cele-
lntroduccin
brando los xitos del equipo y efectuando la transicin a la operacin
del proyecto.
En el Captulo7, el libro cambia de giro al tratamiento del muy
necesario manejo de proyectos mltiples pequeos. 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 mltiples. hoy en da en trabajos de proyectos, pero para casi todos nosotros, el
El libro termina con un excelente glosario de los trminos clave y uso de tcnicas formales de administracin de proyectos de tamao
una bibliografa 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 sera
ha creado una gua prctica y fcll de usar para administrar proyectos. -pero
un exceso. Y sin embargo, cuando se usan en su proporcin correcta,
Puede servir como un excelente manual o fuente de recursos para
los principios y tcnicas de la administracin de proyectos pueden ser
cualquiera involucrado en la administracin de proyectos, en especial
invaluables incluso en proyectos pequeos- 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 dcada, la administracin 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 Emrito siderarse como en exceso burocrtica y complicada, aadiendo poco
University of Pittsburgh valor. En la edicin de enero de 2004 de PM Network, "Ni hablar de
hojas de clculo" [Pg.20], Tom Peters dice,
Con el advenimiento de la tecnologa de la informacin, Ios
gerentes de proyectos se han enfocado demasiado en grficas 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 aos apoyan las
conclusiones de Peters. He visto crecer la administracin de proyecto
 12 Introduccin
descle una aplicacin especfica del sentido comn hasta el uso exce-
sivo de procesos complejos. Muchas organizaciones han adoptado la
arlrninistracin 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 tcnicas inherentes. Y sin embargo, las estadsticas citadas
por las principales organizaciones de investigacin 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 empaquetndolos para reportarlos a
la gerencia, sin ocupar el tiempo suficiente en realmente resolver proble-
mas y aadir valor. Es necesario tener en cuenta que el valor subyacen-
te de la administracin de proyectos es la eficiencia y efectividad con
la que transforma los objetivos estratgicos en resultados de negocios.
Y no obstante, irnicamente, la profesin y la prctica se han venido
asociando con procesos burocrticos. Digo "irnicamente" porque la
fuerza impulsora de la gnesis de la administracin de proyectos fue el
deseo de eliminar la burocracia y realizar el trabajo.
Qu sucedi? En los primeros tiempos de la administracin 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 Ro 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 slo a los grandes. El Project Management
Institute [PMI] naci en los ochenta. El Comit de Estndares 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 cmulo de herramientas y tcnicas. Se instituyeron programas
de certificacin, siendo la credencial ms importante la designacin de
Profesional de la Administracin de Proyectos (PAP). Se crearon pro-
gramas acadmicos, incluyendo estudios de maestra y doctorado en la
especialidad de administracin de proyectos. La idea era que si una
persona poda obtener el grado de rep o un ttulo avanzado en la ad-
ministracin de proyectos, esa persona sera 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 conclusin es vlida. Pero la mayora de los
Introduccin 13
proyectos no son de gran tamao y los procesos complejos no ayudan
a los gerentes en los proyectos de tamao promedio.
A un amigo mo le gusta decir, "Pata un nio de 4 aos con un
martillo,la totalidad del mundo es un clavo". Armados con la PMBOK
Guide, ms de 100,000 gerentes de proyectos se dedican a administrar-
los usando la "biblia" . Pero los proyectos pequeos no necesitan toda
la informacin, tcnicas 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 informacin que "est alI afiJera" en unas cuantas tcnicas
fciles y rpidas para quienes manejan proyectos de tamao medio y
tienen que hacer malabares con varios proyectos pequeos. No hay du-
da que el enfoque de la administracin de proyectos es muy valioso
cuando se aplica a cualquier proyecto, pero necesitamos aplicar slo lo
suficiente para rcalizar el trabajo sin tantos obstculos.
Es para usted Los 4 pasos indispensables
para adm inistrar proyectos?
Este libro una gua prctica de "como hacerlo" para manejar proyec-
es
tos. Si usted es responsable de la administracin de proyectos dc tama-
o pequeo a mediano, en especial cuando trabaja simultneamerrtc 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 realzar para llevar su proyecto desde el inicio a travs de la pla-
neacin, y hasta la finalizacin con conclusiones efectivas.
Si bien no es mi intencin denigrar a la PMI o a la credencial PAP,
y por supuesto, tampoco a los ttulos de postgrado (yo soy un PAP y
poseo un Ph. D. en un campo muy relacionado con la administracin
de proyectos), la verdad simple es que no se necesitan esas credenciales
para manejar bien la gran mayora de los proyectos. Lo que se necesita
es "suficiente" capacidad de administracin de proyectos para realizar
bien el trabajo. Este es el principal enfoque de este libro.
Esta obra tambin proporciona un buen panorama general de la
administracin 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 Introduccin

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 organizacin tiene un buen pro-
grama de capacitacin para gerentes de proyectos y programas basado
en la PMB)K Guide. Encontrar que las definiciones de trminos del
glosario son similares, y en algunos casos idnticas, a las definiciones
generalmente aceptadas por esta gua.

Formatos y listas de verificacin Panorama de

El libro proporciona en toda su extensin varios formatos y listas de
verificacin para ayudarlo a pensar en los documentos necesarios para
la administracin
administrar proyectos y paracrearlos. Thmbin se incluyen las instrucio-
nes de cmo aplicar los formatos, junto con lineamientos prcticos para
de proyectos
uso en proyectos reales. Estos formatos son documentos Microsoft
Word o Microsoft Excel fciles de crear.

Da de accn de gracias
en Beech Mountain

I f ace ,rt par de aos, nuestra familia decidi que la cena del da de
accin de gracias se hara en nuestra pequea cabaa de 75 metros cua-
drados en las hermosas montaas de North Carolina. Beech Moun-
tain, el pueblo donde ahora vivimos, est habitado por escasamente
27g almas y el clima en noviembre es fro ---<lima de chimenea. Pen-
saron que tener ah a toda la familia con el aroma del pavo asndose y
los sonidos del fuego chisporreteando resultara muy atractivo' Slo
haba un problema: La cocina de nuestra pequea cabaa 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 furamos, pero tambin
mencion que tendramos que cenar fuera o llevar el pavo ya PrePa-
rado, por lo pequeo de la cocina' Recuerdo que dijo "Es imposible
cocinar la cena del da de accin 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 administracin de proyectos T7

el tema (ET). Estuvo de acuerdo. Acabbamos de arrancar nuestro proyecto y el nivel de experiencia tcnica del gerente de proyecto y
proyecto. el equipo, aplicamos justamente la suficiente Para efectuar el trabajo.
Para llevarlo a cabp, sabamos que tendramos un plan para coordi- Recordemos los pasos:
nar todas las actividades, por lo que conect mi computadora porttil,
L. Iniciar: Cul es el reto o el problema?
abr mi software de administracin de proyectos, agarr mis libros de
recetas y con mi esposa (recuerde que ella era mi ET que posea el co-
2. Planear: Cmo deberemos proceder?
nocimiento tcnico) me sent a crear el plan. El primer trabajo de la pla- 3. Controlar: Estamos en el camino correcto?
neacin de proyectos es listar todas las tareas que debern 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
nuacin, anotamos todas las tareas en el orden en que tendramos que general.
realizarlas para poder preparar la cena y servirla a tiempo. Despus
determinamos quin hara cada tarea (usamos a nuestros hijos y nues-
tros padres como "recursos"). Tras esto, analizamos todas las cosas que
podran salir mal y aadimos unos dlares y algo de tiempo al plan. Fi-
nalmente, nos sentamos a revisar el plan y decidimos que estbamos
listos para echarlo a andar. La planeacin haba terminado! Para asegu-
rarnos que todo mundo supiera cul era su parte de todo el asunto, im-
prim la lista de tareas y la programacin (si incluyendo la ruta crtica
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 algn pequeo tropiezo aqu y all para
m, el gerente del proyecto. En algunos momentos nos retrasamos, pero
Figura 1-1. Los cuatro pasos de la administracin 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-
cin y gozamos de una cena perfecta. Sin embargo, hubo una leccin Ntese que el paso de control incluye ejecutar el trabajo y contro-
que aprend de forma difcil. Olvid aadir "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 ejecucin, 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 desempeo e identificar
aprendidas " pata referencia futura. las variaciones con respecto al plan, para aplicar acciones correctivas.
La ejecucin del trabajo no es por s misma una funcin de la adminis-
tracin del proyecto, aun cuando, como sucede a menudo, el gerente
Administracin justamente suficiente de proyectos del proyecto tambin haga algo del trabajo o la mayor parte. En el
Aplicamos demasiada administracin 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 cmo hacer el trabajo tcnico.
IB Curtis R. Cook Panorama de la administracin de Proyectos L9

La administracin de proyectos como proceso el trabajo se haga a tiempo, dentro del presupuesto, consistente
La administracin de un proyecto es un proceso serie de pasos con las especificaciones y requerimientos. Se generan reportes de
-una
realizados para lograr un resultado especfico. Todos los proyectos tie- avance del proyecto para mantener informados a todos los inte-
nen un ciclo de vida bsico consistente de cuando 4 pasos. Depen- resados.
diendo de la industria y del tipo de proyecto, este moelo bsico es 4. Cierre del proyecto. El paso final consiste de tres actividades dis-
suscepble de ser ampliado (algunas empresas farmacuticas tienen tintas:
procesos de 12 pasos), pero no puede comprimirse. El enfoque de jus-
tamente suficiente es simplemente la aplicacin 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 ms de detalle. (El resto del libro cubrir cada uno durante el proyecto sean transmitidas o otros.
de ellos con mayor profundidad.)
. Celebracin. 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
iniciacin 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 planeacin 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 especficos y bien
desarrollar un plan detallado que incluya la lista de taras, el plan
definidos que, al conseguirse, identifican la terminacin. En la prctica,
de riesgos y el proceso de control de cambios. Esto puede parecer
demasiado detallado, pero si se toma un minuto para pnsarlo,
la mayor parte de los proyectos tienen recursos y tiempo limitados
para lograr los objetivos. Este sistema es tan tpico que se le da incluso
ver que no lo es tanto. Incluso para proyectos de su casa, tiene
un nombre restriccin triple- tal como se muestra en la Figura 1-2.
que saber qu pasos deber dar para realizar el trabajo, cunto -la
dinero tiene en su presupuesto, quines van a hacer las tareas y
cunto tiempo tomar el proyecto. Y tambin sabe que algunas
cosas saldrn mal, lo cual requerir un poco ms de dinero y tiem-
po que el que tena planeado. Es lo mismo para proyectos ,,ofi_
ciales" en el trabajo por lo general tienen ms detalle Mes
para reflejar su mayor-aunque
tamao y complejidad. Una vez que el pa-
trocinador del proyecto aprueba el plan, se le llama lnea base-del
proyecto.
3. control del proyecto durante la ejecucin del trabajo. El trabajo
comienza una vez que el plan ha sido aprobado. Durante este
Especificaciones
paso/ se realiza el trabajo tcnico 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 restriccin triple
 20 Curtis R. Cook
Dentro del tringulo se localiza el alcance del proyecto, qre define
las fronteras del mismo en trminos de requerimientos tcnicos o es-
pecificaciones, y los lmites de tiempo y costo. Es interesante observar
que son las restricciones lo que dan lugar al proyecto. Sin lmites de
recursos, dinero o tiempo, habra 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 ms rapidez, con menos costo y mejor. Tenga en cuenta que mien-
tras ms 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 administracin de proyectos para
realizar el trabajo. El Project Management Institute (pMI) define ad-
ministracin de proyectos como "La aplicacin de conocimientos, ha-
bilidades, herramientas y tcnicas a las actividades del proyecto, para
cumplir los requerimientos de dicho proyecto"L La mayora de loi ge-
rentes de proyectos exitosos dan una definicin ms detallada.
La administracin 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 administracin de proyectos
Los gerentes ejecutivos frecuentemente me preguntan porqu alguien
podra desear adoptar la administracin de proyectos. Despus de
todo, dirigir el negocio en la forma usual es ms cmodo. 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 mtodo
que incluye restricciones y requiere un enfoque riguroso de la admi-
nistracin del cambio? La respuesta simple es que el entorno compe-
titivo en el que operan casi todas las empresas requiere un enfoque
ms disciplinado para obtener participacin de mercado o incluso pra
sobrevivir. Y para proyectos que no son de negocios, este enfoque nos
ayuda a proceder de manera ms organizada. Pero hay otras razones
especficas y bien documentadas para usar la administracin de pro-
yectos, que cubriremos antes de seguir adelante.
Razn 1. Establece un solo punto de contacto y rendicin de cuentas
para el xito general del proyecto. La administracin de proyectos
Panorama de la administracin 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 administracin 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 orgarrizacin. Al poner a cargo a una persona, los interesados
especial los clientes- saben a quin acudir con sus preguntas
-en
durante el diseo, la produccin, las pruebas y el despliegue. Veamos
con mayor atencin la autoridad,la rendicin 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 legtima para
obligar a que se cumplan sus rdenes El presidente de una compaa
tiene la misma autoridad. Si la gente no cumple las "rdenes" del lder
formal, podran 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 despus y que se llama protocolo del proyecto. Tenga presente
este documento mientras continuamos.
La rendicin de cuentas significa que el gerente del proyecto debe
responder por la generacin 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 fsico 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 obligacin de actuar sin necesidad de una
gua o autoridad formal. Es casi una obligacin moral hacer lo correc-
to. A eso se debe que los libros gerenciales insistan en que la responsa-
bilidad no puede delegarse; es una obligacin inherente. Un gerente
de proyecto que entienda el objetivo del mismo y est comprometido
a lograrlo se siente responsable del resultado sensacin de pro-
piedad del proyecto.
-una
Al conjuntar estos tres conceptos rendicin de cuen-
-autoridad,
tas y responsabilidad- es fcil ver porqu al gerente de proyectos
puede exigrsele que produzca resultados solamente cuando se le ha
otorgaritr autoridad para realizar el trabajo y tiene una sensacin de
22 Curtis R. Cook
responsabilidad por el resultado. Con ello estamos diciendo que la
tarea de un gerente de proyectos no es nada fcil.
Razn 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 dilogo continuo durante
su desempeo, para garantizar la satisfaccin del cliente. Un cliente per-
cibe la diferencia cuando se adopta un enfoque de administracin de
proyectos, porque su xito como gerente del proyecto se mide en tr-
minos de qu tan bien se maneja la restriccin triple al cliente
-darle de pre-
lo que se acord que le proporcionara, dentro de las restricciones
supuesto y tiempo que gobiernan al proyecto.
Razn 3. Mejora el desempeo con respecto al tiempo, el costo y las
reas tcnicas. 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 "rnort 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 presin sobre los miembros del equipo puede ser intensa
aclara expectativas y produce resultados. -pero
Razn 4. Genera resultados consistentes mediante la definicin y
aplicacin de un proceso en las unidades de negocio. Como lo pue-
den atestiguar muchas personas familiarizadas con el movimiento de
calidad, la aplicacin de un proceso bueno y rgido a un problema
ayuda a eliminar desperdicios e ineficiencia. Cuando dicho proceso in-
cluye las mejoras prcticas y se aplica a toda la unidad de negocios, se
lograrn 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 razn que
lo justifica es cuando el proceso es lento y burocrtico. En tal caso, el
enfoque de este libro ser de gran ayuda.
Razn 5. Se enfoca en administrar el alcance del proyecto y controlar
los cambios. Detallaremos este aspecto ms adelante, pero uno de los
&t'.'ay./.T
proyectos
Panorama de la administracin de 23
principios fundamentales de la administracin de proyectos es que sus
objetivos y alcance se definen desde un principio y no se permiten
cambios sin una autorizacin especfica. Esto prcticamente elimina
el deslizamiento del alcance, que se define como un cambio de alcances
sin restricciones.
Razn 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 opinin con frecuencia, mal clima- lo que sea. En la planea-
cin del proyecto, el equipo discute en tormentas de ideas todos los
posibles impactos negativos para el proyecto y desarrolla respuestas
antes de la ejecucin Como resultado, hay menos sorpresas y desastres
que amenacen a la consecucin de los objetivos.
Razn 7. Refuerza a los equipos de proyectos y mejora la moral de
los miembros. Los desafos significativos de desempeo crean equipos.
Una de las ventajas del entorno restringido en el que opera la mayor
parte de los proyectos es que crea un desafo instantneo de desem-
peo. Como resultado, los equipos de proyectos se aglutinan con ma-
yor rapidez qrte los equipos funcionales. Adems, a los seres humanos
generalmente nos gusta tener un objetivo claro en nuestro trabajo. Por
definicin,los proyectos tienen objetivos especficos y medibles, y todo
mundo sabe cul 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 sensacin de haber finalizado de haber terminado algo que
vali la pena. Todos estos factores--o un trabajo desafiante, objetivos
especficos y terminacin --desembocan en un alta moral para los equi-
pos de proyectos.
Razn 8. Mejora el desempeo de las utilidades y hace ctecer al
negocio. Esta ltima raznes el resultado de las siete anteriores. El ren-
gln de utilidades mejora porque los equipos de proyectos son tanto
ms efectivos realizar el trabajo ---como ms eficientes
-permiten
menos recursos para lograrlo. Por otra parte, una buena
-utilizan
administracin de proyectos resulta en una mayor satisfaccin del
cliente, lo cual conduce a una mayor participacin de mercado e in-
gresos ms altos. La mayor satisfaccin del cliente, acoplada a ope-
raciolrcs nrs eficientes, genera ms utilidades.
24 Curtis R. Cook
Ejemplos de demasiada
adm inistracin de proyectos
Quizs ya est convencido de la necesidad de aplicar la administracin
de proyectos. Pero, qu sucede cuando se exagera y se aplica un exce-
so de administracin de proyectos para el tamao 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 compaa de la industria de
hardware de computadoras. La empresa X fue en un momento dado el
lder en su campo. Debido a algunos sonados fracasos de proyectos, la
gerencia decidi que necesitaban una buena administracin de proyec-
tos. Buena decisin. El primer paso que dieron fue conjuntar un equipo
de todo el mundo para desarrollar una metodologa de administracin de
proyectos. Otra gran idea. Pero con el correr del tiempo, el alcance de la
metodologa de proyectos se expandi con muy poco control de los
cambios. El equipo aadi pasos para manejar casi cualquier situacin
posible. Gente adicional, ms contratistas y especialmente ms dinero,
fueron incorporados al proyecto. Cuando finalmente se obtuvo, el entre-
gable fue un enorme documento de metodologa orientada a proyectos
en tres carpetas muy gruesas, un conjunto de dos panfletos describien-
do cmo proceder en cada uno de los cientos de pasos del proyecto y
un pequeo manual resumiendo todo el proceso.
El equipo de la oficina principal decidi que el proceso sera obli-
gatorio (nuevamente, nade de malo en ello si la metodologa 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 sera obligatorio Debemos aclarar que en el primer libro se presen-
taba una matriz aclarando que el proceso era escalable usarse
slo ciertas partes para proyectos pequeos medianos -podan
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 tambin gast millones de dlares entrenando a sus
gerentes de proyectos, pero el entrenamiento fue genrico y no adap-
tado a la nueva metodologa. Pero, tras unas cuantas sesiones, el di-
nero para el esfuerzo dej de fluir. Despus de todo, todo lo necesario
para administrar y completar proyectos ya estaba incluido en algu-
na parte de los libros.
Panorama de la administracin de proyectos 25
Para los proyectos ms grandes y complejos de la compaa, la
metodologa y eI entrenamiento rindieron buenos frutos. Se us un
software adecuado y la gente seleccionada para rcalizar estos grandes
esfuerzos saba cmo hacerlos y qu partes de la tecnologa tena que
usar y cules ignorar. Pero, para el otro 80% de los gerentes asignados
a proyectos pequeos y medianos, la metodologa 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-
cumentacin era preciosa.
-pero
Ms o menos un ao despus de la aplicacin de la metodologa,
la empresa realiz un auditoria global para determinar el porcentaje de
equipos que la estaban usando. Resultado? Menos del10%! La mayo-
ra de los gerentes de proyectos haban utilizado enfoques disea-
dos en casa y / o procesos locales o regionales que ya existan 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 aos siguientes,la mayor parte de los que haban
estado involucrados en la iniciativa haban sido despedidos o se ha-
ban ido voluntariamente a pasturas ms verdes. La empresa, ahora
disminuida, todava no tena un proceso general para Proyectos peque-
os y medianos tamao de la mayor parte de los proyectos de una
-el
organizacin tpica.
Nuestro segundo ejemplo se refiere a una compaa mucho ms
pequea .com del sur de California. Como todos sabemos, hubo
-una para la desaparicin de estas pequeas empresas de
muchas razones
Internet, pero una de ellas fue en buena parte la aplicacin de demasia-
do proceso a proyectos de tamao 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 pblico. Durante las preparaciones, sur-
gieron algunos aspectos. Se dieron cuenta que no podan darse el lujo
de desarrollar "juguetes" y dejar que los clientes jugaran con ellos, pa-
ra despus decidir si deban desarrollar sistemas de produccin de las
aplicaciones ms promisorias La gerencia sinti la necesidad de una ma-
yor consistencia en su enfoque y ms xitos comerciales. Necesitaban ser
capaces dc prede-cir bien sus utilidades para impresionar a los analistas
26 Curtis R. Cook Panorama de la administracin de proyectos 27

del mercado de valores que evaluaran 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
tracin 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), P9. 205.
una mala idea...
La primera seal de problemas surgi cuando se decret que
todos los proyectos seran administrados usando un paquete de soft-
ware comercial. No se proporcion entrenamiento sobre esta herra-
mienta y no se haba desarrollado un proceso bsico aplicable a toda la
compaa para manejar la administracin de proyectos. Sin embargo,
la oficina de proyectos fij nuevos lineamientos. Todo proyecto reque-
ra un protocolo mltiple, un plan detallado que tpicamente cubra L5
pginas y reportes, diagramas y grficas de gran complejidad, la mayor
parte de lo cual se produca con un paquete grfico y no con un soft-
ware de administracin de proyectos. Los gerentes de proyectos se pa-
saban todo el tiempo empujando papeles. Muy pronto se volvieron
administradores de proyectos, no lderes, y perdieron el respeto de la
gente que haca el trabajo. No pas mucho tiempo para que la "admi-
nistracin de proyectos" fuera vista como un proceso burocrtico que
no aada valor y fue suspendida. La empresa regres a sus mtodos
particulares para manejar sus proyectos. Quebr en2002. Algunos de
sus competidores que haban adoptado los procesos, formatos y proce-
dimientos de suficiente administracin de proyectos para controlarlos,
sobrevivieron y prosperan. Debo saberlo mis clientes.
Por consiguiente, la administracin-sonde proyectos aade valor
slo cuando se aplica en dosis apropiadas. Es mucho ms inte-
-pero
ligente aplicar un poco, medir los resultados y donde sea necesario,
aadir enfoques ms sofisticados, que ahogar a su mejor personal en
montaas de papeles.

Todos los proyectos necestan

ser administrados-pero slo lo
suficiente para reaLzar el trabajo
De acuerdo, usted est convencido de que la administracin de proyec-
tos es buena para usted. Ahora ya es tiempo de profundizar en el pro-
ceso de administracin justamente suficiente de proyectos y aprender
todas esas tcnicas rpidas y fciles 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 informacin nece-
sari pra empezar el proyecto y resume dicha informacin en el pro-
tocolo del proyecto ---el-nico entregable de esta fase' Piense en cada
uno de lo cuatro Pasos del proceso de la administracin del proyecto
como eventos con entradas y salidas. La entrada pfincipal necesaria
para arrancar un proyecto es algn tipo de documento de requerimien-
ios. Esto puede asumir una o ms de varias formas:
. Especificacionesescritas
o Contrato con el cliente
. Orden de trabajo
Solicitud de servicio
. Directiva Por correo electrnico
. 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 administracin del mismo'
Destacndose 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 definicindeproyecfo y fin

-inicio
definidos, objetivo especfico, etc. Ampliando esto un poco se genera
una lista de verificacin 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 especfico y medible?
o Es una clase especial de esfuerzo que requiere una solucin
particular?
. Se necesita una respuesta rpida?
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 administracin de proyectos le ser til. Si no
es as, estar realizando un trabajo connuo, gobernado por las polti-
cas y procedimientos normales de su organizacin.

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 quines son los participantes clave y en comprender sus papeles
y responsabilidades. Hgase las siguientes preguntas:
o Realizar yo todo el trabajo o habr otros que contribuyan?
o Quines formarn el equipo?
o Quines usarn el producto final?
r Quin especificar los requerimientos?
Desarrollar r Quin aprobar el producto final?
pfoceso oe
control o Quin paga las cuentas?
de cambos
o Qu tan disponibles estn los otros involucrados?
. Tengo autoridad para pedir ayuda?
IJna manera simple de empezar es trazar un crculo con usted co-
mo gerente de proyectos en el centro y otros participantes en crculos
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 mnimo 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"ierria, 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
competencis asociadas con el *ito en el entorno de un proyecto.
aparecen en los
todas concuerdan que las que se listan a continuacin
individuos de alto desemPeo:
Caractersticas de los grandes gerentes de proyecto
. Compromiso con el proyecto y el equipo
Habilidades de comunicacin
. 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 dems
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- dems 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 Proporcionaaprobacin final de to.Lacapacidaddeliderazgoincluyecualidadespersonales
iroy"cto. patrocinador eierce la autoridad de tales como empata, integridad y honestidad'
coor-
ios usurrtos involucrados en el proyecto y se asegura que exista
Adems de contar con casi todas estas caracterstica, los gerentes
dinacin y comunicacin 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. Tpicamente 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.oyuto encontrar al "campen" del mismo' A menos que el Interesados en el ProYecto
proyecto fallar slo
nador est identificado y su utr campen, el - Una vez nombrado, enire ls primeras cosas que debe hacer el
gerente
proyectos deb,en
ser cuestin de tiempo. Por esta razn, 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 tendrn un
hacer valer su posicin
Esto pued pu."", extrao, pero recuerde que expectatiia, y r trea del gerente del proyecto-determinar cules son
con el xito'
es una caracterstica de los grentes 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-
cin estn involucrados en el proyecto, la mejor manera de proceder es
comunicarse directamente con el individuo en cuestin. Es una buena
idea desarrollar una lista de verificacin 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 ningn interesado.

Establezca el expedente o
carpeta del proyecto
A nadie le gusta el papeleo es una parte inevitable
-pero con proyectos pequeos,deellagerente
nistracin 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-
tacin importante generada en cada paso del proyecto. puede ser desde
una simple carpeta hasta un sistema de documentacin en lnea.
En la Thbla 2-2 se muestra una lista de comprobacin de los do-
cumentos que debe contener el expediente del proyecto.

Qu necesta 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. Quin lo necesita? Quin es el cliente?
3. Por qu lo estamos haciendo? Cul 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, quin lo es?
5. Cul es mi autoridad para que esto suceda? Si no tengo la
autoridad, quin la tiene? Por qu no la tengo yo? Cmo
Tabla 2-1 . Responsabilidades y autoridad del gerente del proyecto puedo corregir esta deficiencia?

36 Curtis R. Cook
a Protocolo del proyecto
a Documentacin la reunin 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. Permtanme compartir un ejemplo
de un proyecto que casi fracas debido en gran parte a que su gerente
simplemente careca de autoridad para llevar a cabo el trabajo.
El proyecto consista en renovar una pista de aterrizaje que se ha-
ba deteriorado debido a su antigedad, el clima y un uso intensivo.
lJna nueva generacin de aviones iba a usar la pista, por lo que tena
que ser repavimentada para manejar el trfico. 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 ms adecuado' Nunca se prepar
un protocolo del proyecto y no me asegur de mi autoridad- cre que
todo mundo saba que yo estaba " a cargo" , Era mucho ms joven en
aquel entonces!
Not que, al convocar una reunin de estado de avance del pro-
yecto, algunos de los participantes clave de nuestra divisin de ingenie-
ra no asistieron y me cost mucho trabajo que el gerente de proyectos del
contratista me prestara atencin. 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 medioda, con una temperatura superior a los 38" C (el
proyecto era en Phoenix, Arizona). Esto no slo iba en contra de las me-
jores prcticas de la industria, sino que adems constitua una violacin
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 tendra que destruir todo el trabajo que
haba hecho y volver a colar el concreto en la noche, cuando la tempe-
ratura fuera ms baja, tal como lo haba 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 reunin sin que se hiciera comentario alguno y confront a nuestro in-
geniero cuando regresamos a la oficina. Result ser que el ingeniero
haba aprobado que se colara el concreto durante el da, siempre y
cuando su contenido de humedad se mantuviera suficientemente alto
para evitar cuarteadoras. Nuestro ingeniero haba 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 tcnicas. Cuando acud al
"jefe" para aclarar mi autoridad, averig que quien realmente estaba
" a cargo" de la parte tcnica del trabajo era el ingeniero. El nico pro-
blema era que ni yo ni el resto del equipo lo sabamos.
Naturalmente, estaba molesto, pero lo ms importantes es que
el proyecto casi fracas. El contrato tena una clusula de daos por el
incumplimiento de la fecha de terminacin o de las especificaciones
tcnicas, 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 hubiramos
aprobado el procedimiento no estndar y la pista se hubiera termina-
do adecuadamente, con lo que nos habramos ahorrado el montn de
dinero gastado en honorarios de abogados.
La leccin 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 tcnicas. En retrospectiva, la leccin 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 preparacin 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 propsito del proyecto y su relacin 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 objevo y el alcance general, e incluye mu-
Objetivos de negocios
chos de los detalles necesarios para que el patrocinador tome la decisin
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 continuacin 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 terminacin
sus elementos para determinar si carece de alguna informacin. Esto
quizs explicar algunos de los problemas que est teniendo con cier- Suposiciones
tos proyectos.
Relacin con los objetivos estratgicos 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, hgalo y divirtase.
Cuando rena al equipo por primera vez, piensen en algn nombre Estamos de acuerdo en que es un proyecto viable. Autorizamos que se inicie el
atractivo. Considere tambin acuar alguna frase o lema que expre- proceso de planeacin.
se el objetiro del proyecto. He visto lemas tales como "Los liquida-
dores bebidas para liquidar su sed". Otro simptico lema
-Servimos
que vi impreso en una camiseta para un equipo de exploracin subma-
rina deca: "Sumrjase profundo, viva a poca profundidad". Esto le da
una idea de cmo hacerlo divirtindose. 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 fenmeno tenstico norteamericano, acababa
de terminar un juego triunfal en el tomeo del All-England Tennis Club de
2004. Lo estaban entrevistando para la televisin y traa puesta una
camiseta de la Copa Davis. Antes de esto, Roddick no haba decidido
si participara en la Copa Davis o los Juegos Olmpicos, y sin embargo,
apareca 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 slo una camiseta, pero cuando me la puse
me di cuenta que era parte del equipo que representara a nuestro pas.
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
cafy otros artculos 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 slo 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 capitn del equipo enlistara a Andy Roddick, es probable
que tambin 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 informacin crucial que muchas veces se menosprecia.
Un interesado se define como un individuo o una organizacin invo-
lucrados en el proyecto o que sern afectados por el mismo. Puede
imaginarse no hablar con un interesado clave durante el inicio o la
planeacin de un proyecto? No tendra 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 sentirn 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 convnza-
los antes de arrancarlo. Es una buena inversin 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, divisin de
-por
compras; ejecutar contrato con tres analistas para apoyar el diseo del
sistema". Un enunciado simple sobre la contribucin del interesado es
suficiente por ahora para sostener las conversaciones con ellos. Esto le
permitir saber si le falta algo.
Objetivos de negocios
Cul es la fuerza impulsora del proyecto? Cul es la necesidad del ne-
gocio? Escriba esto en este bloque. Si no comprende la relacin entre es-
te proyecto y los objetivos de negocios, avergelo antes de continuar.
Objetivos del proyecto
Por definicin, todo proyecto tiene un objetivo. Pero, para que sea va-
lioso en guiar al equipo y la subsecuente evaluacin del proyecto, con-
viene que el objetivo cumpla las reglas del acrnimo EMARR:
Especfico. Cul 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 ms nfa-
sis en definir, durante la preparacin del caso de negocios, la mtrica
que se usar para evaluar si el proyecto fue un xito o un fracaso. Son
estos parmetros de desempeo que deben cumplir los resultados,
funciones que el producto o el sistema deben exhibir, incluyendo los
niveles de satisfaccin 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
rn para proporcionar recursos u otro tipo de ayuda. La mejor manera
con
de garantizar la comprensin es comunicarse con ellos
-renase
que ano-
cada interesado y discuta los elementos del protocolo. Pdales
ten sus iniciales o su firma, o bien que confirmen por correo electrnico
que estn 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 tendrn que vivir durante todo el proyecto.
Restriccin 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 especficos que generar el equipo del
proyecto, incluyendo los siguientes:
o LJna descripcin del hardware o los productos tangibles que se
usarn o crearn en la solucin'
o I-Ina descripcin del software que se usar o se crear.
o dibilidad disminuir y su dilogo con el patrocinador ser... digamos
Identificacin de cualesquiera servicios que deben ProPor-
cionarse como parte de la solucin, tales como entrenamiento,
gua, asistencia o bien seguimientos y garantas'
Cuando se conozcan, debern identificarse las exclusiones, pues
los interesados suelen suPoner que lo que no est explcitamente ex-
cluido est incluido.
Fecha de terminacin del ProYecto
Aada la fecha de terminacin si la conoce. si no se ha fijado una fe-
cha, algo est mal. Crame, alguien tendr una expectativa muy defi-
nida de cundo debe finalizarse el proyecto y su trabajo como gerente
del proyecto consiste en documentarla en el protocolo. Tambin iden-
tifique, siempre que le sea posible, los principales referentes, esto es,
los hechos o acontecimientos que se usarn para medir el progreso. Si
no sabe culeS Son en este momento, no Se preocupe. Se reunir muy
Inicio del proyecto +J
pronto con el equipo y discutirn 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 terminacin, 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
estn separados. Incluso en estos casos, es imperativo que el gerente
del proyecto sepa cunto dinero y otros recursos podrn utllizar.
Suposiciones
No puedo exagerar la importancia de documentar las principales su-
posiciones en las que estn basados los dems elementos del protocolo'
Liste los factores o situaciones que usted suPone que existirn o no exis-
tirn al penetrar en la fase de planeacin. Por ejemplo, si no se conoce
con exactitud la fecha en la que dispondr de un cierto recurso, el
equipo debe hacer una suposicin razonable en cuanto a dicha fecha y
registrarla como suposicin. Si usted suPone que todos los recursos
clave estarn disponibles cuando se necesiten, que contar con los fon-
dos, que no surgirn 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, documnteles aqu y
disctalas con el patrocinador. Su objetivo es contar con una idea clara
del entorno y los retos que enfrentar como gerente del producto.
Relacin con los objetivos estratgicos
y otros proyectos
Como se muestra en la Figura 2-4, todo producto debe tener una
relacin con un objetivo estratgico o cuando menos con la unidad de
negocios para la que se va a desarrollar el proyecto. Y no est por de-
ms sealar que todo producto est relacionado con cuando menos un
proyecto y muy probablemente con otros ms. A menos que el gerente
del proyecto y el patrocinador sean conscientes de esto, se presentarn
problemas cuando surjan conflictos de recursos entre varios produc-
tos. Es un trabajo arduo obtener esta informacin, pero la inversin
reclita en eliminar el caos y una implantacin 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. Ntese que por lo general, otros interesados
suelen estampar sus iniciales en una hoja de coordinacin o enviar un
correo electrnico diciendo que han revisado el protocolo y estn 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 dems responsabilidades tpicas que se
requieren de un patrocinador, tales como las siguientes:
a Participa en las revisiones y la resolucin de problemas.
Distribucin 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 informacin de presupuesto y riesgos sea con-
fidencial.
Transicin a la fase de Planeacin
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
esrrollar el plan. Si se trata de un proyecto muy pequeo, usted y el
equipo pueden ser una sola persona. Gran parte de la informacin
inituiaa en el protocolo se utilizarpara el plan, pero ste es ms deta-
llado y constituye el mapa que el equipo usar para completar el pro-
yecto exitosamente.

Figura 24. Relacin estratgica con otros proyectos.

Establece y comunica el caso de negocios y la alineacin con el

proyecto.
a Fija el alcance y describe con claridad las expectativas.
a Selecciona y nombra a un gerente de proyecto.
a Acta como mentor del equipo y est disponible y accesible.
a Proporciona y garantiza el presupuesto requerido.
a Fija la estimacin inicial de la fecha de terminacin del
proyecto.
Participa con el gerente del proyecto en la definicin del pro-
yecto y el protocolo.
 Fundamentos
de la planeacin

I-
t-l
- principio directriz de la planeacin del proyecto es mantenerla
tan simple como sea posible, dependiendo del tamao de dicho pro-
yecto. Para proyectos pequeos, el plan puede consistir de dos o tres
pginas, mientras que en los proyectos grandes ser mucho ms deta-
llado. El plan del proyecto es el mapa para ejecutarlo y cualquiera que
sea su tamao, debe incluir y cubrir los siguientes elementos:
e Resumen del proyecto: Un resumen ejecutivo del origen del
proyecto y sus objetivos.
o Estructura de divisin del trabajo (EDT): La lista de tareas.
. Asignaciones de recursos: Quin va a hacer el trabajo.
. Programa del proyecto: El programa detallado de tiempos y la
fecha de terminacin.
. Presupuesto del proyecto: Cuinto dinero est asignado al
proyecto.
. Evaluacin de riesgos: Qu puede salir mal y que acciones y
reservas deben incluirse en el plan para mitigar los eventos de
mayor riesgo.
. Comunicaciones: Cmo planea el equipo comunicarse, reunir-
se y reportar los avances.
. Proceso de conhol de cambios: Cmo se manejarin los cambios.
 48 Curtis R. Cook
La manera ms rpida de desarrollar el plan consiste en reunir al
equipo del proyecto y tener una sesin de tormenta de ideas para cap-
turar y registrar la informacin necesaria. use tcnicas y materials
simples, tales como notas adheribles o un rotafolios, y despus 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 rene.o., t pu-
trocinador, hace los ajustes necesarios y pone el plan en su forma final
para su aprobacin. Cuando ya ha sido aprobado, el plan se convierte
en lo que se conoce como lnea base. En eite captulo nos concentrare-
mos en los fundamentos de la planeacin de pioyectos. En el Captu-
lo 4 introduciremos algunas tcnicas ms avanzadas, tales como el
anlisis de ruta crtica, para su aplicacin a proyectos ms complejos.
El proceso de planeacin
El protocolo del proyecto es la herramienta principal de la planeacin.
Proporciona toda la informacin que el gernte del proyecto necesita
para avanzar. Imagine por un momento lo que sera empezar ur-pro-
yecto sin esta informacin ----como disparar en la oscuridd esperando
dar en el blanco. si usted se llega a encontrar en este tipo de si-tuacin,
u{e hlber llegado el momento para aplicar una de las principales
habilidadesde los gerentes proyectos; seaisertivo y mantngase firme.
Asegrese de contar con un protocolo firmado.
La planeacin 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 diaisin del trabajo (EDT) o, ms comnmente, una lista de tareas.
Despus de que el equipo haya creado la EDT, se identifican las de-
pendencias de las tareas. En proyectos pequeos, esto es algo intuitivo
y obvio, pero en los-de gran tamao eslrabajo duro. Esta acin, junto
con el clculo de la duracin de cada tarea, resultar en la obtencin del
programa del proyecto y revelar la ruta crtica. (Definiremos y discu-
remos la ruta crtica posteriormente.) una vez que se han asignado los
recursos a las tareas de la EDI el programa del pryecto puedeiefinarse,
analizado en cuanto a,sus riesgos y preparad pra su aprobacin.
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 pequeos, stal son simplemente secciones o
Fundamentos de la
prrafos del plan general. una vez reunida y documentada toda la infor-
macin, el patrocinador aprueba el plan y el equipo est autorizado
para continuar y ejecutar el plan.
El principal entregable del paso de planeacin es el plan del pro-
yecto, que define en detalle:
. Qu se va a hacer (la ror)
o Quin har el trabajo (asignaciones de recursos)
. Cundo se har el trabajo (el programa del proyecto)
o Cunto costar el proyecto (el presupuesto)
o cmo se manejar el proyecto en trminos 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.
Gunto tiempo debe dedicrsele
a la planeacin?
con frecuencia me preguntan cunto tiempo debe dedicarse a la pla-
neacin. En nuestras sociedades occidentales, casi siempre tenemos
prisas para seguir adelante. Como resultado, usamos poCo tiempo en
la planeacin y demasiado en discusiones durante su ejcucin. En con-
traste, las sociedades orientales pasan ms tiempo planeando y lo-
grando consensos antes del trabajo y la implemntacin es basiante
tersa. Nuestra meta es dedicar a la planeacin el tiempo suficiente para
Iograr una comprensin clara de lo que se requiere pra alcanzar ei ob-
jetivo del proyecto.
Cgmo regla general, los equipos de proyectos deben pasar un m-
nimo del 5% de la duracin del mismo en la fase de planeacin. casi
siempre se requiere ms tiempo, pero ste es el mnimo. por ejemplo,
digamos que usted quiere construir una nueva plataforma de despacho
y que cree que el trabajo le tomar unos 3 das (24 horas de trabajo)
para hacerlo. El cinco por ciento de 24 horas es slo 72 minutos.
s
mucho ms tiempo planeando la cena del da de accin de gracias!No
obstante, al aplicar la regla general a nuestros proyectos en el trabajo,
gcneralmente se produce una reaccin negativa de los gerentes y los
50 Curtis R. Cook
miembros del equipo por el tiempo gastado en la planeacin. Escucha-
mos frases tales como "Sigamos adelante podemos perder el
tiempo en planes elegantes". Lo que realmente-no
estn diciendo es que no
tenemos tiempo para planear, pero s lo tenemos para reaccionar a las
consecuencias negativas que indudablemente surgirn si no hacemos
una buena labor de planeacin 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 reaccin ante las emer-
gencias posteriormente.
Formando el equipo central
El elemento ms 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 mayora de los gerentes de proyectos de poca experiencia que
han sido promovidos de las filas tcnicas dan por sentadas las habiti-
dades de la gente y, como resultado, no integran equipos de alto de-
sempeo. Si bien no est dentro de los propsitos de este libro entrar
en detalles de cmo integrar equipos, podemos proporcionar la infor-
macin "justamente suficiente" para hacerlo: Para obtener mayor in-
formacin, recomiendo altamente el libro del Dr. ]im Lewis, Project
Leadership (vase la seccin de lecturas adicionales).
Sin embargo, como mnimo, usted debe lograr lo siguiente para
tener probabilidades de formar un equipo cohesivo:
. Identifique a los miembros clave basndose 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 difcil.)
o Asigne papeles y responsabilidades en el equipo.
. Asegrese que el equipo cuente con los recursos necesarios.
Fundamentos de la planeacin 51
o Convoque a una reunin de inicio para que el equipo se conoz-
ca y se genere la excitacin y el compromiso (reparta esas ca-
misetas).
El gerente del proyecto debe participar directamente en la interac-
cin y operacin cotidiana del equipo. El liderazgo es quizs la habili-
dad ms 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 planeacin
La Figura 3-1 ilustra las actividades que el gerente de proyecto lleva a
cabo durante la segunda fase,la planeacin del proyecto. Veremos ca-
da una de estas actividades, de tal manera que, al terminar el captulo,
ser capaz de preparar un plan para sus proyectos reales.
Revise los requerimientos del proyecto
Un viejo axioma de la administracin 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 ejecucin. Y este primer paso del proceso de planeacin
consiste en analizar los requerimientos con una mentalidad abierta,
hablar con el cliente y comprobar que nada ha cambiado desde la ela-
boracin 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 quines estn 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-
cin de a quines quiere y quines estn 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 planeacin 53

Conduzca la reunin de arranque del proyecto

Figura 3-1. Diagrama de bloques del proceso destacando los pasos de planeacin
Despus que se han identificado y asignado los miembros del equipo
del proyecto, el siguiente paso es conducir una "reunin de arranque".
Esta reunin es una introduccin al proyecto para los miembros del
equipo que no fueron parte del esfuerzo preliminar de planeacin,
para el personal gerencial que aporta los miembros, Para la gerencia
ejecutiva y paraotros interesados en el proyecto. En esta reunin, el ge-
rente del proyecto lo describe, trabaja para establecer la identidad del
equipo y genera una sensacin de excitacin por el proyecto.
Como gerente del proyecto, la reunin de arranque es su primera
oportunidad para demostrar su liderazgo, Por lo que conviene seguir
las siguientes reglas:
1. Empiece la reunin a tiempo.
2. Logre sus objetivos usando una agenda.
3. Termine la reunin a tiempo.
Simple, no es cierto? Pero, cundo fue la ltima vez que asisti
a una reunin que empez y termin a tiempo y se lograron los obje-
tivos? Usted estar demostrando estos valores en esta reunin, por lo
que debe hacerlo bien.
El formato de la reunin de arranque depende del tamao y la
complejidad del proyecto ms grande sea ste, ms formal
-mientras
debe ser la reunin. Para la mayor parte de los proyectos, una agenda
simple y un mximo de L hora son suficientes para que el proyecto em-
piece bien. Y para equipos virtuales con proyectos pequeos, una lla-
mada telefnica puede bastar.
En la reunin de arranque, el gerente del proyecto debe establecer
una atmsfera de retos, trabajo en equipo y colaboracin 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 preParacin para la reunin.
Acabo de mencionar la agenda. Para garantizar que se cubran
todos los aspectos durante esta reunin ser una de las Pocas
ocasiones en que estn juntos -puede
en un solo lugar todos los individuos
clave para el proyecto- use una agenda que yo he usado durante
las dos ltimas dcadas. 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 reunin, destacan-
do las oportunidades que este proyecto representar para la
organizacin y para los miembros del equipo. Cubra cualquier
aspecto especial del proyecto que pueda presentar retos ms
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. Asegrese 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 opinin de la importancia del proyecto.
. Discuta los papeles y responsabilidades de todos los miem-
bros del equipo y otros interesados, si es que estn presentes.
. Discuta las comunicaciones. Qu informacin debr inter-
cambiarse? Quin necesita tenerla? Qu formar asumir? controlar la totalidad del proyecto durante toda su duracin.
Cundo se realizarn las reuniones del proyecto?
. para programar, presupuestar, asignar recursos, controlar los cambios
Usando como gua 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
terminacin. Presente los entregables del proyecto y discuta
los eventos importantes.
r Programe un taller de planeacin para que el equipo central
genere el plan del proyecto.
o Determine qu acciones de seguimiento se requieren a partir
de esta reunin y planee asignar responsabilidades acordes
con esto, para que la planeacin del proyecto pueda proseguir.
o Lleve comida.
Tabla 3-1 . Lista de verificacin de la reunin de arranque.
Fundamentos de la planeacin 55
Es una buena prctica tomar unas cuantas notas durante la reu-
nin y distribuirlas, junto con las acciones acordadas, a todos los asis-
tentes a la reunin. En muchos casos, el gerente del proyecto conducir
una reunin de planeacin detallada inmediatamente despus de esta
reunin. Recuerde notificar por adelantado a los miembros clave del
equipo de proyecto, pues las sesiones de planeacin toman ms tiem-
po que una simple reunin de arranque.
Nota: Asegrese que el patrocinador del proyecto tenga la oportuni-
dad de participar en la reunin de arranque. Es una oportunidad para
que l demuestre su apoyo al proyecto y al equipo, y la forma en que
encaja en la misin y la estrategia de la organizacin.
Genere una estructura de la divisin del trabajo (EDT)
El trmino estructura de Ia diuisin del trabajo puede sonar imponente,
pero es una frase de amplio uso que simplemente significa una lista de
las tareas que debern 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
La EDT es la clave para el resto del proceso de planeacin y se usa
de alcance, el anlisis y control de variaciones y los reportes de avance.
Muchas organizaciones desarrollan repetidamente el mismo tipo de
,rroyectos genricos. Como resultado, los equipos pocas veces tendrn
(lue crear una EDT desde cero. Es una buena idea conservar copias de
las estructuras ms cornunes de divisin del trabajo para uso futuro. Si
su empresa tiene una oficina de proyectos o una divisin que archive
lrs lecciones aprendidas y proporcione ayuda interna a los gerentes de
proyectos, podr suministrar muestras de EDT.
Ntense las primeras palabras de la definicin de una EDT: "lJna
r,DT es un rbol genealgico de todos los trabajos del proyecto..." Laa-
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 sern erradas. Cuando se
tlcscubra que falta ese trabajo durante la ejecucin del plan del pro-
vccto, tcndrn que adicionarse tiempo, recursos y dinero, causando va-
t'i.tr'iot.tcs inrr1rr1l1cs y cxpectativas fallidas. La creacin de la EDT al
56 Curtis R. Cook Fundamentos de la planeacin 57

INFORMACIN PARA LA PREPARACIN DEL DOCUMENTO nivel de tareas es el primer paso real del esfuerzo detallado de planea-
proyecto I proyecto cin del proyecto.
del Gerente del I Fecha de preparacin
En trminos generales, un proyecto est constituido por fases,
tales como diseo, desarrollo, pruebas, despliegue y transicin a opera-
INFORMACIN DEL PATROCINADOR
ciones y soporte. Estas fases pueden descomponerse an ms en tareas
Patrocinador I Informacin de contacto
especficas para ser asignadas a los miembros del equipo del proyecto.
Para cada fase y tarea del proyecto, la cuestin es si el elemento
ASISTENTES puede o debe descomponerse con mayor detalle para definir mejor el
Nombre I Correo electrnico u otra direccin trabajo a rcalizan Si la respuesta es afirmativa, el elemento se descom-
pone en partes ms pequeas, cada una de las cuales se evala de ma-
nera similar.
Qu tan detallada debe ser la EDT? Depende de cunta atencin
gerencial y control que usted, como gerente del proyecto, sienta que
INFORMAC]N DE LA REUNIN necesita para garantizar que el trabajo se haga. Descomponga el pro-
Fecha Tiempo de inicio Tiempo de terminacin Lugar yecto en tareas demasiado minsculas y el resultado ser una mi-
crogestin. Las tareas demasiado minuciosas invitar a Pasar por alto
Prposito de la reunin
un elemento crtico del trabajo que puede retardar el proyecto si se
deja de hacer. La clave para una adecuada estructura de divisin del
trabajo es un buen criterio.
TEMAS DE AGENDA PRESENTADOR TIEMPO Una EDT puede representarse con un formato grfico o con una
descripcin. Una EDT grfica es parecida a un organigrama, tal como
Bienvenida e introduccin
se muestra en la Figura 3-3.
Perspectiva ejecutiva

Panorama del proyecto

Objetivos del proyecto
.,:,:,...,.::,:..:...o:llu,..ll,..lll..:lll
Elementos del protocolo
Solucin propuesta
Entregables del proyecto
Logros del proyecto a la fecha t.l:t2
'.,;,',rl',;,:,7,ai]tt',irr;,;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 grfica

 58 Curtis R. Cook Fundamentos de la planeacin 59

Si bien es til como ejercicio de integracin del equipo, generar Comentario sobre el uso de software
una EDT usando notas autoadheribles, la mayora de las veces se dis- de administracin 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 ningn
muestra una descripcin para la construccin de una casa en el hermo- otro software de administracin de proyectos. La razn de esto es sim-
so paraje de Beech Mountain, North Carolina. Ntese que la EDT de la ple: Muchas personas no cuentan con software de programacin 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 algn parmetro para evaluar si el trabajo se de este libro son Word, Excel o PowerPoint Adems, los formatos son
est haciendo a tiempo y tal como se especific. Contar con un entre- fciles 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,Prson,;::::l:
Tarea Entresable Etmd r,is,od,,,,,,,,
::,,:i,:Fh,:drrl
:telmjhadi plan del proyecto se titula Hoja de trabajo de tareas del proyecto. Es una
1.'t Limpiar el lugar
hoja de clculo 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 asignacin de
1.2 Construir recursos, fechas de terminacin de tareas planeadas, fechas de termi-
cimientos
nacin 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 tpico.
1.2.2 Colado de Ioclas las zapatas Jailors Ntese 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 aadir 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. Adems, 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 adicin de tareas de administracin del proyecto tam-
Marco de Pyramid
de la Casa madera completado
37,000
Builders
Octubre 31 bin ayuda a que sus esfuerzos sean visibles.
Techo instalado
1.3.2 Colocacin 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 ms importante actividad del gerente del proyecto. Si usted ha segui-
1.3.3 Instalacin
de tuberas Etc. 14,000 Barney Dic 15 do el "libreto",habr realizado la reunin de arranque y ahora todos
1.3.4 lnstalacin
estn 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 especficas
Elctrica 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 quines y qu necesitamos para que el proyecto sea un xito?
Figura 34. Descripcin de la EDT: construccin de una casa en Beech Mountain. a
Quines estn realmente disponibles?
60 Curtis R. Cook Fundamentos de la planeacin 61

Tra Oriih Ondo i'i: ;ii.',i'

Hoja de trabajo de las tareas del proyecto-Globus Offsite
iEtisqb!

rfate Entigabit. Quin Gffientaric

Admn. proyecto Varios
Reunin de Agenda de Sally
19t5t04
arranque la reunin 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 necesaros
Capturar Documento Sally y
las lecciones de lecciones equipo 24t6t04
aprendidas aprendidas
Celebracin Diversin 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 Cmo podemos compensar la carencia si los recursos no estn Obtener capaci- Contrato Seth Godin 3t6to4
tador externo
disponibles cuando los necesitemos? Arreglar Contrato Bill McMurry 7t6to4
o Causarn las restricciones de recursos fallas de programa- entretenimento

cin o de presupuesto? (Cualesquiera disponibilidades de re- Revisar

presentaciones
Presentacio- Sally y 7t6t04
nes aprobadas Seth
cursos no resueltas causarn problemas que eventualmente
Prueba Ensayo lnteresados 15t6t04
se reflejarn en una de las restricciones del triplete: fallas de del evento
programacin, disminucin del contenido tcnico del proyec- Instalaciones Cuartos,
y coordinacin alimentos, Equipo 17t6t04
to o costos excesivos.)
del evento etc.
Discuta los faltantes o los cuellos de botella con el patrocinador Evaluacin Evaluaciones Seiichi 1 8/6-
de la reunin y resumen Naqao 21t04
del proyecto. Cuando haya resuelto estos aspectos e identificado a los
miembros del equipo que realizarn 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 planeacin 63
62

fual. Estos esfuerzos llevan a la ruta crtica, que se discute en

en la Figun 3-6- Si el "quin" es un proveedor, anote esa informa-
el Captulo 4.
cin en lugar de un nombre.
4. Consultndolo con el miembro del equipo responsable, deter-
Programe el trabajo mine la fecha de terminacin de cada tarea, recordando las
Tiempo-alguna vez hay suficiente tiempo? No en el mundo de los condiciones sealadas en el punto 2.
proyectos. La programacin del proyecto es las "entraas" del plan y, 5. Anote las fechas de terminacin 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
tcnicos. 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 programacin. Pueden incluirse en la hoja de
Crear un calendario del proyecto consiste en seis pasos funda- trabajo usando la columna de "comentarios". (Slo hace falta
mentales: hacer un "click" con el botn derecho sobre la correspondien-
te celda y oprimir "insertar comentario".) Esto es importante
1. Generar una estructura de divisin del trabajo hasta el nivel de cuando se discuten las razones de la calendarizacin 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 nacin. Con todas las tareas relacionadas y asignadas y ya con
dedicar 8 horas completas diarias a trabajar en el proyecto. las fechas de terminaciry se puede determinar la fecha de ter-
Parte de su tiempo estar dedicado a actividades que no son de minacin del proyecto.
trabajo directo, tales como entrenar, tiempo libre, caf, Pausas
para fumar, etc. Otra porcin veces considerable Plan para montorear
-a -esta
dedicada a trabajo operativo. Y su proyecto no es el nico en el
que estn trabajando, por lo que slo disponen de cierta parte
la finalizacin de tareas
de su tiempo para su proyecto. Asegrese que cuando alguien Para resumir en dnde estamos en cuanto a la planeacin, 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 dems activi- incluido la persona que-la la llevar a cabo (el "quin" de la hoja de tra-
bajo) y la fecha de finalizacin ("cundo"). Estamos progresando bas-
dades o se refiere a un mundo perfecto sin interrupciones? En
el Captulo 4 discutiremos esto a fondo. Por ahora, asegrese
tante, pero necesitamos un plan para ver cmo monitorearemos
posteriormente las fechas de terminacin, una vez iniciado el trabajo.
de comprender el mensaje que se le est comunicando.
lln el Captulo 4 se cubre esto, adems de algunas tcnicas avanzadas
3. Establecer las dependencias entre las tareas. En otras palabras,
tle programacin.
decidir cundo puede empezar cada tarea y cundo debe ini-
ciarse de acuerdo a las tareas anteriores. Se establecen tam-
bin las actividades sucesorias. A dnde conduce cada tarea?
Qu se retrasara si una tarea se frenara? Es trabajo arduo,
pero debe hacerse para tener una calendarizacin realista. Si
est empezando sin un plan del proyecto como gua, use notas
autoadheribles para mostrar las relaciones. Si cuenta con un
ejemplo anterior, simplemente aada, elimine o modifique las
tareas y relaciones para que sean un reflejo del proyecto ac-
 <-'@ry'

Tcnicas avanzadas
de planeacin

I-
,-
Ln el Captulo 3 hablamos de los fundamentos de la planeacin de
proyectos. En ste daremos un paso ms y presentaremos algunas he-
rramientas avanzadas de planeacin que ayudarn a controlar el pro-
yecto. Tambin discutiremos la importancia de contar con un plan de
comunicaciones y cmo desarrollarlo. Veremos la forma de anticipar los
riesgos y formular un plan para reaccionar a ellos en caso de ocurrir. Y
veremos cmo 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 montorear la finalizacin de tareas
Los gerentes de proyecto ms exitosos saben en todo momento dn-
de est exactamente el proyecto con respecto al tiempo. Para facilitar
cl trabajo de comparacin de los tiempos reales con los planeados, se
pueden usar tres diferentes perspectivas del programa del proyecto:
un calendario simple, una grfica 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-
rninacin de tareas consiste en usar el software de calendario que casi
66 Curtis R. Cook Tcnicas avanzadas de planeacin 67

todos tenemos en nuestras computadoras' Personalmente uso el Out- Grfica de Gantt

look de Microsoft cuando no estoy usando una aplicacin de Progra- Hay otros dos mtodos populares Para representar y monitorear fe-
macin de administracin de proyectos (Figura 4-1). El outlook me chas de finalizacin: la grfica de Gantt y Ia red lgica (tambin llamada
permite aadir tareas a mi calendario, compartir calendarios con otros diagrama de red, grfica PERT o diagrama de precedencia). En la prctica,
miembros del equipo y agregar los recordatorios que surjan Para ase- estos enfoques slo pueden usarse en combinacin con softwares de
gurarme de estar al tanto de las tareas clave que aparecern pronto, y administracin de proyectos
-a menos que a usted le guste construir
opiar y pegar informacin a otros softwares para reportar preparacio- a mano grficas complicadas. Ningn libro sobre administracin de
t ur y .bti"t electrnicos. Inmediatamente despus de fijar las fechas proyectos estara completo si no mencionara estas herramientas.
de finalizacin, resolver las restricciones con el patrocinador (y asumir Las grfica de Gantt en todos los libros y cursos de
-estudiadas
muchos riesgos -discutiremos esto despus), agrego las fechas de ter- capacitacin- son simplemente grficas de barras horizontales con
minacin y ls eventos clave a mi calend atio Outolook y enciendo la fun- una escala de tiempo, mostrando el inicio, la finalizacin y la dura-
cin de reiordatorio Para darme suficiente tiempo de reaccin en caso cin de cada tarea, as como su relacin con las dems. Mientras que un
de presentarse un Problema' calendario distribuye el programa en varias pginas, una grfica de
El enfoque tut simple que es muy sorprendente que no haya Gantt muestra el programa en una sola pgina de la EDT y proporcio-
"J
ms personas usndolo. Intntelo na una visin clara de dnde est el proyecto con respecto al programa
-funciona' planeado. Esto hace de la grfica Gantt una excelente herramienta pa-
ra discutir el proyecto en reuniones de seguimiento cuando
se necesita construir otra peridicamente con el
-incluso
software de presen-
Domin$o Lunes' Martes Mircoles Jv"s Vierrre sbdo
tacin. Y claro est, las grficas de Gantt se construyen automtica-
Registrar Verificar mente una vez establecidas las dependencias y duraciones. La Figura
proyecto precos
materiales
4-2 muestra una grfica de Gantt genrica.
en el JHSS
Ntese que los programas para las tareas D1' y D2 de la Figura 4-2,
Completar
Obtener
pran incluyen ambas un colchn,lo que significa que las fechas de finali-
copia de
propuesta del proyecto zacin pueden variar dentro de ciertos lmites sin que tengan impacto
firmada
por el CSM cn la fecha de conclusin del proyecto. La tarea D1 puede retrasarse
por casi una semana y media antes de que afecte aLaE1., y laD2 puede
ldentificar lnicar
lder 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 lgicas entre las tareas
sin una escala de tiempo. La gran ventaja de un diagrama de red es que
rrruestra la ruta crtica del proyecto de tareas a travs de
-la secuencia
la red en la que cualquier demora causar un retraso en la fecha de la
f inalizacin del proyecto en su totalidad. La construccin 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 finalizacin del proyecto de una manera lgica y directa. Unavez
Figura 4-1. Vista del calendario. t'orrstrtriclo cl diagrama de red, la ruta crtica puede mostrarse en una
68 Curs R. Cook

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

de hacer para que dichos Programas sean ms realistas'

B1
Diseo del
sistema de
1234567 negocios
@ La linea indica el colchn
A g"t" smbolo indica el inicio de la tarea
V g"t" smbolo indica la terminacin de la tarea c2
Modificar
Procedimientos
Figura 4-2. Grfica de Gantt. internos

grficaGantt cuando sta se usa para informar al patrocinador o a los D2

i-nteresados. Las tareas crticas aadidas a un calendario Outlook

pue- Probar
procedimientos
den resaltarse y monitorearse ms de cerca que otras. (Ib.gu cuidado, internos
sin embargo, pues la ruta crtica tiende a cambiar cuando se va agotan-
do el colchn de tareas no crticas.)
Los diagramas de red son difciles de mantener al da si no se est
usando ,rr, ,ft*ute de administracin de proyectos. No obstante, para
la sesin inicial de planeacin son casi indispensables cuando el equi-
po ,,empie za de.".b". La Figura 4-3 ilustra un diagrama de red tpico.

Prog ramacin "avanzada"

Si bien nuestra concepto de administracin 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 lnes sobre consideraciones de Programacin avan-
Figura 4-2. Diagrama de Red
,rdo. gn esta seccin cubrir un Par de factores del mundo real que
 70 Curtis R. Cook
Presin poltica
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 aprobacin. l patroci-
nador puede reaccionar emocionalmente, diciendo cosas como,' -trab ajen
con ms inteligencia. Dnde est esa actitud de ,si se puede,? Nues_
tros competidores se nos adelantarn 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 presin.
Qu puede usted hacer como gerente de proyecto en esta sifua-
cin? Mi consejo e?.que mantenga la calma, aipiie 10 veces profun-
damente y use la lgica del proceso para estaLlecer un dil,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 lgica de trabajo, usado la EDT para fiar las fechas de finali-
zacin-de tareas y relacionado las tareas entre ellas para generar una
fecha de terminacin racional del proyecto. Tiene todas las'cartas en la
mano. Ane este enfoque racional al poder de su firmezay convencer
a los escpticos de que usted y el equipo estn en lo crrecto y que
quienes desconocen los detalles estn equivocados.
Qu pasa si, a pesar de este enfoque, todava persiste la resis-
tencia y la presin para comprimir las fechas? Tiate de invitar a esa
persona a una sesin de resolucin creativa deproblemas, donde expli-
car-en detalle que usted y elequipo realmentcreen que estn p.urln-
tando la realidad. Pero, si se le pas algo, tambin qurr sabeiqu es
y obtener el beneficio de la experiencia y las leccions aprendidas-. Este
dilogo desembocar en uno cualquiera de tres resultaos:
1. Despus 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.
Tcnicas avanzadas de planeacin 71
3. Se le dir que no hay otra solucin y que se ponga a trabajar.
En este caso, ajuste el plan a sus deseos, documente la conver-
sacin y actualice su currculo, pues lo necesitar al no cumplir
con la fecha de terminacin.
Los gerentes de proyectos deben mantenerse firmes en lo que
creen es realista, incluso cuando son confrontados por el patrocinador
o algn 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 obstcu-
los y alcanzar el xito. Puede que se trate de un complejo de hroe,
pero esto sera 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 terminacin, 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
programacin.
Incluso los modelos de programacin ms bsico por ejemplo, la
tcnica de reaisin y eualuacin de programas (pERt por sus siglas en in-
gls) 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 ms 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 ms cercano
al caso optimista que al peor de los casos (pesimista). La Figura 4-4
rrruestra esta tendencia de manera grfica.
Ntese en la Figura 4-4 que el estimado ms probable est ms
cercano al valor del lado izquierdo, el optimista, que al del lado derecho
o pesimista. Como resultado, la estimacin para la fecha de termina-
t'itirr total del proyecto es ms 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. Grfica 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 ms
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 ms pesimista que el estimado ms probable de un
solo punto que le dieron inicialmente. Me gusta Pensar en este valor
como un dato ms realista, no pesimista, considerando los muchos pro-
yectos que exceden las fechas de terminacin planeadas.
Por ejemplo, digamos que uno de los miembros de su equipo le ha
dicho que se necesitarn 10 das para completar una tarea. Usted registra
este dato en el programa junto con los dems estimados. Ahora suPon-
gamos que decide usar el enfoque PERI y le pregunta a la cul sera 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 das. Cuando le pre-
gunta sobre el mejor de los casos,le dice que Podra hacerlo en 8 das si
todo funciona a la perfeccin. Aplicando la frmula PERT a estos estima-
dos, se obtiene un tiempo estimado (T") de 11.3 das, en comParacin
con la estimacin de un solo Punto de 10 das diferencia de ape-
nas 1".3 das. Esto no Parece Sran cosa, pero
-una
incluso en un Proyecto Pe-
queo, probablemente existirn 30 o 40 tareas. Digamos que 15 de esas
tareas estn en la ruta crtica. Multiplicando 1..3 das por 15 tareas nos
da L9.5 das. se trata de casi un mes comPleto de trabajo. En un sentido
muy real, su fecha estimada de terminacin ya est subestimada por L
mes antes que siquiera se inicie el trabajo. Ahora si es algo importante.
Tcnicas avanzadas de planeacin 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 ms crticas, calcular los tiempos esperados Para esas tareas y usar
estos valores para su programa, en lugar de las cifras nicas ms proba-
bles que casi siempre se usan. Tambin puede aadir tiempo al programa
como una contingencia para este fenmeno si no puede obtener los tres
estimados de la gente muy ocupada que est haciendo el trabajo.
Estadstica y convergenca de rutas
Muchos gerentes de proyectos no entienden de estadstica. 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, tambin podemos obtener lo que se conoce
como desaiacin estndar. Se trata de una medida nmero- que
-un
representa cuinto tiempo tendramos que agregar al programa para in-
crementar la probabilidad de xito. Pero me estoy adelantando. Prime-
ro se necesita conocer un fenmeno 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 podrn inicia-
rse cuando estaba planeado. Cuando esto sucede, tenemos que tomar
en cuenta las probabilidades combinadas. Una probabilidad combinada
ocurre cuando dos o ms eventos son interdependientes.
Por ejemplo, veamos si puede contestar esta pregunta: Si tiene un
90% de confianza de que las tres tareas se terminarn
-DL,D2yD3-
a tiempo, cul 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 cmo 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 slo 70"/" probable. Y se pone peor. Digamos que tambin
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 tambin 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 drsticamente reducida,
74 Curtis R. Cook
aun cuando estamos 90% confiados en que cada tarea del plan trans-
currir como se esperaba.
La combinacin 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 cunto
tiempo se necesita aadir al programa Para elevar las probabilidades
de terminacin a tiempo a un nivel confortable. Podramos calcular la
desviacin estndar usramos 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.
Dnde nos deja esto? Sin duda, nos deja vulnerables. Pero habla-
remos de la administracin de riesgos agregando una reserva a nues-
tro proyecto. Tenemos que incluir reservas o reguladores, que sern
usados a discrecin del gerente del proyecto para restaurar las proba-
bilidades. El nico problema con este mtodo es que algunas Perso-
nas Io consideran como un acolchonamiento. El hecho simple es que
estas fuerzas actan en nuestros proyectos y debemos planear tomn-
dolas en cuenta para tener una posibilidad razonable de triunfar. Y si
alguien lo quiere desafiar cuando sugiera crear este regulador, pre-
gntele qu porcentaje de sus proyectos se terminan a tiempo. Esto le
proporciona una evidencia suficiente.
Presupuestacin de proyectos
Un amigo mo muy sagaz, alguna vez me dijo que todos los excesos de
costros de un proyecto se deben a problemas de estimacin. Y es cierto
conociramos un proyecto a la perfeccin antes de iniciarlo, ge-
-si
neraramos estimados correctos todas las veces. En el mundo real esto no
Sucede, pero s existen mtodos para ayudarnos a formular estimados
de costos bastante confiables.
Hay tres niveles de precisin o estimacin de Proyectos/ conoci-
dos con los nombres de descendente, presupuestario y ascendente'
Presupuesto descendente. Recuerde que el protocolo del proyecto con-
tiene una estimacin de su costo. De dnde provino esta informacin? si tttacititr t'sll r.i.
Tcnicas avanzadas de planeacin 75
Probablemente de una estimacin gerencial, basada en experiencias
anteriores, o quizs fue la cantidad contratada menos gastos generales
y utilidad. En cualquier caso, fue la visin "desde 10,000 metros de
altura". Por definicin, 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 lmite de lo que el gerente de lo que el gerente del
-el
proyecto puede gastar.
Estimacin presupuestaria. Cuando el objetivo del proyecto est bien
definido, se conocen las categoras de recursos y gastos y se dispone de
informacin 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 planeacin. 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 estimacin ms precisa se
obtiene estimando el costo de cada tarea de la Eot, sumando todos los
estimados y aadiendo 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 prticipar en la estima-
cin 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. Aadir una cantidad para contingencias imprevistas. (Habla-
remos de esto ms adelante.)
IJna vez completado el estimado ascendente, comprelo con el
cstimado descendente incluido en el protocolo del proyecto. Resuelva
las discrepancias discutiendo las diferencias con el patrocinador del
proyecto. No sea tmido de su trabajo es manejar las expectati-
vas y mientras ms pronto -parte
se refiera a la discrepancias, en mejor
76 Curtis R. Cook Tcnicas avanzadas de planeacin 77

Planeacin de resgos
Enfrentmoslo, no todo saldr de acuerdo a lo planeado para el proyec-
to, por lo que es prudente tomar en cuenta los riesgos que comnmente
o.rlrr.r, en el eniorno de proyectos. Incluso en proyectos pequeos, la
planeacin de riesgos es lmportante. Los riesgos y las es-trategias de
mitigacin deben dbcumentarse en el plan del proyecto. El gerente-del
proylcto debe hacerse una pregunta simple: " LQu puede salir mal en
ste proyecto?" Como mnimo, considere las siguientes interrogantes
cuando est formulando el Plan:
1,. se comprenden bien los requerimientos del cliente y estn
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. Anlisis de riesgos.
4. Habr recursos dedicados al proyecto o slo
estarn disponi-
bles en el momento en que se necesiten?
IJna vez que se han identificado y analizado los riesgos, existen
5. Se reasignarn recursos clave al proyecto
o se perdern?
bsicamente cuatro maneras para manejarlos:
6. Presionarn los clientes u otros las fechas lmite? 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 extrao, pero esta decisin debe
8. Tendremos problemas tcnicos? 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 tcnico del trabajo
La evaluacin y planeacin formal de riesgos son muy importan- para eliminar las soluciones de alta tecnologa. De otra manera,
tes en los proyectos grandes y se cubren en detalle en cursos de capaci-
evitar el riesgo no es una opcin.
tacin y libros enfocados a proyectos importantes. Pero an en proyectos
o Aceptarlo: Literalmente, la aceptacin significa no tomar ac-
pequeos necesitamos incluir la planeacin de riesgos como un Paso cin alguna para reducir la probabilidad o el impacto del suceso.
ormal de los esfuerzos de programacin de proyectos. Como dice Clint Eastwood, "Te sientes con suerte?" Pot ejem-
El riesgo puede definirse como una funcin de tres variables -un plo, si usted se sube a su automvil y conduce en una autopista
suceso qne pnae causar una perturbacin, la probabilidad de que el su- interestatal a ms de 100 kilmetros por hora sin abrocharse el
ceso se preJente y el impacto que el suceso tendr en el proyecto si se cinturn de seguridad, est aceptando el impacto de su deci-
presenti. En la Figura 4-5 se muestra la interaccin de estas tres variables. sin si llega a tener un accidente. En general, la aceptacin no
si utr suceso de riesgo es probable y tendra un efecto catastrfico, 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 mitigacin 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 planeacin 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 Tcnicas avanzadas de planeacin 79

planeacin para disminuir la probabilidad o el impacto del su- Informacin del proyecto Describa el suceso que podra ocurrir
ceso? Por ejemplo, un riesgo tpico es la posibilidad de que al Nombre del proyecto
equipo le sea retirada una persona clave cuando ms se nece- Gerente de proyecto/ Tet.
sita. Qu puede hacer para mitigar este riesgo? Podra sub-
Tarea
contratar la tarea o cuando menos desarrollar un plan para
ello, que entrara en accin si obtiene indicios del suceso. Tam- # de EDT o tarea
bin podra desarrollar una fuente secundaria entrenando a al- Alta
guien ms para el caso de necesitarse. El objetivo es disminuir
Describa el impacto significativo
el riesgo a un nivel aceptable para que no mate ni dae 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 planeacin de riesgos. La Describa la probabilidad del suceso
Figura 4-6 muestra un formato que he usado durante aos para ayu-
darme a identificar y analizar los riesgos y escoger la estrategia de res- Bajo lmpacto Alto
puesta ms adecuada.
Al final de la sesin de planeacin de riesgos, el gerente del pro-
yecto selecciona las respuestas apropiadas y ajusta la restriccin triple
costo o enfoque tcnico 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 despus seleccione la que mejor corresponda a en la situacin.

Respuestas al riesqo
Planeacin de la comunicacin
Estrategia Evitar Aceptar Mitigar Transferir
Un elemento esencial de cualquier plan debe ser una discusin de las
maneras en las que el equipo se comunicar durante el proyecto y Ventaias
cmo se transferir la informacin 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 administracin de riesgos.
primarios:
1. Estamos tan ocupados que nos olvidamos de mantener el flu- Estas dos causas estn relacionadas entre s. Si el plan del proyec-
jo de informacin. to incluye los requerimientos de comunicacin y las expectativas del
2. El gerente del proyecto no ha hecho planes para el intercambio c'quipo, lo ms probable es que haya un buen flujo de informacin y
de informacin. se presentcn menos sorpresas.
 t
il
I

lr Tcnicas avanzadas de planeacin B1

80 Curtis R. Cook

Las comunicaciones en el entorno de un proyecto no son fciles.

. Revise con ellos sus ideas, borradores y planes.
El nmero de enlaces de comunicaciones crece exPonencialmente a . Obtenga su aprobacin para los cambios pendientes.
medida que aumenta el nmero de miembros del equipo, tal como se . Obtenga su aprobacin de los entregables finales.
muestra a continuacin. . Establezca un "dilogo continuo" con el equipo.
Nmero de canales de comunicacin en una red: La aplicacin 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 ms simple es un memo o un correo electrnico. 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 ms 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
Mmorndo de avance del proyecto
2
A: Curtis Cook.
Es evidente que una de las ms 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 prrafo o dos descri- fnico.
biendo los siguientes elementos: Fecha: 4-12-04
o Quines necesitan la informacin?
o Por qu la necesitan?
Logros esta semana:
. L. Se prepar un documento conteniendo todos los requerimientos
Qu necesitan?
. de entrenamiento, junto con la descripcin de cada uno de ellos.
Cundo la necesitan?
o 2. Se identificaron los principales impresores y se recibieron sus
En qu forma necesitan la comunicacin? cotizaciones.
. Cundo se debe reunir el equipo del proyecto Para discutir los
avances, los problemas, etc.?
3. Se inici el trabajo de preparacin 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 accin:
del mismo semanalmente, el gerente lo consolida,lo evala en general 1. El departamento grfico advierte que hay lentitud en los trabajos
y se lo pasa al patrocinador y al cliente, junto con cualquier accin para debido a sobrecarga.
superar los reveses. Los siguientes son algunos lineamientos probados
y comprobados: Estado general del proyecto: Verde.
. Comunquese 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 Tcnicas avanzadas de planeacin 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 ms importantes de la administracin de proyectos.
Nombre del proyecto: El deslizamiento del alcance expansin irrestricta del alcance-
Semana terminada el: puede causar que se rebasen -lael protocolo del proyecto y el presupues-
to con respecto a la lnea 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 Refirase a la EDT para reportar los logros, nada del plan del proyecto aprobado puede cambiar sin la partici-
planes y asuntos. pacin del gerente del proyecto. Como mnimo, 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 prxima semana trnico.
LA SEMANAQUE y las actividades importantes para este proyecto. 2. Los cambios se registran usando una hoja de clculo simple.
TERMINA 1. 3. El equipo evala 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 lmite nuevas, licitud de cambio es retirada al conocerse su impacto.)
FECHAS LMITE modificadas o importantes. 5. El cambio propuesto se discute con el patrocinador y el cliente.
Tarea
- Fecha lmite revisada 6. El cambio es aprobado o rechazado y se le informa la decisin
al solicitante. (Asegrese que todo mundo entienda quin 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 pequeos, las solicitudes de cambios pueden pre-
sentarse por correo electrnico, pero en proyectos mayores y ms com-
plejos, deber usarse unformato de solicitud de cambio, tal como el que se
muestra en la Figura 4-9.
A primera vista, parecera 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 estn acostumbradas o no quieren
ASUNTOS Liste cualquier asunlo (nuevo o abierto)
aceptar. Usted y la alta gerencia deben juzgar cunto proceso es justa-
que requiera un plan de accin.
mente suficiente para controlar los cambios en su empresa.
RIESGOS Liste cualesquiera riesgos nuevos o continuos
asociados con el proyecto. Aprobacin del plan del proyecto
l)espus 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 Tcnicas avanzadas de planeacin B5

asegurarse que sea internamente consistente. Esta revisin garanti-

INFORMACIN DE PREPARACIN DE DOCUMENTO
za qlue se han incorporado todos los elementos importantes del plan y
Nombre del proyecto Preparado por Fecha de ldentificacin
preparacin del provecto
que el equipo tiene una fuente de informacin 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 administracin 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 lnea base aprobada, el control objetivo de los aspec-
tos tcnicos, los costos y el programa ser muy difcil, si no es que
imposible.

RMONES DEL CAMBIO Transicin 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 duracin y el costo del cambio especfico, as como
el impacto general si se conoce.
SUPOSICIONES
Liste las suposiciones tcnicas y de negocios.
La aprobacin del plan del proyecto constituye el final de la fase de
planeacin y el inicio del esfuerzo fsico y de la fase de control del ciclo
de vida del proyecto. ste es un buen momento para invitar al equipo
a una pequea celebracin. Despus de esto, la presin continuar in-
crementndose para que el proyecto se desarrolle de acuerdo al plan.
Recordar que la fase de planeacin empez con mucho bombo.
Hubo una reunin de inicio a la que asisti el patrocinador y que sir-
vi para motivar al equipo. Si bien no suele haber una sesin formal
para comenzar la implantacin y el control, es una buena idea juntar
al equipo con el patrocinador para forrnalizar la aprobacin del plan
y lograr que l los aliente al comenzar el trabajo.

AUTORIZACIN _ GERENTE DEL PROYECTO

Nombre Firma Telfono Fecha

AUTORIZACIN - PATROCNADOR DEL PROYECTO

Nombre Firma Telfono Fecha

Figura 4-9. Formato para la solicitud de cambios

 Gontrol del proyecto

,
,
Llegamos a la parte difcil. El proyecto est en marcha y estn suce-
diendo cosas. Se estn realizando tareas, surgen problemas, ocurren
cambios. Lo que pareca claro y manejable est ahora desdibujado y
complicado. Estamos inundados de informacin de ta-
-terminacin
reas, retrasos, aspectos que requieren nuestra atencin y reuniones a las
que tenemos que asistir. Nuestro desafo es mantener el CONTROL.

Actividades de control
Durante la fase de control del proyecto, el equipo lo desarrolla de acuer-
do a la lnea base del plan. Siguiendo la estructura de divisin 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 ejecucin.
Las actividades de esta fase en realidad se llevan a cabo en para-
lelo ms que secuencialmente. El gerente del proyecto debe controlar
estas actividades y asegurarse que se enfoquen en completarlo de
acuerdo a los objetivos de desempeo.
En la Figura 5-1, se muestran las actividades especficas que reali-
za el gerente del proyecto durante esta fase. Discuremos cada tina de
ellas por separado.

Administracin del desempeo tcnico

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

88 Curtis R. Cook Control del proyecto 89

debe asegurarse de estar logrando avances tcnicos, as como progresos

en otras reas, con respecto a la consecucin de los objetivos. Los pro-
cesos de planeacin, ejecucin y control existen por una razn
-para
satisfacer los requerimientos del proyecto enunciados en el protocolo.
Ya sea que el desempeo resulte en un producto fsico o un servicio,
constituye la base de la existencia del proyecto.
Su labor como gerente del proyecto, aunque usted mismo est
realizando algunas tareas tcnicas, es monitorear todo el trabajo tcni-
co que se est desarrollando y evaluar el progreso con relacin al plan
del proyecto. Su fuente de informacin es, desde luego, el equipo de
trabajo. Ms adelante discutiremos la administracin del equipo, pero
es obvio que sin un alto nivel de confianza y respeto entre el gerente
del proyecto y el equipo, la informacin que fluye hacia el gerente del
proyecto sobre el estado del trabajo tcnico, estar distorsionada.
Basndose en la informacin recibida, iniciar acciones correc-
tivas para cualquier variacin surgida. A continuacin se discute la
forma que pueden aplicarse estas acciones. Thmbin estar monito-
reando las actividades de cambios de tareas tcnicas, el cumplimiento
del proceso de control de cambios y la incorporacin de cambios al
plan despus de ser aprobados por el patrocinador. Por consiguiente,
la comunicacin constante del progreso tcnico 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 orientacin tcnica 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 tecnologa del proyecto, el
Oesar.rollar conocimiento tcnico para los proyectos pequeos es una necesidad
proceso de
control ineludible. No obstante, mientras mayor sea el proyecto, menos cono-
de cambos
cimientos tcnicos se requieren. De hecho, en los proyectos de gran
envergadura, probablemente es un error que el gerente trate de parti-
cipar en los aspectos tcnicos. Para expresarlo de otra manera, si el ge-
rente est en los pasillos acomodando la mercanca en los estantes,
quin estar manejando la caja registradora y la tienda? El proyecto
puede salirse de control en un rea tcnica mientras el gerente est
profundamente involucrado en su tecnologa favorita. Mientras ms
grande sea el proyecto, ms 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
Comunicacn de logros
y estado del proyecto
Est usted satisfaciendo las expectativas del cliente y
del patrocina-
or? No suponga que as es ---<omunquelo. Aunque no lo crea, a la gente
suele olvidrsele hcer esto. Estn 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 peridi-
cos del estado del proyecto y visitas cortas ayudan a asegurarse que
est cumpliendo las expectativas. Las comunicaciones frecuentes tam-
bin le ayudarn a lograr una influencia informal con el equipo y le
proporcionan al patrocinador la informacin 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 explcitamente en el plan del
-todo
proyecto. Si no fue as, tendr problemas en esta etapa para que_todos los
invlucrados "lean la misma pgina" con respecto a intercambio de in-
formacin. Si por alguna razn, el plan no incluy esta informacin, aho-
ra es el momento pra establecer los mtodos que usar para el resto del
trabajo. Es buena idea modificar el plan con esta informaciry Para no
tener problemas repetitivos ms adelante cuando las cosas estn "ca-
lientes".
Supongamos que se hizo bien y se documentaron los requeri-
mientos e inlercambios de informacin en el plan del proyecto. Todo lo
que tiene que hacer es entonces seguir el plan. Use el formato de
ieporte seleicionado para recabar informacin del equipo y pasrsela
al patrocinador y otros interesados.
Reunirse o no reunrse-sa es la cuestn
En el plan del proyecto, quizs incluy un comentario general referen-
te a que el equipo se reunir "cuando resulte necesario" para resolver
problemas, adems de las reuniones semanales programadas para re-
portar los avances. Pero en la prctica, cundo debe reunirse fsica-
mente el equipo? Por una parte, querr evitar reuniones rutinarias sin
ningn propsito, mientras que por otra, desear reunirse con la su-
ficiente frecuencia para Preservar la identidad y el espritu 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 inters comn y
obtener retroalimentacin del equipo.
El tipo de retnin ms frecuente se centra en el estado del proyecto.
Estas reuniones le ofrecen al gerente del proyecto la oportunidad de
solicitar retroalimentacin, avances, informacin 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 reunin. Los siguientes pasos le ayudarn a lograr
reuniones productivas:
L. Prepare una agenda (quizs podr utilizar la agenda de la reu-
nin de arranque como ejemplo), enunciando el propsito de
Ia reunin, su duracin esperada, la lista de convocados, etc.
2. Notifique a los convocados cuando menos con una semana de
anticipacin para cada reunin.
3. Asegrese que en la reunin se cubran todos los tpicos men-
cionados en la agenda.
4. Documente las acciones y otras decisiones surgidas durante la
reunin.
5. Distribuya las minutas de la reunin a todos los invitados (no
slo a los asistentes).
6. Asegrese que las acciones, junto con el individuo responsable
de llevarlas a cabo, se registren en la agendapara la siguiente
reunin programada.
Administracin de variacones de costos,
programacin y recursos
Adems del desempeo tcnico, son tres las mediciones de desem-
Pco del gerente del proyecto: variaciones de costos, variaciones de
programacin y variaciones de uso de recursos. Vigile bien estos as-
l'rt'ctos y tcrrclr srs dedos sobre el pulso del proyecto.
 II

92 Curtis R. Cook Control del proyecto 93

I
I

Usando la informacin 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 Programacin yecto menos crtico, 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 situacin, y en colaboracin con el equipo, su trabajo prdida 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, disctalo . Modifique o reduzca el alcance del trabajo (sujeto desde luego
con el patrocinador, sin dejar de mencionar su recomendacin de ac- a un acuerdo con el cliente). Por desgracia, frecuentemente nos
cin correctiva. vemos forzados a tomar esta alternativa como ltima y poco
En algunos casos, el plan del proyecto tendr que revisarse si el deseable solucin. 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 terminacin. 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' neracin d lugar a un producto.
Hay tantas acciones correctivas para problemas esPecficos del Obviamente, algunas de estas acciones aumentan los costos. Si se
proyecto como problemas, por lo que una lista detallada de cmo "co-
agregan ms 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
aplicacin de ms 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 ms o diferentes recursos humanos a las tareas atra-
sadas, en especial aquellas que constituyen la ruta crtica. Sin
embargo, es necesario recordar que aventar recursos a una ta-
HOJA DE TRABAJO DE TAREAS DL.PROYECTGLOBUS OFFSITE AI416104
rea que est atrasada no necesariamente resuelve el problema.
Reconfigure el plan del proyecto de tal manera que las tareas Trea Entregable Ouin CndCI RI Gometrio
se lleven a cabo con una secuencia diferente o en paralelo. Adminstracn
del proyecto Varios
Aunque los riesgos aumentan al operar en paralelo, en ocaso-
nes esta accin resulta en una aceleracin del trabajo. Sin em- Reunin de
arranque
Agenda de
la reunin
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
organizacin que jerarquiza sus Proyectos de acuerdo a su con-
tribucin a los objetivos estratgicos, puede proceder "qui-
tndole a Pablo para darle a Pedro". Si es capaz de demostrar
que su proyecto es de ms alta prioridad y que sufrir debido Figura 5-2. Hoja de trabajo actualizada de las tareas del proyecto. (contina)
 ]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 terminain, las fe-
Tre Entregab.l Ouin cd6 Rel ,C,6rnntaii chas replanedas 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

Celebracin Dversn Sally

del equipo y lecciones
aprendidas
y el Equipo
25t6t04
Gontrol de cambios
Todo proyecto de cierta envergadura experimenta cambios de diseo
Terminar agenda Agenda Sally Sally enferma tcnico, programa, costos estimados, recursos y otros aspectos. sin em-
Posttte 21l5tO4 23t5t04 dos das 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 decisin
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 restriccin triple
externo sin tener cuidado.. .

Contratar Contrato Seth Godin 3t6t04

entrenador e)derno

Definir Contrato Bill McMurry 7t6to4

entretenimiento
Revisar Presentacin Figura 5-3. Control de los cambios.
presentacin 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 coordinacin comidas, Equipo 't7t6t04
de la reunin etc. clue ste no sufra las catastrficas consecuettiiui del dslizamiento
del
rlcance. Recuerde que el alcance del proyecto se define como
Evaluacin Evaluacin Seiichi el con-
tenido de trabajo
de la reunin 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 revisin, 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. Aprobacin o rechazo del patrocinador.
5. Documentacin 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 documentacin 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 --crame- reinar el caos y el proyecto estar en peligro de
fracasar o cuando menos de sobrepasar el presupuesto y el Programa.
Permtame 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 haban "colectado" para un gran proyecto de construc-
cin para una comunidad de jubilados que la empresa haba diseado
y que tuvo fallas durante el desarrollo del proyecto. Muchos de los do-
cumentos hacan referencia a cambios de diseo que se haban hecho
durante la construccin. Su responsabilidad consista en negociar el
efecto neto de estos cambios en el contrato con el principal contratista
de la obra y resolver cualquier disputa.
Estableci un dilogo con el contratista y encontr docenas de
cambios no documentados que haban sido introducidos por el gerente
de construccin de la empresa. Ninguno de ellos haba pasado Por un
proceso de control de cambios; por consiguiente, nunca se evaluaron
los impactos en el presupuesto y el calendario de la construccin. Sin
embargo, el contratista de la obra haba 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 haba planeado obtener de ese proyecto
desapareci a causa de los cambios no autorizados. Esto pudo haber
sido evitado con sentido comn, 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.
Administracin 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 habrn sido previstos y las respuestas estarn listas
para su implantacin. Habr menos sorpresas y menos labor de apa-
gar fuegos. Sin embargo, an con el proyecto ms simple, surgirn
algunas incgnitas durante el proyecto. Por esta razn,la actividad de
administracin de riesgos y asuntos debe ser una actividad continua.
Cul es la diferencia entre un riesgo y un asunto? En el Captulo 4
discutimos en detalle los riesgos, y a manera de revisin 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 planeacin 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 planeacin. 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 clculo 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 podran tener un impacto negativo en el
proyecto. Los asuntos se asignan a alguien para su resolucin 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 estn mejor equipados para manejar
las malas noticias cuando aparecen inevitablemente suceder
-como
tarde o temprano. Como se dice comnmente, Murphy est vivito y
coleando y lo visitar en sus proyectos- slo que no sabe cundo.
Contine involucrando al equipo en la administracin de riesgos y
rsuntos. Discuta los riesgos, los asuntos y los cambios en todas las reu-
rriones del equipo, para minimizar el nmero de sorpresas. Los miem-

98 Curtis R. Cook
bros del equipo son quienes estn ms cercanos al trabajo y, en conse-
cuencia, estn 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 administracin
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-
lcese a s mismo como una persona dinmica, creativa y gil. (Aquin
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.
Administracin del equipo del proyecto
La administracin del equipo se refiere a lidiar con otros individuos al
nivel personal, colaborando con el equipo para lograr los objetivos del
proyecto y simultneamente ayudando a sus miembros individuales a
alcanzar sus metas profesionales y personales. Y mientras ms peque-
o es el proyecto, ms difcil resulta esta labor, debido a que los inte-
grantes del equipo slo trabajan en l parte de su tiempo. Es un trabajo
difcil, un trabajo que en muchos casos no es intuitivo.
Cuando describimos la fase de planeacin, discutimos la impor-
tancia de seleccionar los recursos humanos apropiados para el pro-
yecto. Esto se refiere ms a seleccionar a la persona adecuada que a
evaluar su experiencia tcnica 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, adems de su competencia tc-
nica. Cuando los objetivos del proyecto, profesionales y personales
apuntan en la misma direccin,la administracin del proyecto se faci-
lita. Cuando existe descontento, es difcil que la gente ponga todo su
corazn y cerebro en el trabajo del proyecto.
Independientemente del tamao del proyecto o de que el equipo
sea de tiempo completo o de tiempo parcial, su administracin es una
de las actividades ms 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 administracin del equipo de
proyectos implica Iiderazgo, motivacin, espritu, resolucin de con-
flictos, toma de decisiones y una comunicacin constante.
II
El alcance de este libro limita la atencin que podemos darle al li-
derazgo y crame, es mucho lo que todos necesitamos saber cuando tra-
tamos de convencer a los dems de que quieran hacer lo que creemos
es lo correcto. una buena fuente de mayor informacin iobre la di-
mensin del liderazgo es el llbro Project Leadership de James p. Lewis.
(Vase la seccin de lecturas adicionales.) sin embargo, s echramos un
vistazo a tres aspectos importantes de la administracin de equipos
de conflictos, determinacin de expectativas a travJ d la
-manejo
constitucin del equipo y recompensas a los desempeos sobresalientes.
Manejo de conflictos
una de las tareas ms 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
situacin. En el modelo mostrado, el eie vertical est relacionado con
la asertividad o firmeza, tambin conocida como "salirse con la stJya",
mientras que el eje horizontal representa cooperacin, tambin 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 aspcto en cuestln,
rresionando su solucin con poca cooperacin o involucramiento de la
 I
100 Curtis R. Cook
otra parte. Cundo 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 competivo conduce a acusaciones de que
el gerente es un autcrata- lo que ratavez es algo bueno.
Aceptar. En el extremo opuesto est el enfoque de aceptacin. Esto
ocurre cuando el gerente del proyecto coopera totalmente con la otra
parte adoptando su propuesta de solucin. Este enfoque es apropiado
cuando la otra parte es el experto y su solucin es mejor. Tambin es
polticamente 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 "Evtalo y desaparecer" no era un gerente de proyecto.
No obstante, como estrategia de corto plazo es apropiada cuando la at-
msfera 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 enfre. En la arena
poltica, 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 informacin adicional.
Colaboracin. En esta estrategia, tambin llamada resolucin 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 dems. Esto casi siempre es posible en
proyectos pequeos, 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 ms efectiva de re-
solver un conflicto es por medio de la negociacin. proceso de to-
mar y ceder. En la negociacin,las dos partes estn -el
satisfechas de que
Control del proyecto
se han cumplido sus necesidades y ambas apoyan la decisin o resolu-
cin del asunto. No es que la negociacin sea fcil y en algunos casos,
ni siquiera deseable, tal como se discuti antes. Pero con una negocia-
cin hbil por cierto es algo que puede aprenderse- casi cual-
-que
quiera puede lograr sus objetivos. Es la negociacin siempre el enfoque
correcto? No, como ya se ha dicho. La toma de decisiones por consen-
so forma de enfoque de negociacin- consume ms 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, surgirn
problemas si el gerente "se empecina" y toma una decisin unilateral.
Estatuto del equipo. Un aspecto importante de cualquier enfoque que
asuma es el apoyo del equipo cuando se aplique dicho enfoque. Cmo
puede estar seguro de que contar con su apoyo? Una manera es desa-
rrollar un estatuto del equipo desde la primera reunin para planear el
proyecto.
El estatuto del equipo es otro trmino para las reglas de juego que
su equipo seguir cuando se rena por cualquier razn. Los elementos
del estatuto del equipo incluyen:
Etiqueta. El equipo debe decidir las reglas para llegar a tiem-
po, quedarse durante toda la reunin, permitir que los dems
hablen sin interrumpirlos, uso de palabras soeces, faltar a reu-
niones, perturbar, etc. Suena como una escuela de prvulos?
Bien,... en algunos de mis proyectos se ha necesitado este ni-
vel de detalle en cuanto al comportamiento adecuado. Usted
ser el juez de cunto es suficiente para su equipo.
Toma de decisiones y resolucin de conflictos. Cul 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 Quin puede convocar a una reunin? Es el gerente del
proyecto el nico autorizado para convocar a una reunin? As
suele ser, pero para equipos ms maduros usando un enfoque
colaborativo de toma de decisiones, cualquier miembro del
equipo central puede hacerlo y se espera que los dems miem-
bros respeten su decisin.
stos son slo 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 prdida 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 tambin es responsable de asegurarse que se
reconozcan los desempeos 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 preocuparn por usted se
sorprender de lo fcil que resulta entonces motivar a la mayor-y parte
de sus integrantes. Diferiremos para el prximo captulo la discusin 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 relacin de trabajo y un alto nivel de confianza con el
cliente, mientras que el otro es lograr su aprobacin 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 organizacin. Al enfocarse en el cliente, el gerente del pro-
yecto desarrolla las siguientes tareas:
o principal y sin 1, no nos pagarn.
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 planeacin del proyecto, formula el involu-
cramiento del cliente, las comunicaciones y el manejo de las
expectativas.
o Busca la aprobacin del cliente del plan del proyecto y los sub-
secuentes cambios al plan durante la ejecucin.
Existen diversos mtodos para mantener un enfoque en el cliente
y para los gerentes de proyecto exitosos, son un simple asunto de sen-
tido comn. No obstante, conviene reiterarlos:
o Conozca al cliente y establezca una buena relacin. Aprove-
che la oportunidad inherente de discutir las necesidadcs y
Control del proyecto 103
expectativas del cliente. Conozca la organizacin del cliente
leyendo la prensa especializada en negocios, buscando en la
Internet o simplemente preguntando.
. Establezca un dilogo continuo con el cliente. Esto va ms
all de la reunin para el reporte tpico 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
atencin lo que el cliente dice y enfquese en ello. Ms all de
la obvia conveniencia que representa construir una mejor rela-
cin, 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 relacin. Una relacin profesional bilateral con el
cliente del gerente del proyecto o punto de contacto es un re-
querimiento mnimo. La relacin puede ir mucho ms lejos,
convirtindose en un flujo de confianza mutua y buenas sen-
saciones entre las dos organizaciones.
Aprobacin final del cliente
A los ojos de muchos de los interesados, la aprobacin final del cliente
seala la conclusin del proyecto. Por supuesto que nosotros, los ge-
rentes de proyectos, sabemos que todava restan por hacer algunas
tareas administrativas y gerenciales, pero la aprobacin es el objetivo
Naturalmente, para obtener la aprobacin, 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-
lacin con el cliente y en manejar los cambios durante la ejecucin del
proyecto, las expectativas del cliente habrn sido satisfechas y la apro-
bacin formal ser fcil. Si no ha sido asi es probable que existan ex-
pectativas no cumplidas y sentimientos negativos. Supongamos que
tenemos una buena relacin y que los entregables concuerdan con lo
que el cliente esperaba ver.
En este punto, slo asegrese que se han satisfecho todos los re-
cluerimientos del proyecto y que los asuntos abiertos estn 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 cue sc ha cunrrlicl<l con todos los com-
 n

104 Curtis R. Cook

promisos. Una vez terminada la revisin, prepare un documento for-

mal de aprobacin para ser firmado por el cliente. Este documento de
aceptacin debe constar por escrito pues constituye la base para poder
facturarle al cliente el trabajo realizado.

Transicin 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 captulo 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 da de
-peroEl gerente del proyecto todava tiene algunos "que-
accin 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 tamao, 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 slo usan parte
de su tiempo. Pero tambin 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 ms 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

Cmo podemos beneficiamos de lo que aprendimos? Este captulo lo

equipar con algunas herramientas tiles para ayudarlo a enfocarse en
estas cuestiones.
Antes de discutir el "cmo 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 sensacin de finali-

zacin que nos embarga cuando alcanzamos el objevo, 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
sensacin de finalizacin. Como resultado, estas mismas per-
sonas estarn menos motivadas para dedicarse a desafos 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 tericos de la motivacin 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 desempeo. 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 todava estn o se sienten asig-
nados al proyecto continan "pellizcando" los entregables y
acumulando costos. Estas mejoras deberan en realidad ser el
principio de un nuevo proyecto, la versin "nueva y mejorada,,
de un producto o servicio, pero, como el viejo proyecto est tc-
nicamente vivo, el trabajo contina. 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 cdigo 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 tecnologa de la informaciry quizs no obtenga una aceptacin 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 imn para pe- la misma manera en que lo hara para un cliente externo.
queos detalles que slo estn perifricamente relacionados
con el proyecto. Tambin hay la posibilidad de que alguien UN MODELO FCILY RPIDO
pueda cargar su tiempo a la cuenta del proyecto abierto en vez
de contabilizarlo como un gasto administrativo beso de la
muerte en una organizacin de servicio.
-el
Se pierden las lecciones aprendidas. Finalmente, si un proyecto no se
cierra, no se recogern las lecciones aprendidas para ayudar a futuros
equipos de proyectos. Las lecciones aprendidas son uno de los me-
dios ms importantes para mejorar nuestro desempeo. 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 atencin en cmo hacerlO correctamente.
Empiece por plantearse las cuatro preguntas que se transcriben a con-
tinuacin. 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 aceptacin y aprobacin del resultado final. Firmada, si es
o Aprendimos algo?
posible, o si no, mediante un correo electrnico como mnimo.
o Hemos comunicado nuestro agradecimiento y reconocimiento? Evale qu tan bien se cumplieron las expectativas. Como un asunto
prctico, cmo puede medir la satisfaccin? Muchas organizaciones
Recuerde que usted y el patrocinador especificaron los criterios de usan una encuesta de satisfaccin del cliente, con lo que se conoce
xito y finalizacin en la etapa de inicio, por lo que usted puede saber como escala de Likert, para medir la satisfaccin en una escala de, por
si se lograron o no los objetivos. ejemplo, del 1 al 7. Si ha mantenido una buena relacin con el cliente a
travs de todo el proyecto, tal como se discuti en el Captulo 5, sabr
Modelo para cerrar el proyecto si el cliente est satisfecho con el resultado final.
Dmosle al cierre del proyecto una estructura, considerndolo como Ate los cabos sueltos. Esta es una categora especial para conside-
un modelo de tres pasos, tal como se muestra en la Figura 6-2. rar todos los pequeos detalles que requieran atencin al final del pro-
Entrega yecto. La Figura 6-3 muestra una lista de verificacin de cierre de
Recordar que discutimos la aprobacin del cliente como la ltima proyecto que es probablemente mucho ms 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
slo necesita asegurarse que el documento de aceptacin 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 podra haber sido manejado en forma un poco diferente, quizs
un poco mejor, si el gerente del proyecto y el equipo hubieran tenido
ms experiencia con el cliente, la tecnologa o la situacin particulares.
Capturar las lecciones aprendidas en el proyecto es una gran manera
de proporcionarles informacin a los equipos futuros. Al conjuntar las
lecciones aprendidas y ponerlas a la disposicin de otros, podemos evi-
tar tener que aprender de la "manera dura".
Existen varios mtodos 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 fcll y divertida de lograrlo consiste en combinar el ejercicio
con una celebracin del proyecto. Rena al equipo para unos bocadi-
llos y bebidas y circule entre ellos, hacindole 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 leccin aprendida de su expe-
riencia en este proyecto a un miembro de un equipo futuro,
cul sera?
se asombrar de las cndidas respuestas que surgirn cuando
acte de esta manera. se trata de lecciones reales aportadas cuando la
gente "se suelta el pelo", que podr usar de inmediato en la planeacin
de riesgos, integracin de equipos, planeacin y control de proyectos,
y construccin de relaciones con los clientes. Por supuesto que no que-
rr atribuir respuestas especficas d personas especficas.
Enfoque formal. En los proyectos grandes, el gerente del proyecto
probablemente necesitar ir ms all de este mtodo 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.
INFORMACIN PARA LA PREPARACIN DE DOCUMENTOS
NOMBREDEL IPREPARADOPOR lrcHRo
PROYECTO I I PREPARACIN
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 cdigo 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 liberacin 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 informacin de
soporte?
Se han notificado a los proveedores cualesquiera compromisos
pendientes?
D Estn enterados todos los interesados del cierre del proyecto?
o Se ha transferido el proyecto a operaciones y soporte?
D (Aada aspectos especficos de su proyecto.)
PERSONAL: INTERNO
a Se ha preocupado de que los miembros de alto desempeo 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 celebracin del proyecto?
o (Aada aspectos adicionales especficos de su proyecto)
ASUNTOS EXTERNOS
o se est aplicando un proceso para mantener la relacin con el cliente?
o Se les ha informado a los proveedores y subcontratistas el estado del
proyecto y las oportunidades futuras?
o (Aada aspectos especficos de su proyecto.)
Figura 6-3" Lista de verificacin del cierre del proyecto
 L12 Curtis R. Cook
Incluso en proyectos pequeos, 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 slo porque
est usando esta lista.
LISTA DE veRITIcRcIN DE LEccIoNEs APRENDIDAS
El propsito 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 hara diferente la siguente vezpa'a
evitar esta frustracin?
Cul fue la parte ms gratificante o profesio-
nalmente ms satisfactoria del proyecto?
Le ayudo el proceso de admnishacin de proyectos
justamente suficiente? Cul de sus tcnicas
funcion especialmente bien para usted?
Qu tcnicas resultaron frustrantes o difciles
para usted? Qu se podra hacer para mejorar
el proceso?
Asignamos las personas adecuadas a los papeles
del proyecto? (Considere la experiencia en
el asunto, las contribuciones tcnicas, el manejo,
la revisin y la aprobacin y otros papeles clave.)
Si no fue as, cmo podramos asegurarnos de
obtener las personas adecuadas la prxma vez?
Participaron efec{ivamente nuestros interesados?
Si no fue as, cmo podramos mejorar
su participacin?
Figura 64. Lista de verificacin de las leciones aprendidas. (contina)
Cierre del proyecto 113
PTANEACIO
r"gun. Respesta:
Faltaron los miembros o los interesados
necesarios a la reunin de arranque o a otras
reuniones? Cmo podramos evtar las ausencias
en el futuro?
tNfcro pEr p.RoYEcTo
ldentific nuestra definicin 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 podramos
estar seguros de capturar los requerimientos
necsarios en proyectos futuros?
ldentific nuestra definicin de requerimientos
entregables algunos innecesarios? Si as sucedi,
cmo podramos evitar esto en el futuro?
Captur adecuadamente el protocolo del proyecto
toda la informacin relevante para iniciarlo
exitosamente? Si no fue as, cmo podramos
hacerlo mejor en el futuro?
FLANH16N
Se delinearon y se comunicaron claramente todos
los papeles y responsabilidades de los miembros
del equipo y los interesados? Si no fue as, cmo
podramos haberlo hecho mejor?
Se dividieron en tareas al nivel apropiado
los objetvos del proyecto? Se cre una
estructura completa de divisin del trabajo?
Se formul el programa usando la EDT y se
comunic esta informacin al miembro del equipo
o al nteresado apropiado? Si no fue as, cmo
podramos mejorar este aspecto?
Se gener un presupuesto del proyecto usando
la EDT? Si no se hizo as, cul fue la base
para estimar el presupuesto del proyecto?
Cmo podra mejorarse?
Figura 64. Lista de verificacin de las lecciones aprendidas. (contina)
Ll4 Curtis R. Cook Cierre del proyecto 115

PLANEACION CIERRE
Fregunta Rs[sta,,:,:,,'::.:.:::,::':::::::;::t', Pign! Respust
Se identificaron y mitigaron los riesgos?
Podramos haber completado este proyecto sin uno Fue nuestra entrega al cliente una transicin tersa
o ms de los proveedores y/o subcontratistas? y fcil? Si no fue as, cmo podramos haber
Si la contestacin es afrmativa, explique cmo. mejorado este proceso?

Se aclararon a todos los proveedores y/o subcon- Capturamos las lecciones aprenddas 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
cmo podramos mejorar nuestros enunciados por equipos futuros?
de trabajo?
Celebramos nuestro xito y recompensamos
apropiadamente a los miembros del equipo?
Fue el proceso de asignacin de recursos internos
Si no lo hicimos, por qu no? Cmo podramos
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, cmo podramos mejorarlo?

CONTROL Figura 6-4. Lista de verificacin de las lecciones aprendidas.

Cumplimos con los objetivos de nuestro programa?
Si no fue as, por qu no y cmo podramos
Recicle la informacin til. lJna vez capturadas las lecciones aprendidas,
mejorar nuestro proceso de control del programa
en proyectos futuros? cmo podremos asegurarnos que estn 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 cmo podramos las lecciones aprendidas si no se usan. Permtame proporcionarle un par
mejorar nuestro proceso de control de costos de trucos que he aprendido en mi canera para superar este obstculo.
en el futuro?
Establezca un sitio intranet para las lecciones aprendidas. Si
Obtuvimos una retroalimentacin oportuna del usted trabaja en una organizacin de gran tamao, sta es una
equipo y el cliente sobre la calidad y puntualidad
opcin viable. Establezca el sitio e infrmele a todos los que us-
de nuestros entregables? Si no fue as, cmo
podramos mejorar el proceso en el futuro? ted sepa que estn 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 equpo como para deramente til para los gerentes de proyectos aprender de los
la gerencia? Fueron tiles para monitorear errores de los dems, estarn motivados para incorporar sus
el proyecto? Si no fue as, por qu no? resultados. Claro est, funciona mejor si existe una oficina de
administracin de proyectos (OAP), pero muy pocas organiza-
Qu funcion bien en el proceso de revisin
y aprobacin?
ciones han establecido OAPs. Si usted tiene la suerte de que
exista una OAP, este departamento cuenta con un archivo al da
Fue efectivo nuestro proceso para administrar de lecciones aprendidas y actualiza la metodologa (si la tie-
los cambios? ne) de la administracin de proyectos, para reflejar las mejores
prcticas derivadas de las lecciones aprendidas.
Enve correos electrnicos a todos los miembros del equipo.
Figura 64. Lista de verificacin de las lecciones aprendidas. (contina) ('olrro rrrninro, el gerente del proyecto debe enviar por correo
 1,r6 Curtis R. Cook
electrnico las lecciones aprendidas a todos los integrantes del
equipo del proyecto y a otras personas de la organizacin in-
volucradas en proyectos.
. El gerente del proyecto y los miembros clave del equipo de-
ben asistir a sesiones de planeacin de otros proyectos para
transmitir en persona las lecciones aprendidas. Esto funcio-
na muy bien. Cuando un nuevo equipo se rene 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 accin 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 ms. 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 consista en lograr un sistema que impidiera que nuestras
comunicaciones fueran escuchadas por los "malos". Esto, por cierto,
sucedi hace un par de dcadas.
Al principio del programa, la Fuerza Area y la Marina estaban
desarrollando tecnologas competidoras. Esto se hizo a propsito para
poder seleccionar la tecnologa ms promisoria e incorporarla al siste-
ma. Las primeras pruebas mostraron que uno de los enfoques tcni-
cos era superior y que estara listo anteJque el otro. Lo ms inteligente
que se podra haber hecho en ese momento era tomar la decisin de
cancelar el desarrollo de la tecnologa menos promisoria y seguir con
un solo enfoque. Pero esto no sucedi.
Pasamos a la fase de construccin de prototipos. se desarrollaron
y probaron ambos prototipos. Antes de eso habamos experimentado
que el desarrollo de dos enfoques paralelos se comera nuestro pre-
supuesto y causara problemas de recursos humanos, pero no aprendi-
Cierre del proyecto L17
mos de esa leccin. Uno de los prototipos (el de mejor tecnologa) era
superior, pero, debido al involucramiento de la poltica, se permiti
que ambos programas continuaran.
Qu sucedi como resultado de no aplicar esta leccin 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 Area usaban diferentes siste-
mas y en algunos casos ni siquiera podan comunicarse entre ellos. La
triste realidad es que tuvieron que intercambiar informacin Por me-
dio de discos blandos antes de iniciar las operaciones del da. Como
resultado de este fracaso, el Secretario de la Defensa descontinu uno
de los programas slo despus de mucho sufrimiento, desper-
-pero
dicio de dinero y dificultades operativas. En la actualidad, el problema
ya est arreglado, pero hubiera sido todo mucho ms fcil si se hubiera
aplicado antes la leccin aprendida.
Celebre. La tarea final del gerente del proyecto consiste en recomPen-
sar a los miembros de su equipo y proceder a una pequea celebracin
para proceder al cierre del proyecto y la disolucin del grupo' Es ex-
trao, pero algunos gerentes de proyectos no celebran sus xitos ---casi
como si fueran alrgicos a la diversin. En dnde est escrito que la
administracin de proyectos tiene que ser desagradable? Salga y cele-
bre cuando logre algo que haya valido la pena. Es tambin una buena
prctica en la vida.
Proceda al cierre
Ya hemos discutido esto como una necesidad humana bsica. La cele-
bracin del proyecto, el ejercicio de lecciones aprendidas y unas cuan-
tas palabras del patrocinador y del gerente del proyecto sirven muy
bien a este propsito. El patrocinador cebe hacerle sabe al equipo lo
mucho que se aprecian sus esfuerzos y lo mucho que el proyecto influi-
r en la organizacin.
Gomunique los logros
Hay una vieja cancin folclrica con una letra que dice ms o menos
lo siguiente: "No puedes ser un faro si tu luz no brilla". No importa lo
bien que se hayan desempeado los miembros del equipo si usted no
se lo cuenta al mundo. Recuerda la discusin sobre las necesidades
de estinra cit' la nrayora 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
tcnicas simples:
' Publique los resultados del proyecto en la revista o boletn de
la empresa, completos y con fotografas.
' Publique proyectos notables redactando artculos para ser so-
metidos a la consideracin de los editores de revistas y pe-
ridicos especializados. Por ejemplo, el project Management
Institute publica en forma rutinaria los resultados de proyectos
importantes.
Pdale al patrocinador que hable sobre el proyecto en la si-
guiente reunin pblica de la empresa.
' si su compaa tiene transmisiones internas en un sistema de
video, pdale al patrocinador que reconozca el esfuerzo del
equipo en ese foro.
Demuestre su apreco a todos los involucrados
Finalmente, demustrele 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 celebracin del proyecto (por favor, no lo llame ,,postmor_
temz quin 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 despus reljese, circule y, como
ya se dijo, capture conversacionalmente unas cuantas leccio-
nes aprendidas. Acurdese de divertirse. Aunque se d el caso
de que su organizacin no permita celebraciones de proyectos
pagadas por la empresa, los mejores gerentes de proyeclos las
hacn por su cuenta.
' Escriba cartas. Tmese tiempo para escribir cartas de agrade-
cimiento a los supervisores de los miembros del equip, con
copia para el individuo en cuestin. Esta tcnica simpl persi-
gue dos propsitos. Primero,le inyecta al individuo una bre.ru
dosis de estima. Segundo, le proporciona a sus jefes, quienes
probablemente son gerentes funcionales, algo para aadir al
reporte de desempeo de su subordinado. Se lo agradecern.
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 desempeo y trabaje con los dems
para darles una retroalimentacin honesta y sugerencias para
mejorar. Esto es tambin un regalo.
Transicin a operacones, 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 verificacin antes de pasar a su siguiente asignacin es reasegu-
rarse que el entregable y el cliente estn siendo apoyados por la
divisin de operaciones de la empresa.
Cmo hacer esto? Si sta es la primera vez que surge el tema a
colacin, 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 planeacin
y control.
Quizs no asistieron a todas las reuniones, pero cuando apareci
en la agenda el tema de apoyo postproyecto por primera vez, deberan
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-
cin y que no existan cabos sueltos. Su mayor desafo consistir en
lograr que el cliente se acostumbre a no contar ya con la atencin cons-
tante que usted le ha estado dando y prepararlo para la clase de
contactos y apoyos que recibir despus 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 despus de la ejecucin de un proyecto. La mayora de las
organizaciones maneja muchos proyectos para clientes de larga rela-
cin 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 estn totalmente seguros que
lr trilrrsicir'rrr st' ha llevado a cabo completamente y sin problemas, es
120 Curtis R. Cook

tiempo de levantar su tienda de campaa y pasar al siguiente proyec-

to. Buen trabajo!

Administracin de proyectos mltiples

usando los principios de Los cuatro pasos indispensables para adminis-
trar proyectos con base en una administracin justamente suficiente, sin
duda podr salir triunfante en el manejo d proyectos nicos. pero,
desgraciadamente, la mayora de nosotros manejamos ms de un pro-
yecto al mismo tiempo. C9mo podemos lidiar con esta sobrecarla y
malabarear exitosa y simultneamente muchos proyectos? ste es t
Manejo de proyectos
tpico del captulo final
ayuda para una situacin-por
lo que le conviene ieeilo como una gran
muy desafiante.
mltiples y sobrecarga
de proyectos

ejanos estn los das 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 simultneamente proyectos mltiples. Qu po-
demos hacer en la prctica para copar con esta situacin? Tenemos que
encontrar la manera de manejar esta sobrecarga o correremos el riesgo
de quemarnos, frustrarnos o ser despedidos.
Este captulo le proporcionar las herramientas y tcnicas simples
para manejar varios proyectos al mismo tiempo y hacerlo bien
poco de administracin, fijacin de prioridades y aprender cmo decir
-un
no de buena manera. Estas tcnicas bien conocidas contribuyen a lo-
grar un nivel de estrs ms bajo y en ltima instancia resultan en una
mejor administracin de proyectos en toda la organizacin.

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 discusin, 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 ms reciente) han incrementado la carga de
trabajo de sus empleados. Esto se debe primordialmente a la intensa pre-
sin competitiva en casi todos los pases del orbe, acoplada con la presin
de los accionistas y del mercado para lograr un desempeo 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 jubilacin,
seguro de enfermedades, atencin dental, cuidados de la vista, seguro
de vida, seguro de incapacidad, vacaciones con goce de sueldo, etc.
Slo los cuidados de la salud han crecido dramticamente cada ao
durante varios aos y no muestran indicios de disminuir. Como resul-
tado, la presin sobre la gerencia para reducir los costos de la mano de
obra directa, con sus costos indirectos asociados, ha sido muy intensa.
En compaas de bajo crecimiento, la cantidad de despidos ha sido
dramtica. 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 compaas 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 presin de primera mano. Para mantener o incrementar la partici-
pacin de mercado, los productos y servicios de nuestra compaa
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 estn basadas en el mejor valor mejor solucin
-la maduro,los
tcnica 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 administracin
de los costos.
La consecuencia de todo esto es que la gerencia es renuente a aa-
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 ms responsabilidades que las que tenan en "los buenos viejos
Manejo de proyectos mltiples... 723
tiempos". Necesitamos algunas herramientas prcticas para ayudar-
nos a manejar nuestras crecientes cargas de trabajo. Por s misma, Ia
adopcin de la administracin de proyectos es una manera de hacer
ms con menos. Los equipos de proyectos son ms eficientes y efecti-
vos que los equipos funcionales para manejar el trabajo de proyectos.
Suponiendo que usted utilice las tcnicas descritas en este libro para
administrar los proyectos individuales, qu otra cosa puede hacer pa-
ra ayudarlo a malabarear proyectos mltiples y un programa sobre-
cargado?
Es posible aplicar algunas tcnicas simples para que primero re-
conozca y despus maneje la sobrecarga. El enfoque de justamente lo
suficiente no est basado en softwares complicados diferentes a los que
casi todos nosotros usamos codianamente. Con un block de notas au-
toadheribles y una evaluacin honesta de la sobrecarga, usted podr
aplicar este marco de referencia prctico para administrar su tiempo
sus proyectos. Estas tcnicas funcionan- depende de usted que
-y
las lleve a la prctica.
La interconexn de todo
El primer paso para manejar proyectos mltiples es darse cuenta de
que sus proyectos estn realmente interconectados. Durante aos,
los que nos dedicamos al negocio de la educacin en la administracin
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 administracin de un portafolio
en muchas organizaciones.
El tratamiento detallado de la administracin de portafolio- o
programas mltiples- queda fuera de los alcances de este libro, pero
podemos aplicar algunos pasos de sentido comn que nos ayudarn a
manejar nuestra carga de trabajo desde la perspectiva de que casi todo
lo que hacemos est relacionado con algo ms 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 cr ractcrsticas:
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 slo tienen en comn 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 relacin entre proyectos.
Dependientes
En este escenario, los proyectos estn 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 estn 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 mltiples... 125
o Los proyectos pueden tener una relacin de dependencia con
otro proyecto. Por ejemplo, quizs la nueva tecnologa que se
est desarrollando en el proyecto A se usar en el proyecto B.
Si A se retrasa, B tambin lo har.
o Los proyectos puede tener una fuente comn 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 ms de los proyectos estn 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 situacin realmente
complicada. Prevalecen las siguientes condiciones:
Figura 7-3. Proyectos interdependientes.
::,,
r
,, ,,,ii1iii| ,,,,,,,',,,,',,,,,,,,,,,,,
Las tareas entre los proyectos estn relacionadas. En la Figura
--------D D.i.,iii.iii.
7-3,puedeverse que A'2 y 8L estn relacionadas Podra ser una
: :':;:':':':
relacin fsica, una dependencia de recursos, un punto de revi-
sin cosas. Quizs A2 es una tarea de colar cimien-
tos de-muchas
concreto para una cancha de bsquetbol y la tarea BL es
es la superficie, el proyecto B es la construcciny 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 situacin es compleja y difcil de manejar, y por lo general
requiere un enfoque ms 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 ls 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 sensacin de concienti-
zacin y el xito es ms probable.
Paso 1.. Liste todos sus ptoyectos. El primer paso consiste en identi-
ficar su carga de trabajo actual. Si todava no lo ha hecho, complete una
hoja de trabajo de tareas para cada proyecto, pero mantngalo 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 continuacin, transfiera el nombre de cada proyecto a una nota
adherible y la fase o etapa en la que est actualmente el proyecto (ini-
cio, planeacin, 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 fsicamente las notas enfrente de -lo
usted. Incluya la
informacin que se muestra en la Figura 7-5.
| ,;tlt.

Pftro;
Mi papf; Prloridad: '

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

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

,:,, iir; :':'.:',.,.,.:.:'::]

Figura 7-5. Nota adherible.

Figura 7.4. Proyecto maestro.
Cmo podemos tratar todos nuestros proyectos y tareas de la
misma manera sin invertir en softwares o sistemas costosos? Resulta
que la respuesta es ms fcil de lo que se imagina.
Ginco pasos para manejar
la sobrecarga de proyectos
La ayuda est en camino. Los cinco siguientes y fciles pasos lo ayu-
darn 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 ms de sus cinco o seis principa-
les proyectos. Operaremos bajo el Principio de Pareto conoci-
-tambin
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.acin del proyecto. Si no
r28 Curtis R. Cook Manejo de proyectos mltiples... 129

ha usado la hoja de trabajo de tareas, preprelas 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 planeacin. En este punto, quizs experimente una sensacin
interesante sobre su manera de ver la carga de trabajo.
En las ciencias de la decisin se habla del fenmeno mr"ty conoci-
do de que la estructuracin de un problema constituye la mitad de su
resolucin. Cuando se trabaja con sobrecarga de proyectos, es posible
beneficiarse de este mismo efecto. El slo hecho de considerar los si-
guientes pasos reduce la sobrecarga a un tamao manejable. Algunas
veces, el trabajo que todava no hemos comenzado se convierte en
nuestra imaginacin en una labor de enorme magnitud. Al sacarlo a la
luz vemos su tamao real y los verdaderos desafos.
Un segundo punto en la identificacin del siguiente paso en cada
uno de sus proyectos principales consiste en determinar con exactitud
qu se necesita hacer a continuacin. 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 rpidos". Usando los siguientes linea-
mientos, identifique cules de los pasos identificados podran resultar
en las ganancias ms inmediatas. Use el enfoque de Pareto: Entre las ta-
reas que ha identificado, vea cul es el20% que de realizarse,le dara un
empuje sustancial inmediato a sus esfuerzos para controlar la sobrecarga.
1. Se lograr que avance el proyecto con una pequea inversin
de tiempo?
2. Est el proyecto cerca del cierre?
3. Est detenido porque necesita una decisin o debido a la falta
de claridad?
Si la respuesta a cualquiera de estas preguntas o a todas es afirma-
tiva, colquelas 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 despus de lograr los xitos rpidos de la mezcla (sabemos

3. Estos son una ilusin 1. Ataque stos

primero muy
-no importantes
pero urgentes.Se
-
importantes y
1 comen su tempo urgentes

HI

4. Lo que hacemos 2. Estos son los

cuando nos siguientes todava
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 mltiples... 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 grfica o en su computadora, usando una herramienta corrro t'l
penso que no son tan importantes como cremos al princi- outlook de Microsoft. Personalmente uso la funcin de lista de trrcas
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- aaden o se eliminan tareas. He visto a otros usar una pizarray un plu-
triz para aclararlo. mn. Otros ms prefieren un documento Word o una hoja de clculo
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. pecficos, podr discutir lo que habr que sacar de la lista si se aade
Abquese primero a las tareas del cuadrante 1 pasos ms otro proyecto nivel discusin completamente diferente que las
-los que est
importantes y urgentes. Incorprelos a la lista de prioridades -un que adeveces
frases emocionales nos vemos obligados a decir cuando
desarrollando. Despus, idenfique los pasos importantes del cuadran- estamos sobrecargados y se nos enfrenta a ms trabajo. LaFiguraT-9
te 2 que no sean tan urgentes. Si ignoramos stos, muy pronto pasarn muestra una tabla que despliega la carga de trabajo de una persona.
a ser crticos. 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
pequeas 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 electrni-
cos que a nadie interesan, o quizs navegamos por la Red Mundial. Si
usted gasta algo de su tiempo en el cuadrante 4, realmente necesita
estudiar administracin del tiempo.
Cuando haya terminado con este proceso de jerarquizacin, 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 ms antes de que proceda a la accin. 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 cul es su carga
de trabajo para poder sostener una discusin racional.
Figura 7-8. Pizarra de proyectos y siguientes pasosatriz.
r32 Curtis R. Cook

Ntese en la FiguraT-9 que se ha agregado al calendario un tiem- Diario de trabajo (o calendario Outlook)
po de reposicin el jueves. Es tan importante incluir un colchn 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 ms: Asegrese de incluir en el calendario los trabajos Folleto 1. Obtener oportunidades de entre-
no relacionados con el proyecto, pues si usted es como la mayora 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, quizs deba considerar una lista con- miento
solidada de todos los proyectos y otros trabajos que requieran de su Metas 4. Reunin 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 negociacin a medida que Lunes Martes Mircoles Jueves Viernes
se le presente ms trabajo en su ya sobrecargado programa.
La siguiente lista resume los cinco pasos fciles para manejar la Reunin con #4
Cita con
Reunin #2 proveedores Revisin
sobrecarga de proyectos y malabarear proyectos mltiples: Mdico
del calen-
sobre Planeacin
1. Liste todos sus proyectos. problemas #3 con el
dario de
44 Tiempo de
personal entrena-
2. Identifique el siguiente paso de cada proyecto. reposicin
miento
3. Encuentre los "xitos rpidos".
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 dems tcnicas de este libro, estos pasos verdadera-

mente funcionan. En la primera ocasin en que su jefe le hable de una
Smna 1 $emana 2 Smana 3
nueva y gran "oportunidad" y pueda sostener una discusin racional
basada en la demostracin de su carga de trabajo, sentir que quizs PryectoA 16 hr ,10hr..
,-
'
:

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

Una rpida historia ms 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 divisin
Suprvisin
::)
l0hr
'' 10 hr 10 hr,

haba renunciado inesperadamente y como resultado, se descubri que Reportes ,','3hr :

,5 hr 3hr
muchos de los proyectos de su grupo tenan defectos; algunos estaban Yf65 ', 5 h'1, 5 hi' ,!i
, :: ,$ f:: :

atrasados, otros haban sobrepasado el presupuesto y otros ms no es- rrr-, 42hr , 52h 52 hr
taban logrando sus objetivos tcnicos. Se me pidi ayudar y aplicar el (Dej ce lai cifras san las que digan no n vez d usted)
contenido de este libro a dichos proyectos, conducir entrenamientos y
colaborar con la divisin para poder controlar todos esos proyectos.
Otras malas noticias eran que ya tena una considerable carga de tra-
bajo y no tena tiempo para esta tarea adicional. Figura 7-'t0. Resumen
134 Curtis R. Cook

Las buenas noticias ean las siguientes: Como siempre lo hago, es-
taba usando las tcnicas de este libro con base diaria. pr ende, .r rre,
de necesitar hacer exclamaciones de que no me era posible absorber
ms trabajo, abr mi lista de tareas (que mantengo rigurosamente ac-
tualizada en outlook) y d jefe y yo tuvimos un aiatgo constructivo
sobre qu proyectos podran asignrsele a otros, cuis podan sus-
penderse por el momento y cules ya no tenan una alti prioridad.
Excelente discusin sin sentimentalismos y se realiz el tratajo nece-
sario en la divisin hermana.
una vez ms, para cerrar, lo invito a poner en accin estos pasos
Glosario
simples. obtendr mejores resultados y podr controlar sus proyctos.

T-
F
L ste glosario contiene una gran variedad de los trminos usados
en la administracin de proyectos, muchos de los cuales no aParecen en
Los 4 pasos indispensables para administrar proyectos. Los lectores que se
involucren en proyectos ms complejos en los que se use la jerga co-
mn en este campo, encontrarn todas las definiciones necesarias.
Accin correctiva. La accin necesaria para corregir una variacin 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 trminos
actiaidad y tarea se usan indistintamente.
Administracin del tiempo. El conocimiento necesario para garanti-
zar la finalizacin del proyecto ---<onsistente en definicin de tareas,
secuencias, estimacin de sus duraciones, desarrollo del programa y
control del mismo.
Administracin de proyectos. Definida informalmente como "hacer el
trabajo a tiempo, en presupuesto, de acuerdo a las especificaciones".
Una definicin ms formal es "la aplicacin de conocimientos, habili-
dades, herramientas y tcnicas a las actividades del proyecto, para qrre
satisfagan o excedan las necesidades y expectativas de los interesados
en el proyecto".
Administracin 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 estndares de calidad.
Cambio. Una alteracin de cualquiera de las caractersticas del pro-
yecto.
Cambio en el proyecto. Una modificacin aprobada de un elemento
del trabajo del proyecto.
Ciclo de vida del proyecto. Un conjunto de fases por las cuales trans-
curre el proyecto. Ntese que el nmero de fases y su divisin en tareas
dependen de la metodologa usada. El ciclo de vida de la administra-
cin justamente suficiente de proyectos consiste de inicio del proyecto,
planeacin del proyecto, control del proyecto y cierre del proyecto.
Cierre del proyecto. Un proceso que da lugar a la aceptacin 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.
Colchn. Tambin llamado flotador. La cantidad de tiempo que una
tarea puede retrasarse desde su inicio sin afectar a la fecha de termi-
nacin del proyecto.
Compresin. Accin usada para disminuir la duracin de una acti-
vidad de la ruta crtica, por medio del aumento de aplicacin de re-
cursos.
Contrato. Un acuerdo obligatorio y firmado entre dos o ms partes que
establece los requerimientos de los productos y servicios que debern
proporcionarse.
Descripcin de actividad. un nombre que identifica claramente una
actividad cpn un elemento de la EDT.
Diagrama de red. Un despliegue esquemtico de la relacin secuen-
cial y lgica de las tareas de la EDT.
Duracin. La cantidad de tiempo consumido en una tarea o en el pro-
yecto, ya sea planeado o real. La duracin puede expresarse con o sin
la inclusin del tiempo dedicado a no trabajar en el proyecto.
Glosario I r;'
Duracin del proyecto. El tiempo transcurrido desde la fecha clt' irri
cio del proyecto hasta la fecha de finalizacin.
Entregable. Un producto o servicio tangible que satisfaga uno o nris
de los objetivos del proyecto.
Estimacin. Evaluacin de todos los elementos de costo de un proyec-
to, tal como se define en el alcance.
Estimacin actualizada. El pronstico de fechas de inicio y terminacin,
horas de trabajo y costo, que se hace en cualquier momento despus
de haber sobrepasado la fecha de la lnea base.
Estimacin 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 finalizacin. El valor (expresado en dlares y/u horas)
obtenido como evaluacin realista del costo una vez terminado. Toma
en cuenta los costos reales ms los costos proyectados y constituye una
expresin del esfuerzo total del proyecto.
Estrategia. tln marco de referencia que sirve como gua para las op-
ciones que determinan la naturaleza y direccin necesarias para alcan-
zar un objetivo.
Estructura de divisin del trabaio (or). Descripcin de las acvidades,
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 definicin ms 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 debern rendir cuentas de su desempeo, tal como se
detalla en el plan del proyecto.
Estudios de factibilidad. Los mtodos y tcnicas usados en el anlisis
de los datos tcnicos y de costos para determinar el potencial econ-
mico y la vala prctica de un proyecto.
Evento de riesgo.I-Jn suceso pueda afectar negativamente al proyecto.
Expediente del proyecto. Thmbin llamado archiao del proyecto. La
localizacin fsica de toda la documentacin especfica del proyecto,
incluyendo el protocolo, el plan, los reportes de avances y el contrato
cuando existe. Puede ser total o parcialmente electrnico.
138 Glosario
Factores crticos para el xito. Los factores necesarios para garantrzat
el xito del diseo, desarrollo e implantacin de un proyecto. Se basan
en el punto de vista del cliente del proyecto.
Fecha real de finalizacin. 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. Vase colchn.
Formacin 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.
Grficas de Gantt. Representacin grfica del programa de un proyec-
to que muestra cada trabajo como una barra cuya longitud es propor-
cional a su duracin. Las barras aparecen en filas e indican los tiempos
de inicio y finalizacin de las tareas, as como las yuxtaposiciones con
otfas tareas.
Impacto. La prdida 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 informacin 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. Informacin 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 atencin.
Lnea base. Un plan del proyecto con aprobacin gerencial fijado en
un punto especfico 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 seo del
equipo del proyecto.
Miembro del equipo. Cualquier individuo que reporte a tiempo com-
pleto o parcial al gerente del proyecto, responsable de algn aspecto
de las actividades del proyecto.
Objetivos del proyecto. Descripcin de los resultados especficos que
el proyecto intenta generar. Los objetivos de un proyecto deben ser
especficos, medibles, acordados, realistas y con restricciones de tiem-
po. (EMARR)
Organizacin 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 dbil. En una matriz fuerte, el gerente del proyecto
ejerce ms control, mientras que en una matriz dbil, el poder recae en
el gerente funcional.
Organizacin funcional. Cualquier grupo externo al control del ge-
rente del proyecto, responsable de tareas en la estructura de divisin
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 decisin final del proyecto.
Plan del proyecto. Documento formal y aprobado usado para admi-
nistrar y controlar las tareas y actividades del proyecto.
Planeacin de contingencias. Proceso de identificacin y planeacin
de las respuestas apropiadas que debern adoptarse cuando un ries-
go ocurra en la realidad.
t40 Glosario
Planeacin de recursos. Determinacin de los recursos (humanos, equi-
po, materiales) necesarios y en qu cantidades , para ejecutar las tareas
del proyecto.
Planeacin del proyecto. Identificacin de los objetivos, tareas, pro-
grama/ recursos/ costos, riesgos, comunicaciones y otros elementos ne-
cesarios para completar un proyecto.
pnox@ Guiile.Iniciales en ingls del cuerpo de conocimientos de la
administracin de proyectos. Es un trmino inclusivo que describe
la suma de conocimientos en la profesin de administracin de pro-
yectos, tal como la describe el Project Management Institute (PMD.
Presupuestacin. Parte de la funcin de planeacin y mecanismo de
control de un proyecto.
Presupuesto. Estimacin de los fondos planeados para sufragar el pro-
yecto o un lapso de tiempo especfico en el futuro.
Presupuesto del proyecto. La cantidad y distribucin 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 propsito
especfico.
Proceso de administracin de cambios. Conjunto de tareas o procedi-
mientos establecidos para garantizar que los cambios son revisados,
aprobados o rechazados con una actualizacin de la lnea base.
Producto. Trmino 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 tambin tienen
fechas de inicio definidas, pueden durar aos o indefinidamente.
Programa del proyecto. Representacin grfica de la prediccin de ta-
reas, referentes, dependencias, requerimientos de recursos/ duracin
de las tareas y fechas lmite.
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
Programacin. Llamada tambin calendarizacin. 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
influirn en la ejecucin del plan.
Protocolo del proyecto. Llamado tambin estatuto del proytclr. lrs r'l
formato entregable del proceso de inicio. Documento que dcst'ril'r' rlc
manera concisa el proyecto, anuncia la designacin de su gercntt', Irro
porciona la autoridad organizacional para aplicar recursos al proyt'. trt
y otorga la autoridad para proceder con la planeacin.
Proyecto. Cualquier trabajo con un inicio y final definidos con olyr'lit,u;
especficos y bien definidos que, cuando se alcanzan, identifican lr f irr,r
lizacin.
Referente. IJn suceso o una tarea con duracin cero que no requiert'
recursos, usada para medir el avance de un proyecto y representar la
finalizacin o inicio de un esfuerzo para generar un entregable.
Reporte de avance. Reporte que compara el avance real con la lnea
base actualizada y aprobada.
Reporte de estado. Reporte generado a intervalos peridicos para pro-
porcionar informacin del proyecto.
Reserva gerencial. Cantidad de tiempo o fondos apartados para con-
tingencias.
Resolucin de conflictos. El proceso de bsqueda de la solucin de un
problema.
Restricciones. Factores que limitarn las opciones del equipo de ad-
ministracin del proyecto ejemplo, un presupuesto predefinido,
-por
fechas lmite, alternativas tecnolgicas o acciones legislativas.
Retroalimentacin. Informacin extrada de un proceso o una situa-
cin, usada para controlar, planear o modificar de inmediato las en-
tradas del proyecto.
Riesgo. Un evento o condicin que, de ocurrir, podra tener un efecto
adverso sobre los objetivos planeados. (Nota, el pvtsox Guide menciona
que el impacto puede ser positivo o negativo.)
Ruta crtica. Una rrrta de secuencias de actividadcs en un programa de
red, tltrt'rt'rrt'st'nt.r lir clurircitin nrs larga clc tttr proyt'c'to. Ctralquicr
't42 Glosario
falla en una de las tareas de la ruta crtica aumenta la duracin del
proyecto, a menos que se apliquen acciones correctivas.
Solicitud de cambio. Una peticin formal por escrito para hacer una
modificacin a algn elemento del plan del proyecto o a las especifi-
caciones.
Suposicin. Algo que se percibe como correcto en el momento de
expresarlo.
Tarea. Vase Actiaidad.
Tcnica de revisin y evaluacin de programas (prnr). Tcnica de
programacin de proyectos orientada a las tareas, usada para esti-
mar la duracin total del proyecto cuando existen incertidumbres en A valor subyacente de
los estimados de las actividades individuales. El pnr usa duraciones
Acciones correctivas
calculadas con base en los promedios ponderados de los estimados
definicin,135
optimista, pesimista y ms probable. Con el uso del PERT, la fecha de
finalizacin del proyecto puede fijarse en trminos probabilsticas y para problemas de ProYectos,
los intervalos de confianza pueden definirse de acuerdo a las desvia- 91-94
ciones estndar de las tareas de la ruta crtica. para variaciones, 87, 89-90
Aceptacin
Variacin. La diferencia entre los resultados planeados y los reales, de riesgos, TT
expresado con la frmula V : P - R. Una variacin puede ser positi-
del proyecto, 108-109
va o negativa. Aceptacin enfoque de (manejo
de riesgos), 99-1-00
Actividad, definicin de, 135
(Vase tambin Tareas)
Administracin de ProYectos
de proyectos mltiPles (Vase
Administracin de ProYectos
mltiples)
como Proceso, 18-19
definiciones de, 20, L35
ejemplos de exceso de,24-27
mltiples como Proceso, 4-5
pasos en Ia,17-19
software parala,59-61
valor aadido por La,26
valrrr dc la,20-24
lndice analtico
La,13-L4
Administracin del tiemPo, 135
(V ase tambin Programacin )
Administracin/manejo de
riesgos, 23,76-78
definicin,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
definicin,135
deslizamiento del,22,
83,95-96
Aprecio, 11.8-119
Aprobacin del ProYecto, 108-109
Archivo del proyecto, 35-36,
L37
Arranque del proyecto, 29, 3I-35
Arranque, reunin de, 51., 53-56
Asignacin de recursos, 47,59-62
Aspectos
definicin, 97-98
maneio de los,97-98
 1,44 Indice analtico
ndice analtico 145

que afectan a la programaciry Cierre del proyecto,1,36 (Vase

62-63 durante la fase de control, Dilogo con el cliente, 103
tnmbin Fase de cierre)
Autoridad,21,34 95-97 Disminucin del alcance, 92-93
Clientes
Avances,/estado del proyecto planeacin de los, 47 -48 Duracin
decisiones de compra de los,
comunicacin de los,90 1,27_123
tcnicas avanzadas para ef definicin,136
euniones sobre los, 90-91 81-84 del proyecto, 136
comunicacin con los, 89,90
Avances, reportes de, 87, Bg,'J.4'1. Convergencia de rutas, 73-7 4
necesidades y expectativas de E
Correos electrnicos, LL5
B Ios,22,1,09
Costos EDT,55, 57-59,63
Cdigo de cargos, 108
Beneficios, costos de los, 12I-IZ2 clculo de,75 EDT grfica,55,57-58
Colaborativo, enfoque (manejo
de beneficios para Ejecucin del trabajo, 1.7, L8
c de conflictos), 100
Colchn,definicin de, 136
empleados, L22 EMARR, objetivos, 4L-42, 139
de variaciones,g2-94 Entradas,29
Cabos sueltos, 109-110 (Vase tambin 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
definicin,136
131-133 Compresin del programa, D del paso de planeacin, 49
software para crear ef definicin,136
Decisiones por consenso, 100-102 en el protocolo del
63,65-66 Comunicacin
Decisiones, toma de, proyecto,42
Cambios con el cliente, 87,89-90
por consenso, 100-102 protocolo del proyecto
definicin, 135 cuando se aplica presin 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 tcnicos,89 actividades del, en la fase de
Cambios en el proyecto, definicin, equipo para la, 101
de logros, 90-97,117 control,8T
735 (Vase tambin Control y estructuracin de
del estado del proyecto, administracin del, en la fase
de cambios) problemas, 127-128
80, 90-91 de control, 98-L02
Camisetas,38,40 Descripcin de actividades, 136
memorando de avances del comunicacin y tamao
"Campen" (V ase patrocinador Descripcin de la EDI 55,57-59
proyecto,8L del,80-81
del proyecto) Desempeo,22,23
planes de,47 comunicaciones en el, 78-83
Carga de trabajo, despliegue de medidas clave del, 91-92
retroalimentacin, L4L confianza y respeto eneL,87,89
la, 131-133 PERT (Vase Tcnica de
sobrecarga de,121, desarrollo del plan del
Cartas de agradecimiento, 11.8-119 revisin y evaluacin del
tcnicas avanzadas de proyecto por parte del, 99
Celebracin, 79, I17 -1Ig programa) en la administracin de
planeacin de la, Z8-g3
Certificacin, programas de, 12-1,3 tcnico, administracin 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 planeacin
definicin,136 Desempeo tcnico, del,107
de contingencias)
Cierre, 19,22-23 administrac in del, 7 3-7 4 formacin de la identidad
Contrato, definicin de,'1.36
necesidad del,177-178 Deslizamicrrto dt'l ir lcancc, del,38, 40,I38
Control de cambios,22
sensacin de,707 9,66,8022, U3, 95-9(r formacin del equipo central,
como actitud mental,82
I)t'sviacitin t'stiirrtl.rr; 711, 7,1 50-51
 746 Indice analtico ndice analtico t,t7

lecciones aprendidas
enviadas por correo
electrnico 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
Estimacin ascendente, 1.37
Estimacin presupuesta ria, 75
Estimaciones rinicas, 70-77, 73-7 4
Estimados actuales,
definicin, 137
Estimados/estimacin
actuales, 1.37
ascendentes , 75, 737
de programactn,70-73
definicin. 136
descendente s,74-75
en la finalizaci6n,737
niveles de precisin
en los,74-75
presupuesta rios, 7 4-7 5
Estrategia, definicin, 137
Estructura de la divisin del
trabajo (EDT), 47,737
cantidad de detalles enla, ST
creacin de La, 55, 57-59
definicin, 55,737
descripcin de la, 55, 57-59
ejecucin dela,77
grf.ica, 57, 58-59
Etiqueta (en el protocolo del
equipo), 101
Evaluacin de riesgos, 47
Evaluacin del proyecto, 109
Evento de riesgo, definicin, 132
Evitar riesgos en el manejo de
conflictos, 76, 77,'],,00
Excelencia, recompensas por, 102
Exitos rpidos,729
Expediente del proyecto, 35, 137
F manejo de las relaciones con
Factibilidad, definicin de
estudios de,737
Factores crticos para el xito,
1,37
Fase de cierre, 19
captura de las lecciones
aprendidas, 11.0, 11,2-71.s
celebracin/recompensas,
1,02-104
entrega del proyecto, 108-110
importancia de la, 105
lista de verificacin para la, 111
modelo parala,108-119
pasos en la, 106
reciclaje de informacin til,
775-777
reciclaje en la, 110, 172-717
transicin ala,104
Fase de control, 78-19,87-704
actividades del gerente del
proyecto, 87-90,95-96
actividades involucradas en
La,87-88
administracin de costos,/
programa/recursos
en la, 91-95
administracin de riesgos,
97,98
administracin del desempeo
tcnico, 87,89-90
administracin del equipo
del proyecto, gS-702
aspectos gerenciales, 97-98
comunicacin 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
transicin a la, 85
Fase de inicio, 78,29-45
creacin del protocolo del
proyecto enla,37-45
establecimiento del expediente/
archivo en la, 35
gerente del proyecto
en la,32-33,34-35
identificacin 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 definicin de un proyecto,
29,37
Fase de planeacin, 18,47-63
aclaracin de papeles/
responsabilidades en, 51-63
actividatlt's dcl gerente del
proyecto en Ia,51-63
asignacin de recursos en
La,59-62
creacin del programa del
proyecto en la, 60, 62-63
estructura de divisin del
trabaio, 55,57-59
formacin del equipo central,
50-51
pasos de Ia,52
proceso dela,48-49
reunin de arranque en la,
53-56
revisin de los requerimientos
del proyecto en Ia,51
tcnicas avanzadas para la,
65-85
tiempo dedicado a la, 44-45
transicin aLa,44-45
y software de administracin
de proyectos,5T-67
Fecha de terminacin del
proyecto,42
Fecha real de finalizacin,1,37
Fecha real de inicio, 138
Fechas de terminacin, 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
grficas de Gantt para
monitorear las,66-68
red lgica para monitorear
las,67-69
software de calendarizacirr
para monitorear las, 65-(r(r
1,48 ndice analtico
Fiesta de cierre, 118-119
Flotacin, 67 (Vase tambin
CoIchn)
G
Ganar-perder, manejo de los
conflictos,99
Gantt, grficas 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
planeacin, 5L-63
autoridad del, 27, 34-35
caractersticas de un buen, 33
como nico punto de
contacto,20-22
confianza y repecto del
equipo,87,89
defiricin, 138
en el protocolo del
proyecto, 40
optimismo natural del, 7 7-73
plan de reunin de arranque
del,53-54
rendicin 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,
transmisin de las lecciones
aprendida por parte
del, 115-116
y formacin del equipo
central, 50
Gerente funcional, definicin, 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
actualizacin de la, 93-95
fechas de terminacin en
La,63
para proyectos mltiples,
1.27-128
I 1t2-115
Identidad de los equipos,33
Impacto, 76,77-78,138
Informacin reutilizable, reciclaje
de,115-tI7
Inicio del proyecto, definicin,
138, (Vase tambin Fase de
inicio)
Interconexin (de proyectos
mltiples), 123-127
Interdependencia de proyectos/
tareas,725-127
Interesados en el proyecto
definicin,138
en el protocolo del
proyecto,40
en la fase de inicio, 33-36
ndice analtico
responsabidades de
los,40-41
Lrtranet, 1L5
T Manejo de conflictos, 98-\02,'1.39
jerarquizacin, matriz de, 129-131.
Jugadores clave
gerente del proyecto,
identificacin de los, 29,
37-32
impacto del retraso por,
123-124
interesados en el proyecto,
31.-32
patrocinador del proyecto,
3L-33
L Microsoft Word, Excel, P owerP oint,
Lecciones aprendidas, 108, 110,
definicin,138
enfoque formal para capturar
las, LL0, I12,175-776
enfoque informal para
capturar las,Il0,1\2
lista de verificacin para las,
112-11.5
sitio intranet para las, 114-116
Lewis, James P.,50,99
Lider azgo, habilidades de, 50-51
Likert, escala de, 109
Lnea base, 48, L38
Lista de tareas, 48,127-131. (Vase
tambin Estructura de
divisin del)
Logros
14()
comunicacin de, 90, 177 -778
reconocimiento de, 102
M
Manejo de las relaciones con el
cliente, L02-704
establecimiento de las
relaciones, 1-02-103
y aprobacin, L02-104
Matriz dbil, 139
Matriz de jerarquizacin,
L29-I3I
Matriz fuerte, 139
Mejoras, '1,05,1,07
Mejor valor,12L-122
Memorandos del estado del
proyecto, 80-8L, 90
Out\ook,74,59,131.
Miembros del equipo
(Vase tambin Equipo del
proyecto)
definicin,139
transferencia de las lecciones
aprendidas por los, 115-116
Mitigacin de riesgos, 77 -78
Moral, 23,107
Motivacin,107
N
Necesidades de estima, 107
Negociacin, 100
Negociador, enfoque (manejo rlt'
conflictos), 100-102
Ni hablar de hojas de clculo
(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
mltiples, 127
para "siguientes pasos" con
proyectos mltiples,
127-128,729-731
o aprobacin deI,83,85
OAP (Oficina de administracin
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 administracin de
proyectos (OAP), 115
Operaciones/ apoyo/
mantenimiento, transicin
a la fase de,179-120
Optimismo (en la programacin),
77-73
Organizacin de la matriz, 139
Organizacin funcional,
definicin, 139
P para ri'esgos,75-79
PAP (Profesional de
la administracin
de proyecto s),12-73
Pareto, enfoque de,129
Participante s (V ase Jugadores
clave)
Patrocinador del proyecto
ndice analtico
definicin,139
en el protocolo del
proyecto,3T-40
en la fase de inicio, 32-33
firma del, del protocolo,43
presin del,70
responsabilidades del, 43
Peters, Tom, 11-12
Plan del proyecto
definicin del, 139
desarrollo del,48
elementos en el, 47
planes subordinados del,
48-49
revisiones del,97-92
Planeacin de contingencias
de presupue stacin, 7 5-7 6
definicin, 139
reserya gerencial, 141
Planeacin de recursos, definicin,
739
Planeacin de riesgos, 76-79
Planeacin del proyecto, 139
(Vase tambin Fase de
planeacin)
Planes
de comunicacin, 78-8L, 83
para contingencias, 75-76, 1,39
P MBO K Gude, 1.3-14, 1,40
PMI (Project Management
Institute), 12-13
Precedencia, diagramas de,
65,67
Presin
para comprimir el programa,
68.70-77
por sobreca r ga, 727-734
Presiones del mercado, 70
Presiones p olticas, 70-7 7
Presupuestacin ascend ente, 66-75
Presupuesto del proyecto,
42-43,47,740
Presupuesto descendente, 74
Presupuesto detallado, 65-66
Presupuesto/ presupuestacin
ascendente, 66
definiciones, 140
de proyecto s, 42, 47, I40
descendente, 74
detallado,66
tcnicas avanzadas de, 74-75
Probabilida d conjunta, 7 3-7
Probabilidad,73-74
definicin, 140
de riesgos, 76,77-78
Proceso de administracin de
cambios, 140
Proceso, definicin, 140
Procesos burocrticos, 11
Producto, definicin, 140
Profesional de la administracin de
proyectos (PAP), 12
Programa, definicin, 125
Programa del proyecto, 47
(Vase tambin Programacin)
creacin del,47-48
definicin del,727
Programa detallado, 123
Programa semanal, 115-119
Programacin
(Vase tambin Programa del
proyecto)
dcfinicirr, 140
clt'l ticrl ro st'rtriru;rl, 131-134
ndice analtico t5l
optimismo enla,77-73
presiones polticas sobre
la,70-77
reservas/reguladores en
La,74-75
tcnicas avanzadas de, 68-7,1
y convergencia de rutas,
73-74
y estadstica,73-74
Programas acadmicos, 6
Project Leadership (James Lewis),
50,99
Project Managentent Body of
Knowledge (PMBOK Guide),
740
4 Project Management Irstitute
(PMI),72-74,20
Promedio ponderado, 72
Protocolo
del equipo, 101-102
del proyecto,29,37-45
Protocolo del proyecto, 29, 37 -45
cdigo de cargos en el, 108
como entrada principal dc
la planeacin,48
definicin, 140
distribucin del,44
documentacin de suposicior r.,s
en eI,43
elementos principales
del37-39
entregables en eI,42
fecha de terminacitrr
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 analtico

Respeto, 38-89 Soltwirc

objetivos de negocios en de lecciones aprendidas,
Responsabilidad, 21, 34-35 1'ara administracilr 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 Reconfiguracin de proyectos, 21.-22 Solit ittrd de cambio,83
presupuesto del proyecto en 92-93 Restriccin triple, 19-20, 60 tlt'firricin, 141
el,42-43 Reconocimiento, 707, Restricciones, 19-20 lrrrmato patala,M
relaciones estratgicas en el, 118-119 como desafos de Sr rrosiciones, 43, 63
43-44 Reconocimientos, 102 desempeo,23
responsabilidades de los Recursos definicin,141 T
interesados en el, 40-41 disponibilid ad de, 92-93 en la disponibilidad de 'I.r
n.,rs
responsabilidades / firma del fuente comn de, 125 recursos,60-61
tlt.rcndencias entre las,
patrocinador en el, 43-44 reasignacin de,92-93 estimaciones descendentes .t8,60,62-63
Proyectos como,74-75
uso de los,9L rf t: pcndiente s, 123-125
definicin de, 29, 31. 1.41. Resultados, 22,23
Red, diagramas de, 67-69,1,36 It'chrs de terminacin de,63
dependientes, 124-725 Resumen del proyecto, 47
Redes lgicas,65-67 llotirdor para, 67
xito de los, 13 Retroalimentacin, definicin,
Referentes, definicin, 141 i rr tc rconexi n de, 123-127
interconexin de los, 723-127 r47
Reguladores, T4-75 i rdependientes, 125-126
rr tc
interdependientes, 125-726 Reuniones del equipo
Relaciones estratgicas, 43 nrorritoreo de la terminacin
lista de, 726-127 durante la fase de control,
Rendicin 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 mltiples, administracin
Reportes Riesgo, definicin de, 76, 97, 747 l'cnica de revisin y evaluacin
de, \2'J.-124
de avances,/progreso/ Roddick, Andy, 38 del programa (PERT),
enfoque de proyecto maestro
89,1.41, Ruta crtica,67 65-67,70-73
enla, 126
de estado del proyecto, 81, definicin,141 definicin,140
interconexin en los, 123-727
82-83,90,147 origen,48 desviacin estndar en la, 73
manejo de la sobrecarga en,
Reportes de estado,90 estimacione s en la, 71-73
726-734
definicin, 141
S Tecnologas avanzadas de
y sobrecarga, T2l-1M
semanales,81, 82-83 Salidas,29 planeacin, 65-85
Proyectos / tareas dependientes,
Requerimientos del proyecto, Sobrecarga, 721-1,34 aprobacin del plan del
60, 62-63,123-726
revisin de los, 51 causas de La,1.21.-122 proyecto, 83,85
Proyectos / tareas separados,
e interconexin de los para la calendariza cin, 68-75
123-724 Requerimientos, revisin de los,
proyectos, 123-127 para monitorear la
del proyecto, 51
R Reserva gerencial, 141 ganancias inmediatas contra terminacin de tareas,
La,729-737 65-69
Reciclaje, 19 Reservas, 74-75,'J.41.
pasos para copar con la, planeacin de la
de la informacin reutilizable, Resolucin de conflictos,
726-131 comunicacin,78-82
71.5-177 700,701,147
L54 Indice analtico

planeacin de riesgos, 7 6-79 Variacin de la programacin,

presupuesta cn, 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 administracin de
(trabajo) las,9'J.-95
costo de las,97-92
V definicin,142
Variable de evento (riesgo), programa,9T-92
76,77-78 Variaciones de costos, 91

GERENCTA Y DESANNOIIO E.'ECUTIVO

INTERs 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
. Cmo destruir una empresa en
12 meses... o antes
. Cmo planear y dirigir un
negocio de tecnologfa exitoso
. lmplementacin
Los secretos gerenciales de
Disney
. Planeacin e implementacin
de la ventaja competitiva de su
empresa
. Visin viable

Si desea recibir informacin

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

nE* cRUPo EDtToRtAL

',I98 PANoRAMA
Dlreccln 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. Asturas 06850 - Mxico, D.F.
m e rc adotecn a @ pano ramaed. c o m. m x
Febrero 2006
Emprsa Certificada por el Tels.: 55-35-45-97 o gg-46-26-99 ext. 1 1 6
Insttuto Mexicano de Normalizacin www.panonmaed.com.mx
y Cerlilcacin A.C., bajo la Norma tienda panoramaed.com. mx
@
ISO-9002: 1 994/NMX-CC-004: 1995
con el Nm. de Registro RSC-048,
y bajo la Norma ISO-14001: 1996/5AA-1998,
con el Nm. de Regstro RSAA-003