"!$#&% ')( *+,-
./.&.10 2
"34
5 


0 6
Com o ce r r a r cor r e ct a m e n t e u n pr oye ct o
I nt r oducción
El cierre de proyect os ha sido y sigue siendo
uno de los capít ulos m ás oscuros y abando-
nados de la gerencia de proyect os. I nclusive
m uchas publicaciones no t rat an el t em a con
la profundidad necesaria.
En est e art ículo quiero describir brevem ent e
una serie de reglas para cerrar correct am en-
t e aquellos proyect os que llegan feliz o infe-
lizm ent e a su final. El cierre de proyect os
inconclusos que son cancelados por alguna
razón, sea de orden económ ico, t écnico o
com o result ado de una ordenanza guberna-
m ent al puede ser diferent e y ello dependerá
de la et apa en la cual se cierre y el m ot ivo
de su t erm inación. Est e t ipo de cierres no
son t rat ados en est e art ículo.
El cierre incorrect o de un proyect o concluido
hace perder m uchas oport unidades que serí-
an út iles para proyect os fut uros y a su vez
t rae consigo riesgos, norm alm ent e asociados
con cierre incom plet o de cont rat os y m anej o
de aspect os legales sin el rigor requerido, y
que pueden result ar en un fuert e im pact o
negat ivo para la organización que ej ecut a el
proyect o. Un cierre inadecuado dará lugar
adem ás, a im plicaciones que pueden afect ar
la est rat egia corporat iva de la em presa.
Ciclos de vida de l pr oye ct o y de l
pr oduct o
El ciclo de vida de un proyect o incluye por lo
general, cuat ro o cinco fases bien m arcadas
que t endrán diferent es nom bres, según el
t ipo de proyect o, pero que en el fondo son
sim ilares para la m ayoría de las diferent es
t ipos de indust ria. Est as fases est arán acorde
a una prim era et apa “ concept ual” , una se-
gunda et apa de “ definición” donde general-
m ent e se lleva a cabo la m ayor part e de la
planificación, una t ercera de “ ej ecución y
cont rol” y una últ im a de “ t erm inación” .
La fase concept ual puede incluir en si m is-
m a, un proyect o t ot alm ent e independient e
1
7
080 
que requiera un est udio de cost o- beneficio y
un est udio claro de si el proyect o es viable,
acorde con los obj et ivos de la em presa, para
decidir si se debe aut orizar o no su ej ecución
( pasar a la siguient e et apa) . La fase de defi-
nición suele ser una et apa de planificación,
pero algunos docum ent os requeridos para la
definición del proyect o global, pueden form ar
part e de la et apa de ej ecución en indust rias
t ales com o ingeniería.
La ej ecución es un conj unt o de procesos que
t ienen por obj et ivo “ hacer” el product o del
proyect o. En la m ayoría de los casos la ej e-
cución requerirá necesariam ent e act ividades
de cont rol y probablem ent e t areas de prue-
ba. Algunos aut ores que definen el ciclo de
vida de un proyect o separan las pruebas
com o una et apa independient e, com o en el
caso de la indust ria de t ecnología de infor-
m ación o el desarrollo de nuevas m edicinas
por la indust ria farm acéut ica y biot écnica. La
fase final de t odo proyect o es el cierre y pa-
recería que es una et apa sencilla, pero des-
afort unadam ent e es la et apa m ás descuida-
da de t odas, por lo que la m ayoría de los
proyect os se cierran m al.
Es t ípico ver com o el equipo del proyect o con
su gerent e al frent e, es t ransferido por su
necesidad en ot ro proyect o que se est á ini-
ciando, sin haber cubiert o los procedim ient os
m ínim os de cierre. Muchos son los proyect os
que t erm inan sin nunca alcanzar el 100% de
avance.
El m anej o correct o de las fases del ciclo de
vida, requieren la ut ilización de procesos que
form an part e de nueve ár eas de conocim ien-
t o. Una de est as áreas es int egración, cuyos
procesos son necesarios para int egrar t odas
las et apas del proyect o. Todos los procesos
se com binan en cinco grupos principales
( PMBOK© 2000) : inicio, planificación, ej ecu-
ción, cont rol y cierre. Est os grupos de proce-
sos se pueden repet ir y solapar a lo largo del
proyect o, según las circunst ancias part icula-
res de la organización y la dinám ica y obj et i-
 





 

"!$#&% ')( *+,-
./.&.10 2
"34
5 


