Gestin de Proyectos

1. Ejecutar proyectos tiene no una sino hasta dos y tres metodologas, pero definir
las prioridades de los mismos, no ha corrido con la misma suerte. Algunas
pautas para priorizar sus proyectos.
Los proyectos existen desde siempre, pero recientemente se ha ido
construyendo esquemas de trabajo que permiten que los proyectos sean
efectivos y cumplan con su propsito.
Ya no es solo terminar el proyecto dentro del tiempo y costo asignado sino
tambin producir el entregable con el cual quien lo recibe obtendr! los
beneficios estipulados desde la justificacin del mismo.
"e han generado dos metodolog#as claras, una avalada e impulsada por el $%&,
quien produce el $%'o( )cuerpo de conocimiento de proyectos* y otra, conocida
como $+&,-./, generada por la 0ficina de -omercio 1ubernamental en el +eino
2nido, inicialmente para proyectos de 3&- y ahora para todo tipo de proyectos. .st!
tan de moda las metodolog#as de proyectos que la &"0 est! preparando el est!ndar
&"0/4566 que re7ne, seg7n los preliminares, las dos metodolog#as enunciadas arriba.
8 pesar de todo este trabajo, no existe una propuesta concreta para priori9ar proyectos.
.xisten todo tipo de recomendaciones sobre diferentes alcances para lograr esta
priori9acin, pero se quedan cortos en cuanto a definir una serie de pasos para definir
prioridades, no porque no se quiera, sino por lo dif#cil que es conjugar los diferentes
requerimientos que tendr#a esta priori9acin.
-uando se clasifica algo, lo que sea, por ra9ones obvias quedaran unas en los primeros
lugares y otras en los 7ltimos lugares. &gual suceder! con cualquier mtodo que se utilice
para proiri9ar proyectos. Lo importante no termina siendo solo el orden, sino que todos los
involucrados estn de acuerdo con el resultado obtenido, tanto los que defienden los
proyectos en los primeros lugares, que de seguro se llevar!n a cabo, y para quienes los
proyectos tendr!n que esperar otra ronda, por no haber clasificado lo suficientemente alto.
$ara lograr esta aceptacin, los criterios de clasificacin deben ser acordados entre todos, y
tener un claro reflejo en el beneficio para el conjunto, no en forma individual.
2n conjunto de criterios que ha tenido buen resultado en nuestra pr!ctica incluye:
Impacto Estratgico ;<u tanto impactar! el proyecto al logro de los resultados
estratgicos de la compa=#a .xisten herramientas que permiten evaluar y medir el impacto
estratgico de los procesos y la informacin, en forma numrica, asignando valor al
impacto que se perciba sobre la necesidad o no de un proceso para la correcta ejecucin de
la estrategia.
!eneficio ;-u!l ser! el monto del beneficio a obtener al aplicar el producto del proyecto>
?ebe ser claro que el beneficio debe estar dado por el receptor del producto del proyecto,
beneficio sobre el cual se hicieron las justificaciones para el proyecto. .s importante de
todas maneras que el beneficio se logre, y esto solo se podr! determinar al finali9ar el
proyecto y aplicar el producto del mismo.
.sta es una de las variables sobre las cuales se puede hacer an!lisis de sensibilidad para
tratar de limpiar cualquier sesgo que pueda tener la informacin inicial. 8 mayor
beneficio, mayor calificacin para el posicionamiento del proyecto. "e pueden estipular
rangos de beneficio, que debe ser de cualquier manera traducido en beneficios econmicos
)a menos que sean proyectos que se deben emprender por requerimientos legales, los cuales
tienen prioridad alta de todas maneras*.
"actor de #$ito )que podr#a tambin ser una medida del riesgo*: ;<u tan factible es tener
xito, no solo en la ejecucin del proyecto sino en el logro de los beneficios> $or
definicin, el an!lisis de riesgo involucra an!lisis de probabilidades de que el riesgo suceda,
y la capacidad para mitigarlo. 8 mayor riesgo, menor probabilidad de xito, por lo tanto
deber#a tener una calificacin menor que un proyecto con menos riesgo.
?e la calificacin de cada uno de estos criterios, habr! posibilidades de darles pesos en
varias alternativas, o de multiplicarlos entre s# para luego generar un gran total.
?e cualquier manera, cada empresa requerir! estructurar su propio sistema de priori9acin
de proyectos, y ojal! terminarlos antes de que los criterios de clasificacin cambien su
prioridad.