0 6
vos del proyect o.
Los procesos de cierre est án present es a lo
largo del ciclo de vida y son necesarios cada
vez que finaliza una et apa. Por ej em plo un
gran proyect o de infraest ruct ura puede ne-
cesit ar el cierre adm inist rat ivo de la fase de
ingeniería, a m it ad del ciclo de vida del pro-
yect o. En TI , la conclusión de la fase alfa de
diseño de un soft ware ( first build) puede re-
querir un cierre. En un laborat orio farm acéu-
t ico el inicio de la segunda fase de pruebas
clínicas de una nueva m edicina en desarrollo,
solam ent e será aut orizado después de la
evaluación de los result ados clínicos de la
prim era fase. En m uchos casos el pase de
una et apa a la ot ra puede dar lugar a una
evaluación del negocio ( financiera, m erca-
deo, t écnica, et c..) , para aut orizar si se debe
o no proseguir con el proyect o.
Hay que dist inguir t am bién la diferencia en-
t re el ciclo de vida del proyect o y el ciclo de
vida del product o del proyect o. Aclarem os
que un proyect o t iene com o obj et ivo realizar
un product o ( del proyect o) que una vez
puest o en m archa puede m anufact urar un
“ product o para el consum idor final” ( que
puede no coincidir con “ el product o del pro-
yect o” ) . Est a últ im a clase de “ product o del
consum idor final” t am bién t iene su ciclo de
vida part icular.
Por ej em plo, el diseño, const rucción y puest a
en m archa de una refinería const it uye en si
un gran proyect o. El product o del proyect o
es la m ism a refinería, la cual es “ ent regada”
a operaciones para producir product os refi-
nados que const it uyen los product os del con-
sum idor. La puest a en m archa de la refinería
dará lugar al cierre del proyect o ( de duración
ent re 3 y 5 años) y solam ent e a una de las
et apas del ciclo de vida del product o, o sea,
la refinería, con una vida út il de alrededor de
50 años.
En ot ro t ipo de indust rias com o el soft ware,
el product o del proyect o puede ser el m ism o
que el product o del consum idor final.
Fa se de l cie r r e de l pr oye ct o
El cierre de proyect os es en si un conj unt o
de procesos, com o lo es el inicio, la planifica-
ción, la ej ecución o el cont rol. Según el
PMBOK© 2000 el cierre de proyect os incluye
dos procesos:
2
7
080 
x La conclusión del cont rat o
x El cierre adm inist rat ivo
El prim er proceso es part e del área de procu-
ra, m ient ras que el segundo es part e de co-
m unicaciones. Est os procesos son aplicables
a t odas las act ividades de cierre que ocurren
repet idam ent e en diferent es et apas de un
proyect o.
La versión PMBOK© 2004 que en el m om en-
t o de escribirse est e art ículo est á en fase de
revisión, hará ciert os cam bios sust anciales
en los procesos de cierre y uno de ellos for-
m ará part e de int egración, indicando ello la
necesidad de repet ición de est os procesos a
lo largo del ciclo de vida.
Pero el cierre m ás im port ant e y a su vez el
m ás descuidado de las et apas de un proyec-
t o, corresponde a su finalización y t iene lu-
gar en la et apa final de su ciclo de vida.
Aun cuando el cierre de proyect os requiere
de dos procesos est andarizados y es la fase
m ás sencilla, las act ividades que se deben
realizar t ienen una com plej idad m uy part icu-
lar y a veces no t ienen el apoyo del equipo,
ent re ot ras razones, porque la part e creat iva
del proyect o ya ha concluido. La list a de act i-
vidades indicada m ás abaj o, sería aplicable
en aquellos proyect os donde exist e clara-
m ent e un client e ext erno a la em presa que
ej ecut a el proyect o. Si el proyect o es realiza-
do para ot ra organización int erna, com o se-
ría el desarrollo de un nuevo product o a ser
ent regado al depart am ent o de m anufact ura
( y/ o m ercadeo) , la part e cont ract ual y legal
no aplicarían.
Est a list a incluye las siguient es act ividades,
pero no necesariam ent e se lim it a a ellas:
1. Term inar los det alles t écnicos falt ant es del
proyect o.
2. Audit ar los t rabaj os para asegurar que
est án com plet os.
3. Asegurar que t odas las ent regas de docu-
m ent os han sido realizadas y ordenadas
adecuadam ent e y asegurar que el proyec-
t o no dará lugar a dem andas legales fut u-
ras por part e de ninguno de los act ores del
proyect o.
4. Cierre de t odos los cont rat os y ej ecución
de t odos los pagos ( y cobr anzas) pendien-
t es.
 





 

"!$#&% ')( *+,-
./.&.10 2
"34
5 


0 6
5. Asegurar la sat isfacción del client e y obt e-
ner su reconocim ient o.
6. Preparar un m anual hist órico del proyect o.
Debe incluir la docum ent ación de planifica-
ción, t odos los regist ros de problem as y
casos ident ificados, la docum ent ación de
los cam bios de alcance, la ident ificación de
riesgos indicando su ocurrencia, im pact o y
com o se m anej aron, et c.
7. Preparar el m anual de lecciones aprendi-
das para ser incluido en el m ast er de la
em presa.
8. Transferir adecuadam ent e los recursos
hum anos y t ecnológicos que aun quedan
en el proyect o.
Analicem os brevem ent e, cada una de ellas:
1) La t erm inación t écnica del proyect o puede
llegar a ser un dram a. El avance de un pro-
yect o parece paralizarse y el proyect o es una
hist oria sin fin. En diseño de soft ware, es
aquí donde se j uega la calidad del product o
final ( en est e caso, product o del proyect o y
product o del consum idor final son iguales) .
Em presas m uy prest igiosas en el m undo TI
han ret irado a últ im a hora, m ódulos com ple-
t os que est aban en el alcance original, o han
decidido salir con cant idades excesivas de
defect os ( bugs) , con la idea de corregirlos en
una versión post erior, a ser publicada a ve-
ces, varios m eses después del lanzam ient o
del program a. Ret rasos en la ent rega final o
un proyect o fuera de presupuest o, puede dar
lugar a est e t ipo de decisiones. Una herra-
m ient a m uy út il para ello son las list as de
asunt os pendient es o “ punch list s” m uy t ípi-
cas en los proyect os de const rucción.
Por ej em plo, a veces un soft ware que puede
ser requerido para su fecha de lanzam ient o a
fines de Noviem bre, a t iem po para las fuer-
t es dem andas de las fiest as navideñas, sale
con un conj unt o exagerado de defect os. El
result ado final es una m ala calidad que pro-
duce un desencant o hacia el product o en los
consum idores, y hacia la em presa que lo
lanza. Los consum idores t ienen act ualm ent e
una fuert e herram ient a de denuncia y pro-
t est a com o es la I nt ernet , que cont ribuye a
difundir est as crít icas. Part icularm ent e, en
un proyect o TI en el cual part icipó el aut or,
en su evaluación y pruebas, se produj o la
caída vert iginosa en las vent as de una ver-
sión de un soft ware para j uegos de una m e-
ga- em presa de vent as m illonarias, que m ás
t arde acabó con la serie com plet a por su m a-
3
7
080 
la calidad.
2) Audit ar los t rabaj os significa evaluarlos
con respect o a los requerim ient os, alcance y
calidad aprobados para el proyect o, asegu-
rando que t odo el alcance que est á en el
proyect o ( o sea t odo lo que est á definido en
la est ruct ura desagregada de los t rabaj os -
WBS) se haya realizado de acuerdo a las
norm as de calidad t am bién aprobadas. Se
debe com probar que t odas las ent regas pla-
nificadas se hayan realizado.
3) Un cierre com plet o requiere el ordena-
m ient o y la ent rega de t odos los docum ent os
del proyect o de t ipo t écnico y adm inist rat ivo,
que no hayan sido t odavía ent regados. Se
debe asegurar que t odas las ent regas lle-
guen a los part icipant es del proyect o
( st akeholders) , o sea a los dest inat arios fina-
les que fueron ( o debieron ser) definidos en
el plan de com unicaciones del proyect o.
4) Cerrar los cont rat os que queden abiert os,
es una part e adm inist rat iva de procura e
im plica lim ar t odas “ las asperezas legales” ,
realizar la devolución o la ej ecución de fian-
zas y m ult as, aprobar o no los reclam os y
hacer los pagos finales ( o cobranzas con el
Client e) . En un gran proyect o est a et apa
puede ser la m ás larga y t ediosa del cierre y
puede requerir la part icipación de valiosos
recursos hum anos, necesarios para ot ros
proyect os. Se debe asegurar que no habrá
problem as fut uros con posibles dem andas
por part e de proveedores, subcont rat ist as o
el m ism o client e.
5) Si se cierra el cont rat o adecuadam ent e, y
si se ent regó el proyect o a t iem po y con el
alcance previst o y dent ro del cost o aut oriza-
do, y adem ás las relaciones con el client e
durant e el desarrollo del proyect o se m ant u-
vieron fluidas, sin m ayores cont rat iem pos y
conducidas dent ro de las reglas básicas de la
ét ica, la sat isfacción del client e debe ser au-
t om át ica. Hay que asegurar conseguir un
docum ent o que exprese la sat isfacción del
client e recom endándonos para fut uros t raba-
j os. Pero si hay problem as y el client e no
est á sat isfecho hay que dem ost rarle porque
los event os ocurrieron de una m anera det er-
m inada que causaron la insat isfacción e in-
sist ir en obt ener su recom endación.
6) Debe recuperarse t oda la inform ación del
proyect o y archivarla par a uso fut uro de la
 





 

"!$#&% ')( *+,-
./.&.10 2
"34
5 