2. %ual&uiera &ue sea su aplicacin, no se puede perder de 'ista entonces donde
encajan los proyectos en el entorno empresarial.
?e un tiempo para ac! el tema de gerencia de proyectos, gestin y
lidera9go de proyectos, profesionales de la gerencia de proyectos, y
otros nombres que recibe, ha cobrado vigencia y relevancia, no solo
en empresas cuyo curso de negocio es manejar proyectos, como las
constructoras o las casas de soft@are, sino en todas las empresas.
.sta popularidad no es en vano. "e ha generado una buena cantidad
de conocimiento en varios frentes y continentes que permiten desarrollar metodolog#as
apropiadas para la gestin de proyectos cumpliendo a cabalidad con los objetivos del
mismo.
Aasta hace un tiempo el manejo de proyectos era mas por intuicin que por otra cosa, hoy
se tienen como m#nimo dos cuerpos de conocimiento: el $%'o( gestado por el $roject
%anagement &nstitute y $+&,-./ surgido en &nglaterra y de amplia aceptacin en .uropa
como est!ndar para manejo de proyectos. $ara confirmar el auge, la &"0 est! preparando el
est!ndar /4566 como herramienta de gestin de proyectos para que sea aceptada
mundialmente.
&ndistinto de las metodolog#as, una sola o un h#brido de varias, la concepcin del proyecto y
donde encaja dentro de las organi9aciones sigue siendo la misma.
&niciemos con la definicin de un proyecto entonces como un esfuer9o temporal que se
ejecuta para obtener un resultado 7nico. La temporalidad del mismo es la que precisamente
exige que el proyecto tenga no solo un inicio sino un final. 'uena parte de los proyectos los
iniciamos en el #mpetu y la emocin, y se nos olvida planear desde ese mismo momento
como y cuando se culmina el proyecto.
La definicin del alcance, donde se ha hecho mucho nfasis en las recientes versiones de
las metodolog#as arriba mencionadas, se convierte en herramienta fundamental para
enmarcar precisamente el alcance del proyecto, qu se debe entregar para considerar
finali9ado el esfuer9o.
Lo que no es temporal es el producto del proyecto, es decir, el objetivo para el cual se
conform el proyecto, sea construir una casa, generar una nueva vacuna, hacer una tesis, o
crear un sitio Beb.
Aabiendo entonces aclarado la temporalidad del proyecto, es importante ponerlos en
contexto dentro del !mbito empresarial.
$or peque=a que sea una empresa, hace un proceso de planeacin estratgico, formal o
informal, pero todos los gerentes saben para donde quieren llevar su empresa, para qu la
construyeron, y que deben hacer para llegar all!. Las respuestas a estas inquietudes
constituyen el plan estratgico corporativo, que reiteramos, est! formalmente documentado
en algunos casos y en otros se maneja de manera informal.
.ste plan estratgico es el que da inicio entonces o dispara una serie de proyectos para dar
cumplimiento al mandato de esta estrategia. .s con proyectos que se van logrando los
objetivos estratgicos. -uando requerimos m!s de un proyecto para una estrategia, que por
lo general suele ser as#, entramos entonces a manejar el concepto de programas. Los
programas re7nen una serie de proyectos que apuntan a una misma estrategia.
-uando se inicia un proceso de gestin de proyectos, debe estar claro que el beneficio del
mismo ya ha sido justificado. La estructuracin de proyectos de factibilidad, planes de
negocio y la formulacin de proyectos son otras disciplinas anteriores a la 1estin de
$royectos. .s precisamente la estrategia la que da pi al proyecto y de no ser as#, es bien
probable que durante la ejecucin del mismo proyecto haya muchas dudas sobre su valide9
o pertinencia. .l estar amarrado a las estrategias corporativas le dar! suficiente piso para
aguantar todos los embates que recibir!.
-ualquiera que sea su aplicacin, no se puede perder de vista entonces donde encajan los
proyectos en el entorno empresarial.
3. No se aventure a desarrollar proyectos y avanzar en el tiempo hasta que no tenga
una claridad suficiente sobre lo que se espera que haga; defina bien el alcance
antes de distraer recursos.
Aace unos a=os no ten#amos metodolog#as que permitieran indicar
las mejores pr!cticas para llevar a cabo un proyecto y garanti9ar el
cumplimiento de sus objetivos con el uso de los recursos asignados
al mismo. Aoy contamos con el cuerpo de conocimiento sobre estas
mejores pr!cticas en un documento que se conoce como el $%'o(
)$roject %anagement 'ody of Cno@ledge*.
La teor#a indica que lo primero que se debe estructurar, aparte de unos documentos
formales de establecimiento y lan9amiento, es el alcance del proyecto. "e debe llegar a un
claro entendimiento entre el cliente y el proveedor )quien recibir! el producto del
proyecto y quien desarrollar! actividades para elaborar el producto del proyecto.*
$or lo general el cliente va a querer que haya la menor definicin posible para poder
cambiar el alcance, y el proveedor querr! el mayor nivel de definicin para evitar desfases
y reducir el riesgo de imprevistos. .ste balance es dif#cil de lograr en la medida que el
cliente no quiera concretar lo que necesita, y que el proveedor no pueda manejar la
incertidumbre.
.s necesario entonces un proceso de negociacin que permita definir no solo el alcance
sino el mecanismo para manejo del alcance. 2na de las mejores herramientas para esta
tarea es precisamente la construccin de la estructura de desglose de trabajo ).?3, o B'"
del ingls Bor( 'rea(do@n "tructure*.
?esarrollar la estructura de desglose de trabajo bajo la metodolog#a propuesta invita a
descomponer el o los productos finales en componentes y cada componente en subD
componentes hasta que no se puedan hacer m!s divisiones. .s importante recordar que
seguimos hablando del <2., es decir del alcance, no del -0%0 que vendr#an a ser las
actividades.
-ada elemento, cada componente de esta estructura, debe tener definido un alcance, que
permita determinar que se ha logrado el objetivo. -ada elemento madre o que tenga subD
componentes se deber! construir a partir de los elementos debajo de l, y no con trabajo
adicional. "on principios sencillos pero por nuestra caracter#stica occidental de
concentrarnos en el cmo, omitimos desde el principio.
3enemos claro que la vida real no responde a procesos perfectos, ni se puede encajar en una
metodolog#a r#gida. $ero por lo menos debemos tener claridad en buena parte del
contenido de esta .?3, y en especial en aquellos elementos que su variabilidad pueda
ocasionar un desv#o grande en el desarrollo del proyecto. -ualquier omisin en este
aspecto puede por si sola llevar al fracaso el proyecto, por peque=o que sea.
.n la medida que el equipo humano del proyecto es m!s numeroso, y que su ubicacin
geogr!fica pueda ser dispersa, con mayor ra9n se hace indispensable tener una definicin
clara del alcance, de ese objetivo a donde debemos llegar, para que cada miembro del
equipo pueda tener su norte establecido y determinar las actividades a desarrollar bajo su
responsabilidad que le permitan lograr los entregables a su cargo.
$or alguna ra9n que no logro identificar, la mayor#a de proyectos que plane!bamos )si a
eso que hac#amos se le pod#a llamar planear* siempre iniciaba con una lista de actividades y
sub actividades, seguidas de la asignacin de tiempos a las mismas, responsables, y en
ocasiones hasta los recursos requeridos para desarrollar las actividades. ;Y el alcance> ?e
eso no sab#amos mucho.
8hora tenemos las herramientas que nos permiten sugerir que hasta que la B'" no est
definida, en buena parte todos sus entregables, tendremos un alto riesgo de incumplir, no
porque no seamos capaces de hacer lo que se nos encomiende, sino porque el norte, adem!s
de no estar claro, puede ser sujeto a variaciones. E,o arranque a hacer hasta que no termine
de planear el queF
;"e lo permitir!n las restricciones de tiempo del proyecto> ;"e lo permitir! su cliente> ?e
usted depende manifestar los beneficios de planear el alcance, para garanti9ar que durante
el hacer haya claridad en el curso de accin adem!s de mayor certe9a en el cumplimiento.
4. (a est)n consolidadas por lo menos dos metodologas para administracin de
proyectos, sin em*argo se nos ha &uedado un poco rezagado la forma de medir
el $ito del proyecto.
.l manejo de proyectos no es una nueva disciplina, as# pare9ca algo
novedoso por lo que est! de moda, tanto una metodolog#a como la
certificacin en la misma. Lo que si es nuevo es la aceptacin
generali9ada de unos pasos indispensables que garanti9an el xito en la
gestin del proyecto.
.n este orden de ideas, se tienen dos marcos de referencia, muy slidos ambos, uno el
$%'o( o el cuerpo de conocimientos sobre proyectos, agenciado y promocionado por el
$%& )$roject %anagement &nstitute* y $rince/, que traduce $rojects &n -ontrolled
.nvironments )proyectos en ambientes controlados*, que es de dominio p7blico y originario
en el +eino unido. 3an de moda est! esto, que la &"0 ha anunciado el desarrollo de la
norma &"0/4566 precisamente para manejo de proyectos.
.s importante tener claro donde encaja la metodolog#a de gestin de proyectos dentro el
esquema general de los proyectos, un esquema general que arranca en la concepcin de un
beneficio, que se convierte en proyecto y se aprueba, 8,3." de iniciar su ejecucin. La
gestin del proyecto inicia en la ejecucin.
,o tiene sentido aplicar ninguna metodolog#a de gestin de proyectos antes de que el
proyecto est formulado y aprobado. .xisten muchas presiones, en especial por el acelerado
ritmo del mundo de hoy, para ir avan9ando as# no se tengan cubiertos los pasos anteriores.
$ara atender este tipo de requerimientos previos a la gestin, existen metodolog#as para la
formulacin de proyectos. %etodolog#as generalmente aceptadas como la del %arco
Lgico generada en el '&? permiten de una manera muy sencilla validar la coherencia de
objetivos a la lu9 de los riesgos identificados.
3ambin se aplican herramientas financieras para determinar el costoGbeneficio de ejecutar
o no el proyecto, teniendo en claro que el beneficio es reali9able, por lo general, una ve9
termine el proyecto y se entreguen los productos del proyecto. -on frecuencia nos
olvidamos que los proyectos deben concluir, m!s no el producto del proyecto, y
confundimos el alcance identificando tanto el desarrollo del producto como el resultado de
su aplicacin como parte del alcance.
2n ejemplo sencillo ser#a la construccin de un acueducto. .s claro el beneficio del agua
potable, y aunque a primera vista no se ven beneficios numricos, hay numerosos estudios
que demuestran el beneficio social del mismo y que justificar#an sin mayor problema su
construccin. 8cto seguido viene la construccin misma del acueducto, dentro de un
proyecto cuyo alcance sea establecido desde los dise=os finales )por ejemplo*, hasta la
primera prueba de calidad de potabilidad del agua que sale del acueducto.
2na ve9 terminado el acueducto, y por ende el proyecto, habr! que mantener el acueducto,
hacer mediciones permanentes de la calidad del agua, y verificar los beneficios estipulados
al inicio del proyecto para validar que efectivamente se est!n logrando.
.l xito del proyecto entonces se debe medir comparando los beneficios esperados contra
los beneficios obtenidos, medicin que por lo general abarca un per#odo m!s largo que el la
gestin del proyecto, cuyo objetivo es entregar el producto.
.l xito de la gestin del proyecto, en la que normalmente nos concentramos cuando
gerenciamos un proyecto, se mide en la entrega del o los productos del proyecto, acorde a
especificaciones del clienteGusuario, dentro de los tiempos y costos esperados.
.n el !mbito empresarial, no es suficiente preocuparnos por la gestin del proyecto, que en
7ltimas es solo la porcin del costo, dentro del an!lisis del costo beneficio. 3ambin nos
debemos preocupar por la obtencin del beneficio, ra9n primordial por la cual nos
embarcamos en la gestin del proyecto.
5. +as metodologas disponi*les para la gestin y administracin de proyectos,
enfocan la o*ligacin y tarea principal de un gerente de proyectos en el
*alance, seguimiento y garanta del cumplimiento de tres restricciones
*)sicas. ,emos ido a'anzando en la aplicacin de estas metodologas, y las tres
restricciones *)sicas ya no son suficientes, es necesario tam*in tener en cuenta
otras tres restricciones adicionales &ue hoy da se e$igen para garantizar
satisfaccin completa en el resultado del mismo.
&dealmente no debe haber cambios en un proyecto bien planeado, se
debe poder ejecutar y obtener el resultado esperado )alcance* dentro
del tiempo, costo y calidad esperada. La palabra clave es la primera de la frase:
idealmente. 3enemos claro que lo 7nico cierto es que el plan no se ejecutar! como se
plane y que se requiere tomar decisiones al respecto. "i no fuera as#, realmente no
necesitar#amos gerentes de proyecto en el curso del mismo.

8 pesar de ser un proceso completamente c#clico, y en ocasiones en paralelo, todas las
decisiones que se tomen dentro del entorno del proyecto de deben tomar a la lu9 de su
impacto previsible en cada una de las restricciones.
8l inicio del proyecto, la primera que nos concierne en su definicin es el alcance. .s
donde definimos exactamente qu debe entregar el proyecto, tanto en calidades como en
cualidades y funcionalidad, y adem!s estructuramos tambin los recursos necesarios para
obtener ese alcance. .ntre estos recursos incluimos las dos variables importantes: tiempo y
costo.
-onstituyen entonces las tres restricciones b!sicas el alcance, el tiempo y el costo. Las
experiencias recogidas nos han mostrado que los proyectos tienden a desviarse de la
primera restriccin en el curso de su administracin, en particular porque nos enfocamos en
temas de tiempo y costo, que al parecer es lo que realmente le interesa a los due=os del
proyecto. "in embargo, es claro que los cambios en el alcance, mal manejados, pueden y
en efecto dan al traste con los resultados generales del proyecto en la mayor#a de los casos.
,os concentramos en tiempo y costos. La balan9a por lo general est! entre menos tiempo y
mas costo, o mas tiempo y menos costo, sin tener en cuenta que las demoras en la entrega,
suponiendo se entrega con la totalidad del alcance, tambin acarrean un costo de
oportunidad. "e completa la trilog#a b!sica entonces con la restriccin del alcance, donde
es indispensable hacer un manejo exhaustivo del alcance, sin permitir cambios en el mismo
que realmente agreguen valor al proyecto.
+ecientemente se ha venido utili9ando el concepto ampliado de la -triloga. con tres
nuevos componentes a tener siempre en cuenta en la balan9a al momento de tomar las
decisiones. "e complementa con el manejo de la calidad, satisfaccin del cliente y el
manejo del riesgo.
La calidad es un concepto relativamente nuevo incorporado dentro de los proyectos, y
luego de los procesos de calidad total, mejoramiento continuo y dem!s tendencias
administrativas de los ochentas, entendemos ahora claramente la diferencia entre la calidad
del producto y la calidad del proceso. .n algunos casos, los sistemas de gestin de calidad
al interior de los proyectos se ven como impedimentos para toma de decisiones !giles, por
ejemplo, sin embargo est!n ah# por una ra9n valida y se deben cumplir. La calidad del
producto del proyecto no se discute, y menos se deben admitir cambios en su definicin,
convirtindose en una de las restricciones m!s fuertes del proyecto.
.l manejo del riesgo es otro concepto que requiere permanente monitoreo, en especial al
momento de tomar decisiones sobre los cambios en los proyectos. .s costumbre que al
modificar los proyectos en sus otros aspectos, toda nuestra matri9 de riesgos y contencin
de los mismos pueda quedar inservible.
$or 7ltimo, completa la sexteta de restricciones, el manejo de la satisfaccin de los
beneficiarios del proyecto o sus clientes. 0riginalmente hab#amos apareado esta
satisfaccin con el cumplimento del alcance, pero sabemos hoy que adem!s hay que
cumplir con el tiempo, el costo, la calidad, y otros elementos de satisfaccin que bien
puedan ni siquiera estar estipulados dentro del objetivo del mismo.
-ualquier cambio al interior del proyecto requerir! de la habilidad de los gerentes de
proyecto para *alancear el impacto, no solo en otros dos frentes, sino ahora en cinco
frentes de restricciones. .s poco probable que se pueda acortar la duracin de un proyecto
sin causar impacto en por lo menos dos de las otras !reas.
. !unque parezca e"tra#o$ la conclusion de los proyectos se debe estructurar desde
el inicio del mismo. No de%e que sus proyectos sigan estando en el &&' y se
queden inconclusos.
Aay dos tipos de aplicacin de gestin por proyectos en las empresas: en unas
de estas empresas su HvidaH gira en torno de proyectos, como las empresas
de construccin, de consultor#a, y hasta entidades educativas. .l otro tipo de
aplicacin es en aquellas cuyo curso normal del negocio no tiene nada que
ver con proyectos, pero que opta por utili9ar la metodolog#a para
implementar una nueva planta de produccin, una nueva cultura corporativa,
obtener una certificacin de calidad, entre otras.
?e cualquiera que sea el tipo de empresa y la aplicacin de la metodolog#a,
uno de los mayores inconvenientes con los que nos enfrentamos en la
gestin de proyectos es precisamente lograr el cierre del mismo, llegar a
Hfeli9 terminoH )o a triste trmino, pero terminarF*. ?esde cumplimientos del
IIJ hasta dineros dejados de pagar por remanentes, informes dejados de
hacer, pendientes de esos aburridores de concluir.
La falta de cierre de los proyectos se da al inicio del mismo. $arecer#a
irnico pensar que desde el comien9o del proyecto se deba estar hablando
del final del mismo, pero precisamente para eso se gesta la planeacin del
alcance del proyecto, con exhaustiva dedicacin.
"omos muy !giles para entrar en el hacer, y dejamos un poco en el olvido las
tareas del pensar. La planeacin del alcance de un proyecto en dos
vertientes, se hace indispensable para poder garanti9ar que el proyecto se
concluir!, y mejor a7n, tendr! como verificar su conclusin sin estar sujeto a
opiniones o consideraciones subjetivas.
2n proyecto tiene dos alcances claramente definibles y que deben estar
completamente entendidos antes del inicio. 2no de los alcances aplica al
producto del proyecto. -ada proyecto se estructura como un esfuer9o
temporal para producir un productoGservicio como salida del proyecto
mismo. Aay que definir muy bien las caracter#sticas deseadas en el producto,
en forma tangible y verificable, de tal manea que mediante los procesos de
verificacin del alcance se pueda determinar si se cumpli o no con el
objetivo.
"i es un programa de soft@are, hay una funcionalidad que ste debe cumplir,
con unos requerimientos de calidad estipulados. "i es una casa o edificio,
hay unos planos y funciones que se deben ejecutar para garanti9ar el
beneficio del espacio construido. 8s#, para cada proyecto es necesario definir
el alcance del producto.
8hora viene la conjuncin con el alcance del proyecto. ;Aasta adonde va el
proyecto> ;<u incluye> ;-u!ndo 3ermina> .n buena parte de los proyectos
nos concentramos en el alcance del producto y ponemos poca atencin al
alcance del proyecto, lo que hace dif#cil concluirlo. .s indispensable poder
dar repuestas a estas preguntas antes de iniciar el proyecto para que tanto el
proveedor como el cliente del proyecto tengan claro hasta adonde van sus
obligaciones y su exigencia.
-uando uno compra un soft@are, quisiera que tambin se quedara el
proveedor m!s all! del per#odo de implementacin para resolver las
inquietudes de operacin y hasta de manejo, nos da temor Hdejar irH al
proveedor porque no estamos seguros de poder continuar sin l. "i somos el
proveedor, queremos irnos cuanto antes de la instalacin del cliente,
necesitamos pasar al siguiente cliente. 2na clara definicin de que el
proyecto llega hasta finali9ar las pruebas y puesta en produccin, por
ejemplo, durante el primer mes, da por concluido el proyecto, permite saber
exactamente cuando se termina.
.l cierre del proyecto depende de lo que adecuadamente se estipule al inicio,
en la planeacin del alcance. 1arantice que sus proyectos concluyan
adecuadamente desde el principioF
(. )or peque#o que sea el proyecto$ se requieren habilidades de administraci*n del
mismo para sortear las diferentes situaciones que se presenten$ y adem+s
garantizar el cumplimiento de los ob%etivos dentro de los tiempos estipulados.
Introduccin Los proyectos por definicin tienen una fecha de inicio y
finali9acin determinados, al igual que un alcance, presupuesto, resultados
espec#ficos y recursos asignados. 8dicionalmente, cada proyecto, por similar que
sean las actividades y los alcances, se tornan diferentes porque las circunstancias
cambian, y las cosas siempre son distintas cuando se lidia con personas.