0 6
em presa que ha ej ecut ado el proyect o. La
inform ación t écnica, com o códigos fuent e
( en TI ) , planos de I ngeniería, docum ent os de
planificación, ordenes de com pra, cot izacio-
nes de proveedores, m inut as y agendas de
las reuniones m ás im port ant es, list as de
event os y problem as y com o se resolvieron,
y en general cualquier docum ent o esencial
que perm it a aclarar cualquier duda en el fu-
t uro y que se puedan llegar a ut ilizar para
fut uros proyect os. Un infor m e com plet o debe
encabezar el conj unt o. El grupo de docum en-
t os del proyect o que se archiva, debe ser
capaz de reproducir en el fut uro la hist oria
det allada del proyect o, en caso de que sea
necesario.
7) Debe preparase un m anual de lecciones
aprendidas. Hay que dej ar claro que est e no
es un t rabaj o que se realiza al final del pro-
yect o, sino que es un conj unt o de inform a-
ción recolect ada desde el inicio m ism o. I n-
cluye solución de problem as t écnicos, hist o-
rial de nuevos riesgos que de hecho se con-
virt ieron en event os, el porqué ocurrieron y
com o se realizó su ident ificación, cual fue su
im pact o y la form a de enfrent arlos, hist oria-
les que afect aron los t iem pos y cost os, pro-
blem as específicos de calidad, cot izaciones,
et c. En general debe indicarse cada event o
relevant e y com o se solucionó, y el conj unt o
com plet o debe incorporarse a la base de da-
t os de lecciones aprendidas de la em presa.
8) Una act ividad que nunca se olvida durant e
el cierre del proyect o es la t ransferencia
oport una de los recursos. El proyect o ya no
puede pagar por los recursos hum anos y
m at eriales y deben de ser t ransferidos, o a
ot ro proyect o o a la gerencia de línea que
cont rola est os recursos. En algunas em pre-
sas bien organizadas donde se hacen m u-
chos proyect os, el cierre es realizado por un
equipo de t rabaj o que solam ent e se dedica a
est a act ividad. Los m iem bros del equipo
pasan a ot ros proyect os ya en m archa y son
sust it uidos por el equipo de cierre. Aun así
es deseable que el gerent e de proyect os per-
m anezca hast a donde sea necesario. Est e
m ét odo t iene sus vent aj as ( especialización,
rendim ient o) y desvent aj as ( falt a de conoci-
m ient o hist órico del proyect o) . En m uchas
em presas el grupo de cierre es un conj unt o
de profesionales adm inist rat ivos y abogados
que se dedican únicam ent e a cerrar cont ra-
t os y vent ilar asunt os legales.
7
080 
Ca u sa s de cie r r e s incom ple t os
y r e com e nda cion e s
Just am ent e es debido a las necesidades de
recursos escasos, que hace que el proyect o
se quede t em pranam ent e sin los recursos
necesarios para su t erm inación, descuidando
el cierre del proyect o y el porque la m ayoría
de los proyect os son pobrem ent e cerrados,
dej ando cont rat os inconclusos, angust iosos
conflict os con el client e y/ o proveedores, in-
sat isfacción de los part icipant es del proyect o,
punt os pendient es, alcance no com plet ado
que debe ser concluido post eriorm ent e por
equipos de t rabaj o de operaciones o por es-
caso personal, m eses después de la fecha de
ent rega, con docum ent os ext raviados o t ras-
papelados y sin un m anual de lecciones
aprendidas, por lo cual la m ayor part e de la
inform ación aprendida se perderá en pocos
m eses en el lim bo.
Ot ras razones de cierres inadecuados puede
ser la duda de si habrá ot ros proyect os para
el personal salient e, lo que puede producir su
despido de la em presa y por t ant o una fuert e
caída de la m oral del equipo en pleno, t an
pront o com o est a condición se det ect e, dan-
do lugar a que los t rabaj os finales se realicen
sin m ot ivación alguna, y por lo t ant o sin ren-
dim ient o ( he aquí ot ra razón para usar equi-
pos dedicados de cierre) .
Es necesario im plant ar polít icas en la em pre-
sa, a ser posible m anej adas por la oficina de
Gerencia de Proyect os ( PMO) ( si ést a exist e) ,
y que est ablezca el rigor suficient e para que
se cum plan los procedim ient os de cierre, no
im port ando las circunst ancias que obliguen a
salir con rapidez de un pr oyect o. Est os pro-
cedim ient os deben est ablecerse de t al m ane-
ra que perm it a adelant ar algunas de las act i-
vidades de cierre arriba m encionadas, y no
se espere siem pre para el final.
Un sist em a adecuado de norm as que produz-
ca cierres ordenados y com plet os en la m a-
yoría de los proyect os de la organización,
garant izará un paso adelant e hacía un m ode-
lo de m adurez en gerencia de proyect os y
hacia la obt ención de los obj et ivos est rat égi-
cos de la em presa.