2na de las funciones primordiales de los administradores de proyectos es administrar los
procesos internos del mismo donde realmente se efect7a el trabajo. $or peque=o que sea el
proyecto, se requieren habilidades de administracin del mismo para sortear las diferentes
situaciones que se presenten, y adem!s garanti9ar el cumplimiento de los objetivos dentro
de los tiempos estipulados. .stas habilidades van desde la definicin del proyecto, hasta la
administracin de las medidas de avance del mismo. 8dicionalmente, se deben incorporar
tcnicas para el manejo de contratos y el manejo de proveedores. .n esta y las
subsiguientes entregas anali9aremos lo que consideramos son las 4/ habilidades necesarias
en el manejo de proyectos, que si se ejecutan adecuadamente garanti9ar!n el desarrollo del
proyecto:
/. 0efinicin del proyecto
1. Planeacin del 2ra*ajo
3. Administracin de %ontratos
4. Administracin de Pro'eedores
5. Administracin del Plan de tra*ajo
6. Administracin de situaciones
7. Administracin del Alcance
8. Administracin de 9iesgos
:. Administracin de la comunicacin
/;. Administracin de la documentacin
//. Administracin de la calidad
/1. Administracin de las mtricas
8ntes de iniciar la explicacin de cada una de estas habilidades requeridas, es importante
efectuar una diferenciacin entre lo que se considera el trabajo del proyecto y la
administracin del mismo. La lista arriba no incluye las etapas de an!lisis, dise=o, pruebas
o implementacin y quienes han trabajado en proyectos conocen que por lo menos incluyen
an!lisis y pruebas. "in embargo, estas etapas son claramente parte del mismo proyecto y no
del proceso administrativo. .n muchas ocasiones se confunden las actividades del proyecto
con las de administracin, haciendo que estas etapas no estn incluidas dentro de los
cronogramas.

Las dos primeras actividades se deben hacer en estricto orden y antes que las die9 restantes
para garanti9ar el xito del proyecto. "alt!rselas ser!n se=al inequ#voca de fracasos, bien
sea por falta de enfoque o por falta de actividades requeridas.

/. 0efinicin del proyecto
8ntes de iniciar el proyecto, es indispensable que el trabajo est! entendido y que los
responsables, tanto de la ejecucin del proyecto como quienes recibir!n los resultados del
mismo, tienen una visin clara de los resultados esperados, cuando se terminar!, cuanto va
costar, quin har! el trabajo, como se dar! por terminado el trabajo, y cuales ser!n los
beneficios.

$eque=o o grande el proyecto, la definicin de su alcance es herramienta vital para que el
1erente del $royecto o los comits respectivos puedan tomar decisiones en las etapas
administrativas que se mencionar!n m!s adelante. 'uena parte de las decisiones se toman y
se califican mediante valoracin del impacto que tienen en el resultado final del mismo,
dado por esta etapa de definicin.

.ntre m!s grande el proyecto, la importancia de dejar esta informacin expl#citamente
estipulada aumenta. .l resultado de esta actividad debe ser un documento titulado
H?efinicin del $royectoH y debe incluir la informacin mencionada en el primer p!rrafo.

$uede ser un poco dif#cil determinar cuales ser!n las salidas del proyecto en detalle, y
tambin puede ser complejo determinar el costo total y la fecha de finali9acin. .n este
caso se recomienda dividir el proyecto en proyectos m!s peque=os. "e definir#a en detalle
los primeros subproyectos en el cronograma, y se definir#a el detalle de los proyectos m!s
lejanos, cuando se acerque su ejecucin. Aabr!, en este caso, que dejar actividades de
revisin de proyecto para garanti9ar que estas definiciones si se llevar!n a cabo. 0mitirlas
del plan de trabajo, casi certifica que no se har!n.

8l final de esta etapa, se debe tener entonces un documento con el alcance y expectativa del
mismo, como se medir!, quien lo har!, y cuanto costar!. .ste documento deber! estar
aprobado por todos los involucrados, ya que tratar de buscar consenso sobre estos temas en
un proyecto que ya ha arrancado es extremadamente dif#cil.
1. Planeacin del 2ra*ajo
-uando se define el proyecto, uno se asegura que se tiene un entendimiento claro con el
patrocinador del mismo sobre &u se debe alcan9ar en el proyecto. .n la etapa de
planeacin se determina cmo se va reali9ar el trabajo. .sto implica entonces elaborar un
plan para el trabajo. "e utili9an diferentes alcances, acordes al tama=o del proyecto. $or
ejemplo, se puede utili9ar desde una hoja de papel para un proyecto peque=o, hasta
soluciones sistemati9adas como el %icrosoft $roject para proyectos m!s complejos.
"i no se cuenta con una plantilla para el plan de trabajo, se recomienda utili9ar la estructura
de an!lisis de arriba abajo, una tcnica que permite mirar el proyecto desde un alto nivel, y
quebrar el trabajo en peque=os componentes hasta que se tiene el panorama completo del
mismo. 3odo el equipo puede colaborar en esta tarea. "e recomienda tener cuidado con el
nivel de detalle, porque partir el proyecto en componentes exageradamente peque=os puede
ocasionar altos costos de ineficiencia en su mantenimiento. %i recomendacin es que se
tengan actividades en fracciones del tama=o total del proyecto. $or ejemplo, si el proyecto
dura un a=o, la tarea m!s peque=a debe ser en semanas. "i el proyecto dura meses, la tarea
m!s peque=a debe ser d#as, y si el proyecto dura semanas, la tarea m!s peque=a debe ser de
cuatro horas. ,o tiene sentido incorporar actividades de menor duracin a las estipuladas
aqu#, a menos que sean hitos dentro del proyecto.
2na ve9 se tiene la lista de actividades, el siguiente paso es estructurar la dependencia de
las mismas. ,o todos se pueden desarrollar al tiempo. 2na ve9 culminado este proceso de
dependencias, se pasa a asignar los recursos a cada una de las actividades. .stos recursos
incluyen personal, dinero, y elementos requeridos. .s factible, y por lo general com7n, que
la asignacin de recursos ocasione cambios en las fechas, por lo que se utili9an tcnicas de
nivelacin de recursos para ajustar el plan de trabajo a la disponibilidad de recursos.
"e recomienda, especialmente para el recurso humano, tomar solo seis horas h!biles por d#a
laborable, y en caso que se trabaje los s!bados, no contar este tiempo dentro de la
planeacin, sino dejarlo para ajustes semanales al proyecto. -uando el c!lculo de tiempos
es muy preciso, se ocasionan muchos ajustes a cronogramas y fechas de terminacin, lo que
por lo general desmotiva al grupo.
3. Administracin de contratos
"i el proyecto no involucra proveedores externos, tanto este aparte como el siguiente se
pueden saltar. "in embargo, dado que el auge por el outsourcing, en especial en materia de
conexin a &nternet e implementacin de soft@are de refiere, incluimos los dos apartes
como tercer y cuarta habilidad requerida.
.l contrato es el documento que rige las condiciones bajo las cuales se adquiere un bien yGo
servicio. .n el caso de los bienes, es mucho m!s f!cil medir la entrega de lo adquirido,
situacin que se dificulta cuando son servicios. $or esto es recomendable tener una lista de
HentregablesH que se esperan obtener de los servicios recibidos. .ntre m!s tangibles los
entregables, m!s f!cil de administrar el cumplimiento.
Aay dos temas fundamentales en la administracin de un contrato: la entrega de los
resultados )entregables* y el cumplimiento de las fechas para estas entregas. $ara ambos se
establecen criterios y requerimientos que permiten controlar el cumplimiento de los dos
temas. 0jal! el pago est amarrado a los entregables a satisfaccin por el contratante, lo que
aporta un factor motivador para el cumplimiento.
-on frecuencia se olvida que el contrato es un documento legal, regido por el cdigo de
comercio de cada pa#s, por lo que es indispensable conocer ste cdigo. ?e la misma
manera se convierte en necesidad conocer el esquema de manejo de las pli9as de
cumplimiento, las instancias para su ejecucin, y la documentacin de soporte.
.n resumen, la administracin del contrato involucra el control de los entregables, los
pagos, y el manejo del tiempo del proyecto.
4. Administracin de Pro'eedores
.n el transcurso del proyecto, la relacin con los proveedores es muy
variante, variacin estrechamente ligada al avance del mismo. .s claro que
al inicio del proceso, todo es como una luna de miel: la empresa acaba de
contratar a quienes consider su mejor opcin en un proceso de seleccin, y
el proveedor acaba de adquirir un nuevo cliente. ?urante esta etapa, todo
fluye, las decisiones son f!ciles de tomar, y realmente no es mucho el
tropie9o que se sufre.
2na ve9 inicia el proyecto, empie9an a detectarse diferencias de criterios y
de alcances para los entregables. .n la administracin de contratos y en el
proceso de contratacin mismo, se trata de incluir todo lo que pudiera hacer
claridad en el manejo del proveedor y sus obligaciones, pero con frecuencia
no son suficientes.
-omo en los matrimonios, el mejor remedio es la conversacin, y si es a
tiempo, mucho mejor. "e deben establecer reuniones peridicas de
seguimiento tanto al contrato como a las actividades del proveedor. 8plica la
misma recomendacin que para la elaboracin del cronograma, la reunin
por lo menos deber! ser como m#nimo semanal, y como m!ximo mensual,
dependiendo del estado de avance del mismo.
3anto el proveedor como el cliente en ocasiones dejan de establecer
mecanismos para esta administracin, por lo que por lo general terminan
establecindose procedimientos durante la ejecucin del contrato. .s
necesario tener claro, por ejemplo, quin sufraga los costos de viajes y
alojamiento, cmo se relacionan dentro del proyecto, cuales son los
documentos para exigir el pago, y cada cuanto se presentan estos pagos.
?e la misma manera, es imperante establecer como se manejar!n los
incumplimientos, normales hasta cierto punto, entre lo programado
inicialmente y lo que realmente est! entregando el proveedor. Aay dos tipos
de incumplimientos: el de especificaciones o funcin requerida, y el de
tiempos. "obra decir que una entrega incompleta, pero en la fecha
estipulada, no constituye una entrega a satisfaccin, y por lo tanto induce al
incumplimiento.
2n proyecto, dependiendo de la envergadura, puede llegar a tener varios
proveedores interactuando. La administracin de esta interaccin la puede
hacer inclusive otro proveedor, o la empresa misma. "e deben definir
tambin los mecanismos de asignacin de responsabilidades de tal manera
que no haya lugar a rebotar de un proveedor a otro, la solucin a un
problema.
"e recomienda el nombramiento de un tercero como interventor del proyecto
de tal manera que haya una visin imparcial y defensora del proyecto en s# y
sus objetivos, y no de los intereses de cliente y proveedor. .s claro que el
7nico que queda sin defensor es el proyecto, y el interventor puede hacer
esta tarea.
5. Administracin del Plan de 2ra*ajo
Aasta aqu#, ya se tienen definidos el proyecto y planeado el trabajo. ?e la
misma manera, en caso de necesitarse, est!n en pi los documentos que
rigen la relacin con los proveedores. Los entregables del proyecto hasta
ahora son: La ?efinicin del $royecto, .l $lan de 3rabajo, el -ontrato, y el
%anual de 8dministracin del $royecto. 8unque algunos gerentes de
proyecto consideran que al superar estos pasos ya se tiene superada la parte
dif#cil de la administracin del proyecto, est!n equivocados.
.l plan de trabajo es solo un entregable. ?escribe lo que hay que hacer, el
orden del trabajo, el esfuer9o requerido y quien est! asignado a qu tarea,
pero solo representa el mejor estimado de cmo completar el trabajo que
queda por hacer en un momento dado de un proyecto.
.ntre m!s complejo es el proyecto, m!s cambios se presentan en el plan de
trabajo con el transcurrir del tiempo. .l 1erente del proyecto deber! revisar
los planes de trabajo en forma permanente )se recomienda en forma
semanal, como m#nimo* y determinar el estado actual del mismo.
"e hace indispensable el uso de la gerencia proactiva, de tal manera que se
identifiquen las actividades a cumplirse en el cercano futuro, y con base en
estas actividades y su impacto dentro de los cronogramas y los objetivos del
proyecto, hacer los ajustes para que los objetivos principales se cumplan.
-ualquier cambio en los cronogramas, criterios de aceptacin y objetivos
establecidos deber!n ser resueltos a travs de un comit de cambios. ?ebe
ser claro para todos los involucrados en el proyecto, que estos cambios
afectan el alcance del contrato, por lo que no se pueden tomar
unilateralmente. .ste comit debe, una ve9 se analice el impacto y eval7e el
riesgo, tomar la decisin de asignar m!s recursos, o apla9ar el cumplimiento.
6. Administracin de situaciones
$or lo general, un proyecto se administra en dos instancias: una a nivel de
equipo de proyecto y el gerente del proyecto, y la segunda a nivel de
gerencia de la compa=#a. -uando se involucran proveedores, habr! tambin
un gerente del proyecto por parte del proveedor, y estar! tambin asignado al
proyecto el gerente de la empresa para el comit gerencial. .n algunos
casos, comit implica largas e improductivas reuniones. $ara efectos de este
escrito, el comit es un grupo de personas con autoridad para tomar
decisiones, que requieren o no de reuniones para hacerlo. Aoy, con el uso del
correo electrnico y sistemas automati9ados para el manejo de proyectos,
son escasas las reuniones requeridas.
2na HsituacinH se presenta cuando un problema puede llegar a impedir o
impide el progreso del proyecto y no puede ser resuelto por el gerente del
proyecto y el equipo del proyecto sin ayuda externa. -uando se presenta este
tipo de situaciones, no queda m!s alternativa que resolver el problema.
"e recomienda la aplicacin de tcnicas de manejo de situaciones, la cual
tiene dos componentes. .l primero es tener un proceso que permita
encontrar estas situaciones y traerlas a la lu9, determinar su impacto en el
proyecto, evaluar las alternativas, y conseguir las personas que permitan
tomar la mejor decisin dadas las circunstancias. .ste proceso debe hacer
parte del proceso general de administracin del proyecto y debe estar
definido antes de empe9ar el mismo.
.l segundo componente es aplicar tcnicas de solucin de problemas para
resolver estas situaciones. .sto incluye el entendimiento de herramientas
como los diagramas de espina de pescado, diagramas de $aretto, y an!lisis
de causa y efecto. .l conocer estas herramientas permite que el equipo
entienda la ra9n del problema, determine acciones disponibles, y qu
alternativa ser#a la mejor a tomar.
.s importante tener en cuenta que tener un proceso para resolver situaciones
no es lo mismo que tener la habilidad para resolverlos exitosamente. .n
algunos casos hay mejores alternativas, y el trabajo del grupo de proyecto es
encontrarlas y aplicarlas. .n otros casos no hay una buena solucin para
estas situaciones. .n este caso hay que tomar la decisin por la que menos
da=o haga, o la Hmenos malaH de las alternativas.
7. Administracin del Alcance
.l alcance de un proyecto describe los l#mites del mismo y lo que el
proyecto va a entregar, qu informacin se necesita y qu partes de la
organi9acin se ver!n afectadas. ?ado un grupo de recursos y tiempo, un
n7mero de cosas se puede lograr.
La administracin de cambios en el alcance inicia con la definicin de qu es
un cambio de alcance. "i el gerente del proyecto no ha definido bien el
alcance inicial del proyecto, ser! tremendamente dif#cil administrar este
alcance durante el proyecto. .l propsito de la administracin de cambios en
el alcance es proteger la viabilidad de la definicin del proyecto ya definida
y aprobada. -uando se defini el proyecto, tambin se definieron y
estipularon las expectativas de resultados.
?urante la vida del proyecto es normal que se requieran #tems diferentes o
adicionales a los incluidos en la definicin original del proyecto. ?ebe ser
claro para todas las partes que cumplir estos nuevos requerimientos con los
mismos recursos de la definicin anterior, es pr!cticamente imposible.
.s claro que la aprobacin de los cambios en el alcance debe ser efectuada
entre los clientes y proveedores del mismo, ya que es la 7nica manera de que
se alleguen los recursos adicionales necesarios y se ajusten las expectativas
de los involucrados.
La administracin del alcance no es siempre tan sencilla. "uceden problemas
comunes. 2no de ellos es aceptar cambios peque=os que a simple vista no
afectan mucho el proyecto, y se desconoce el efecto conjunto de muchos
cambios peque=os. 3ambin se pueden tomar decisiones a un nivel menor
del indicado, lo que implica que los Hdue=osH del resultado pueden no
obtenerlo. $ara evitar este segundo problema, se recomienda que los
cambios en los entregables solo puedan ser aprobados por la gerencia de
cada empresa. $or lo general estos cambios conllevan mayores costos y
atrasan la obtencin de los resultados, dos temas que impactan directamente
a las gerencias de las empresas. del proyecto
8. Administracin de riesgos
.l riesgo es una condicin futura que existe fuera del control del grupo del
proyecto, y que puede tener un impacto negativo sobre el resultado del
proyecto si se llega a dar la condicin. 8dministradores reactivos esperan a
resolver la situacin cuando esta suceda. Los administradores proactivos
tratan de identificar y resolver problemas potenciales antes de que ocurran.
Los proyectos peque=os, por su corta duracin, no dan mucha cabida al
surgimiento de problemas. $or el contrario, los proyectos grandes est!n
propensos a problemas esperando a aparecer. 8bogamos por una
administracin proactiva, por lo que la administracin de riesgos entonces la
definimos como la identificacin de todos los riesgos posibles, determinas
qu tan certero es que se presente el riesgo, y entender el impacto en el
proyecto si ocurren.
2na ve9 identificado el riesgo que se quiere administrar activamente, hay
cinco cursos de accin que se pueden tomar:
<o hacer nada. ,o se har! nada si se determina que el efecto sobre el
proyecto es despreciable ante la ocurrencia del riesgo, o no hay nada que se
pueda hacer para atenderlo.
=eguimiento. "e le dar! seguimiento al riesgo en forma que se pueda
determinar la probabilidad de que se d o no el riesgo en la medida que
transcurre el tiempo. "i aparentemente aumenta la probabilidad de
ocurrencia a medida que pasa el tiempo, se atender! en ese momento.
E'itar el riesgo. .sto implica eliminar la condicin que podr#a causar el
problema. $or ejemplo, riesgos que presente un proveedor pueden ser
evitados con la contratacin de otro proveedor.
>ue'a el riesgo. .n algunos casos es factible que la administracin del
riesgo sea removida de la administracin del proyecto y asignada a otra
entidad o tercera parte.
>itigue el riesgo. .n la mayor#a de los casos esta es la medida a tomar. "i
se ha detectado un riesgo, y es de consideracin, puede desarrollarse un plan
proactivo para garanti9ar que el riesgo no ocurra, o si lo hace, su impacto sea
despreciable.
8l igual que con la administracin del alcance, no hay nada malo en que
haya riesgos en un proyecto. ,o se pretende que un proyecto no tenga
riesgo, lo que importa es la respuesta que de la administracin del proyecto
al riesgo. "i se ignoran los riesgos, se convertir!n en situaciones y se tendr!n
para ese entonces, menos opciones para su solucin.
:. Administracin de la %omunicacin
.sta es una de las actividades cr#ticas en un proyecto, y fundamental en la
administracin de los objetivos y los receptores de los beneficios del mismo.
.s la mejor forma de evitar las sorpresas, factor agravante ante la presencia
de un imprevisto.
Aay dos niveles de comunicacin en un proyecto. 3odos los proyectos deben
comunicar el estado del mismo. 8dicionalmente, si el proyecto es complejo
o m!s grande, se necesita un nivel m!s sofisticado de comunicacin definido
en un $lan de -omunicaciones.
Las reuniones de estado y el reporte de estado del proyecto es donde se
estipula el avance del proyecto, los problemas, las actividades cumplidas,
revisin del flujo de caja, y la proximidad de los entregables. .n este nivel
se efect7a la formali9acin del manejo de riesgo, de situaciones, de los
contratos y dem!s componentes del proyecto. $or lo general se define un
informe con formato est!ndar donde se resume el avance y se alerta sobre
posibles problemas.
-uando el impacto del proyecto es de gran envergadura, se requiere un $lan
de -omunicaciones, que no solo informe sobre el proyecto sino que ayude
en la implementacin del cambio. $or lo general este plan se arma con
informacin que se distribuye en varios niveles. .l obligatorio, donde se
incluyen los reportes de estado del proyecto, presupuestos, y requerimientos
legales y de auditoria. .l de informacin, donde se provee informacin
extensa para quien la requiera. .sta informacin incluye preguntas
frecuentes, una biblioteca de documentos y un sitio @eb para el proyecto
entre otros. $or 7ltimo, est! el tipo de informacin de mercadeo que se
encarga de crear entusiasmo por el proyecto, e incluye desde la nombrada
del proyecto, entrega de testimoniales de los administradores, y relatos de
los xitos en el proyecto.
La comunicacin se debe manejar en forma proactiva por el administrador
del proyecto, debe estar planeada y ser ejecutada con un propsito en mente.
/;. Administracin de los 0ocumentos
La administracin de la documentacin es una de esas
actividades que los gerentes de proyectos dan por sentadas,
hasta que se ven inundados en papel. $ara proyectos peque=os
no hay necesidad de establecer todo un sistema administrativo,
pero en la medida que el alcance del proyecto aumenta, se hace
necesario tenerlo. 8unque es una de las tareas que puede ser asistida por
tecnolog#as como un repositorio documental, estas herramientas pueden ser
dif#ciles de administrar e incorporan mayores problemas al proyecto.
3emas tan sencillos como la codificacin de los documentos, y qu tipos de
documentos se quieren almacenar y por cuanto tiempo. 8lgunos prefieren
organi9arlo por fuente de la informacin, y otros por el objeto de la misma.
Ae tenido muy buena experiencia clasificando la informacin general del
proyecto, como contratos, pli9as y reporte de cumplimientos en un grupoK
la informacin relativa a cada logro en otro, y por 7ltimo, las actas
consecutivas de los diferentes estamentos de decisin.
0tra decisin es el formato est!ndar para los documentos. +ecomendamos
utili9ar el $?L para los documentos que no variar!n una ve9 se publiquen, y
crear un sitio Beb para su almacenamiento.
//. Administracin de la %alidad
La calidad de un proyecto ser mide por qu tan cerca est!n de
cumplirse las expectativas y entregables para el cliente, por lo
tanto el objetivo central del equipo del proyecto es tratar de
cumplir y exceder los requerimientos del cliente. Aay una
tendencia a equiparar calidad con el mejor material, mejor equipo
y cero defectos. "in embargo en la mayor#a de los casos, el cliente
no espera y no puede costear una solucin perfecta.
.l propsito de la funcin de la administracin de la calidad es la correcta
definicin de la expectativa del cliente, mediante la cuantificacin de algo
que originalmente se maneja como subjetivo. "e debe descomponer el
termino HcalidadH en un n7mero de arreas que puedan definir las
caracter#sticas de calidad en forma tangible, y luego ver cmo se mide cada
una de ellas.
La medicin de la calidad no es un evento sino un proceso continuo y un
estado mental. "e recomienda la utili9acin de los principios del circulo de
calidad para efectuar este proceso en forma efectiva.
-uando se define el proyecto, el grupo de trabajo debe entender los trminos
de calidad impuestos por el cliente y estar consignados en un $lan de
-alidad, en el cual se manejan los criterios de aceptacin y correccin de
cada entregable. $or ejemplo, en la entrega de soft@are, se sabe que es
dif#cil que est completamente libre de fallas, por lo que se puede definir que
se da por aceptado con fallas de forma, m!s no de fondo.
.l plan tambin contiene dos procesos: control de calidad y aseguramiento
de la calidad. .l control de calidad asegura que los entregables del proyecto
cumplan con las expectativas del cliente. 8seguramiento de la calidad se
ocupa de que el proceso para crear los entregables sean de alta calidad. 2n
ejemplo de este segundo caso puede ser una lista de chequeo de pasos para
garanti9ar que el producto se entrega completo.
2no de los propsitos del control de calidad es detectar errores lo antes
posible en la vida del proyecto, y as# disminuir su impacto tanto econmico
como en tiempo del mismo.
/1. Administracin de la >edicin
0btener las mtricas de un proyecto es la habilidad de manejo
de proyectos m!s sofisticada, y se puede convertir en la m!s
dif#cil. Las mtricas son por lo general dif#cil de definir y
recolectar, ra9ones por las cuales se ignoran o se manejan en
forma inadecuada.
"e deben definir mtricas b!sicas que permitan medir el esfuer9o, costo y
tiempos de terminacin. 3ambin se deben incluir mtricas que determinen
que tan bien se satisfacen los requerimientos del cliente y como se cumple
con las expectativas. ?ependiendo de los resultados, se toman los
correctivos pertinentes.
$ara fijar las mtricas para el proyecto, se sugiere identificare los criterios de
xito en termino de entregables y ejecucin, determinar como medir tanto el
logro final como el avance, seleccionar un numero balanceado de mtricas, y
recoger la informacin. .s de vital importancia colocar par!metros de
comparacin mediante metas ya que la mtrica por si sola no dice mucho.
.n general, este proceso es de poca importancia para proyectos peque=os ya
que no hay ni el tiempo para recolectar los valores, y menos para anali9ar y
tomar correctivos.
%?<%+@=I?<E=
.stas doce habilidades descritas como necesarias en una medida u otra para
garanti9ar el xito de los proyectos se centra en la administracin de
procesos. "in embargo hay otra serie de habilidades que tambin se
requieren en el manejo de las personas como lidera9go, escucha y buena
retroalimentacin.
8lgunos de estos aspectos de la administracin de proyectos, como definir el
proyecto y administrar situaciones, aplican para todos los proyectos. 0tros
como el manejo de la documentacin y las mtricas cobran importancia en
proyectos m!s grandes.