¿ Qué hay detrás de la creciente demanda de software, asesores, libros y cursos de administra-

CIÓn d<.: proyectos? ¿Por gu~ ahora tantas personas se interesan en la admin istrac ión ele proyectos?
¿Qué puede ofreca la admtnistración de proyectos que otras tecnologías de administrución no
ofrc:zc.an ·)
Las razones del creciente interés por la ndministración de proyectos (AP) se hacen evtdentes
mediante un cuidadoso examen del panor<lma actual de los negocios. Pero más importante, quizá,
administración de proyectos es sinónimo de acmir.istración del cambio. Las organizaciones que
quieten modificar su enfoque o dirección reconocen, cada vez más. que implantar verdaderos cam-
bios requiere la introducción de nuevos productos, procesos o programas de manera oportuna y de
manera eficiente en costos.
El cambio rápido se ha convertido, actualmente, en un requisito esencial para la supervivencia
de casi todas las organ¡zaciones. Confonne el ciclo de vida de los productos dtsmwuye, dében desa-
rrollarse e implementarse nuevos productos y serYicios, tan rápida y eficientemente como sea posi-
ble. Además, los productos se vuelven obsoletos con mayor rapidez. Griffing y Page (1993) informan
que 50% de los ingresos de una empresa típica provienen de productos imroducidos en los últimos
cinco años en comparación con una estimación de 33% en los 80 y 20% en los 70 (Takcuchi y
Nonaka, 1986). Los ciclos de vida del producto más reducidos requieren que la selecc ión y el desa-
rrollo de nuevos productos se manejen con eficiencia en costos y que maximicen las posibi ltdades de
éxno comercial. En algunas industrias, los administradores tienen mucho menos de cinco años para
desarrollar. producir y vender un nuevo producto. Por ejemplo, Yang (2000) apunta que la industria
de la comunicación está sujeta a la regla 4-3-3 : cuatro meses para desmTollar un nuevo producto, n·es
meses para hace r dinero con él y t.res meses para sacarlo de los anaqueles. Los asesores de McKinsey
& Co. estimaron que la ganancia potencial bruta de un producto de una empresa típica se reduce alre-
dedor de 12% si el producto se introduce con tres meses ele retraso, y 25% si se introduce con cinco
meses de retraso (Vesey, 1992). Yang expresó h siruación del desarrollo ele nuevos productos de
manera muy sucinta: "el momento para ponerlo en el mercado significa vida o mue11e, y todo lo que
pueda inclinar la balanza a nuestro favor es preciado". Cada vez mñs administradores reconocen que
una buena admimstración de proyectos puede proporcionar una parte significauva de esa vent:.tja.
También la naturaleza de los proyectos ha cambiado en la última década. La admin istractón de
proyectos se ha usado desde el tiempo de las pirámides d<.: Egipto, hace casi cinco mil años. Aunque
no sabemos si la construcción de l:~s pirámides de Egipto terminó a tiempo y dentro del presupuesto,
sí sabemos que hoy las organizaciones realizan proyectos rutinarios en entornos globales comple-
jos que hacen la coordi nación y la comuntcación mucho más difícil que en los tiempos ele la cons-
trucción egipcia hace cinco mil años. Muchos de estos proyectos, en especial los de tecnolog ía de
la información (TI), re¡Jresenton inversiones significativas para una organización. de modo que
el fracaso del proyecto puede significar el ftn de la organización. Los admimstradores de proyec-
tos deben usar mbodos que maximicen 1:1 probabi lidad de éxitO de estos proyectos.
Dad:.t la creciente irnpo11ancia de admin istrar proyectos complejos, es inqu ietante ver el gran
número de proyectos que no logran satisfacer sus objetivos básicos. En un estudio de veintitrés mil
proyectos ele aplicación. el Grupo Standish itj(ormó que en 1998 sólo 26% de los proyectos tuvieron
éxtto total, mientras que 46% fueron cuestionables (esto es, termtnaron, pero con presupuesto y/o
1
L CAf'ITULO 1 INTRODUCCION A LAADMINISTRACION DE PROYECTO~,

tiempo mayores, con menos funci ones que las desig nadas originalme nte) y 28% se consideraro n un
fracaso (Grupo Standish, 1999). Según el Grupo Standish, estos proyectos que fracasaron costaron
cas1 75 000 millones de dólares en 1998.
Las estadísticas presentadas por el Grupo Sta ndi!>h son alarmantemente congruentes con otros
estudios. Bounds ( l 998) infom1a q ue sólo 26% de los proyectos de tecnología de la información
terminaron a tiempo y dentro del presupuesto. Yeo (1999) inform a q ue de los doscientos m.il pro-
yectos de desarrollo de 5ofrware puestos en marcha en 1999 por empresas de E stados Unidos, alre-
dedor de 31% se cancelaron o abandonaron antes de terminar, lo que representó una pérdida de cas1
62 millones de dólares. Yeo también indica s¡ue sólo 13% de Jos proyectos de sistemas de T I fue-
ron considerados proyectos exitosos por los patrocinadores, mientras que sólo 16.2% de Jos pro-
yectos de desarroll o de software termina ron a tiempo y dentro del presupuesto.
Otros ejemplos i l u~tran la imponancia del éx ito de la AP, y los altos costos del fracaso. Por el
lado del éxito. hace poco BC Hydro terminó a tiempo y 21 'lo abajo del presupuesto un proyecto de
repos1ción de una p lanta de poder en Brilish Columbia, Canadá. mediante el uso de técnicas pro-
fesionales de AP. U na btJe na AP no sólo ahorró millones de dólares a BC Hydro, sino que demos-
tró cómo estas "técnicas aseguran que los proyectos tengan éxito técn ico, ambiental y soc ial"
(Water Power, 2000). En Alemania, los arqueólogos encontraron que las herramientas de AP ofre-
cen una manera eficiente de admini!.trar las exploraciones y e;;cavaciones de los sitios arqueológi-
cos (Walker. 1996). En otra historia de éxiw. los administradore~ de Taco Bell describen cómo
reconstruyeron completame nte un restaurante de Taco Bell que el fuego había destruido. Los ad mi-
nistradores pudieron reducir drásticamente el tiempo normal de este proyecto, de sesenta días a 48
horas, aplicando con cuidado las técnicas de AP en incrementos de q uince minutos (Industrial
Enginecring, 1992). Estos ejemplos indican Jo que la AP puede lograr cuando hay una planeación
cuidadosa, una implementación hábil y buena suerte.
Por otro lado, ha habido muchos fracasos nolabJes de proyectos. El sistema computarizado para
manejo del equipaje en el Aeropuerto Internacional de Denver retrasó la apertura del aeropuerto más
de un aiio y le sumó $85 millones al presupuesto 01iginal. El proyecto para la construcción del túnel
en el Canal de la Mancha costó f3 000 millones más que la estimación original y necesitó dos años
más de lo planeado. Aun Mickey Mouse ha sido incapaz de escaparse de las dificultades impuestas
por la administración de proyectos complejos, como lo testifica!Ían muchos clientes frustrados (vea
el artículo adj unto).
Dada esta reciente historia de experiencias en proyectos, la administración de proyectos pro-
fesional ofrece una metodología que ha sido cuidadosamente definida, refinada y aplicada con éxito
durante los últimos cinco años. La administración de proyectos es un sistema bien desarrollado que
puede ayudar a las organizaciones a lograr sus metas con oportunidad. Como resultado, la admi-
nistración de proyectos se ha convertido e n una parte esencial de la ad ministración de alta tecnolo-
gía, un elemento crucial del comercio electrónico y una parte importante del movimiento de
globalización que ha transformado a la economía mundial en los últimos diez años. Dado el tamaño
y el alcance de todos los proyectos que se emprenden anualmente, es claro por qué la administra-
ción de proyectos se ha convertido en e l enfoque de las empresas globales y el gobierno. De hecho,
ahora ~e estima que la administración de proyectos es e n sí unn industria de 850 millones de dóla-
res que se espera crezca 20% por ciento por año (Bounds, 1998).
E!';tc libro introduce los conceptos básicos de la administración de proyectos con el fin de dar
a los administradores una clara comprensión de las herramiemas y trueques que requieren Jos pro-
yectos complejos. En e l libro nos centramos en los problemas que deben afrontar los administra
dores que realizan proyectos com plicados. En este primer capítu lo se consideran los te mas
SlgUICiltes."

• ¿Qué es la administración de proyectos y en qué difiere de otras formas de administra-

ción (como administración de programas)?
• ¿Qué es un proyecto?
• ¿Cómo se define e l éxito o el fracaso de un proyecto?
 ¿QUÉ DEFINE UN PROYECTO? 3

• ¿Cuáles son algunos ejemplos notables de éxito y fracaso de proyectos y qué lecciones
se pueden aprender del estudio de estos casos?
• ¿En qué difieren los proyectos de T I de otros proyectos?
• ¿Qué es un ciclo de vida de AP?
• ¿Cuáles son algunos modelos de ciclos de vida comunes'1
• ¿Cómo se puede considerar el nesgo de un proyecto?
• ¿Cuál es la historia de la administración de proyectos?
• ¿Cu<ll es la naturaleza del software para AP?

¿QUÉ DEFINE UN PROYECTO?

-------------------------------------------------------------
¿Qué es un proyecto y en qué difiere de un programa? De acuerdo con el Project Management
Institute (2000), un proyecto es "una iniciativa temporal que se pone en marcha para crear un pro-
ducto o servicio único." De manera alternativa, un proyecto se puede vc1 como un conjunto bien
definido de tareas o actividades que deben realizarse para cumplir las metas del proyecto.
Normalmente se considera que estas tareas o acti' idades que constituyen un proyecto están defint-
das de manera que:
• Cada tarea se puede in iciar o tletener independientemente de cualquier otra (dentro de
una secuencia dada) y
• Las tareas están ordenadas de tal manera que se deben reaLizar en una secuencia tecno-
lógica (por ejemplo, las paredes de una casa de ben construirs~ antes que el techo).
Además, en general se supone que una vez que se inician las tareas, no se pueden interrumpir (o
detener) y deben de continuar hasta su terminación.
De e!>tJ definición se derivan varias impiJcaciones. Primero, los proyectos tienen un tiempo de
vida bien defin1do entre el momento en que inicia la primera tarea y term1na la úluma (aunque en
realidad a veces es difícil decir cuándo un proyecto está totalmente terminado). Como los proyec
tos const.sten en tareas bien definidas, sue len existir metas específicas as1gnadas al proyecto; entre
estas metas se encuentran las espectficaciones de calidad y de dise;;ño, y los objetivos de costo y
programactón. Es común que estOs objet i vo~ e~té n orientados al clien te meta del proyectO, que
puede scr diferente al cliente típico de una organización (es decir, un proyecto designado ¡:¡ara un
cliente espccítico).
Más aún, los proyectos tienen algunas otras características únicas. Casi siempre se caracte"ri-
zan por el u~o de equipos de proyecto multifuncionales. De hecho, el amplio uso aclllal de equipos

El constructor de barcos de Disney se retrasó seis meses en la entrega de los harcos crucero y miles de
clicmes que habían comprado boletos se quedaron planwdos. Aun con est:l experiencia. también entregó
el segundo barco después de las fechas publicadas. Universal Studios en Orlando, Florida, llevaba dos
años construyendo un nuevo complejo de rc~taurantes y entretenimiento. Anunciaron que la inaugura-
CIÓn sería en diciembre sólo para rectificar a fines de noviembre que tardaría do~ o tres meses más.
Aun cuando las instalaciones abren cerca de la fecha prevista. rara vez est:ín completamente termi-
nadas y con frecuencia aún les faltan componentes cla,·e. ¿Por qué pasan estas cosas? Con todas las
sofisticadas computadoras y el software para la administración de proyectos eXIStente. ¿por qué no ter-
mman los proyectos a tiempo?
Fuente. F. Frnble. Nation·s Restaurant News ( 12 de abril d.: 1999).
4 CAP[TU LO 1 INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS

mult1funcionales en la mayoría de las organizaciones es una extensión de las prácticas de AP ante-

riores. La ventaja de usar equipos de proyecto ahora se reconoce ampliamente, aunque es menos
claro cómo organizar y manejar estos equipos.
Dado que los proyectos deben terminar en un tiempo fmito, los recursos no suelen adquirirse
para proyectos específicos, sino gue se obtienen de otras partes de la organización. Una excepción
se presenta cuando la empresa contrata empleados evenruales para un proyecto específico o subcon-
trata parte del proyecto (o todo). De cualquier manera, en general los proyectos deben ajustarse al
portafolio global de experiencia y conocimiento disponible en la organización.
Todo tipo de organización, sea pública o privada, lucrativa o no lucrativa (y los indiv iduos),
emprende proyectos; un ejemplo interesante se encuentra en el artículo adjunto de Janofsky, "de la
política a los pasteles: nueva vida para el ex gobernador deArizona". Algunos ejemplos de proyec-
tos incluyen:
• Constru ir las pirámides del rey Keops (Egipto)
• Encontrar un trabajo al salir de la universidad
• Cerrar los registros contables al final del mes
• Instalar y depurar un nuevo sistema de computación
• Planear y lanzar un nuevo producto
• Realizar una campaña política
• Los proyectos de mantenimiento y reparación
• Intentar comprar boletos para la serie mundial de béisbol
La definición de un proyecto ayuda a diferenciar los proyectos y los programas; éstos son opera-
ciones en marcha que continúan de manera indefinida, y su alcance y duración son mayores que la
de casi todos los proyectos. A diferencia de los administradores de programas, los administrado-
res de proyectos luchan por quedarse sin trabajo lo más pronto posible. Sin embargo, debe obser-
varse que la admin istración de proyectos puede aplicarse (y con frecuencia se aplica) a programas
que están compuestos de proyectos múltiples. Por ejemplo, considere una línea de ensamble de
aviones. En un sentido, esta línea se puede ver como un proceso de ensamble continuo; pero en
otro, cada av16n se puede considerar un proyecto separado, donde se aplican las técnicas de AP a
cada avión en la Hnea de ensamble. Esta relación entre los proyectos y los procesos de producción
de flujo continuo se explorará con más detalle en otros capítulos.

No todos los proy ectos son igu a l es

En la mayor parte de este libro se analizan proyectos genéricos. Sin embargo, es obvio gue no todos
Jos proyectos son iguales. Un proyecto para el desarrollo de un nuevo software complejo es bas-
tante diferente de un proyecto para la construcción de una carretera. En el primer caso puede ser
difíc1l definir con claridad el diseño y alcance del proyecto, el ambiente externo cambia con rapi -
dez y el personal de TI que desarrolla el software suele estar involucrado en otras actividades y pro-
yectos. Por el contrario, la mayoría de Jos proyectos de construcción se realizan en forma aislada
respecto a otros proyectos; aunque por supuesto conúenen muchos factores de incertidumbre, casi
todos estarán de acuerdo en gue es más probable que un proyecto de construcción cumpla sus metas
que la mayoría de los proyectos de desarrollo de software. Además, es mucho más sencillo medir
el avance de un proyecto de construcción, donde el progreso (o la falta de é l) es visible, que el de
un proyecto de IT cuyo avance puede ir de O a 90% en Jos últimos minutos del proyecto.
Varios investigadores (entre Jos que se encuentran Yao y Souder, 1994; Brown y Eisenhardt,
1997. y Eisenhardt y Tabrizi, 1995) han estudiado diferentes tipos de proyectos y aseguran que los
distmtos tipos de proyectos necesitan estructuras organizacionales diferentes al igual que estrate-
gias y estilos de administración diferentes. Por ejemplo, una organización altamente centrali.zada y
 ¿QUÉ DEFINE UN PROYECTO? 5

jerárquica, con poca comunicación sería muy efectiva para Jos proyectos de construcción de carre-
te;:ras, pt:ro tal vez no sería lo mejor para el desarrollo de un nuevo producto con tecnología com-
pleja en un entorno de gran incertidumbre.
Con base en algunos estudios de proyectos de desarrollo de nuevos productos (o procesos o
servicios) basados en ingeniería, Shenhar (200 1) sugirió que los proyectos se pueden clasificar de
acuerdo con dos caracterísúcas: complejidad e incertidumbre. Como se indica en la figura 1 1, una
de las características indica el grado relativo de incertidumbre/riesgo tecnológicos en un proyecto.
que van desde p royectos de baja tecnología que usan tecnologías ya bien establecidas y estab les
(proyectos de construcción) hasta proyectos de muy alta tecnología que requieren desarrollar nue-
vas tecnologías durante el proyecto (el proyecto Apolo de alunizaje) A lo largo de este conttnuo,
Shenhar define proyectos de tecnología media y de alta tecnología. Los proyectos de tecnología
media usan una tecnología estable, en una nueva dirección (como mejora de productos); cstc tipo
de proyectos incluye a la mayoría de los proyectos industriales. Por otro lado, un proyecto de alta
tecnología representa un proyecto que puede estar aplicando una tecnología nueva por primera vez.
La segunda característica empleada para definir la taxonomía de la figura t.l, es la compleji-
dad del proyecto o alcance del sistema. Según Shenhar, un proyecto de complejidad limitada es "un
!>ubsisrema que realiza una función bien definida dentro de un sistema mayor, o puec.k ser un pro-
ducto independiente que realiza una sola función de escala limitada". Shenhar los llama proyectos
de ensamble. En el otro extremo del espectro de la complejidad están los proyectos de integra-
ción, proyectos geográficamentú dispersos que requieren la combinación de muchos subsiste-
mas complejos, por ejemplo la puesta en marcha de un sistema de planeación de recursos
empresariales (ERP, Enterprise Resource Planning), en una empresa multinacional grande. Entre
los proyectos de complejidad alw y baja están los proyectos d e sistemas; estos proyectos requie-
ren el dcs<u-rollo de numerosos subsistemas que, a sú vez, definirán un producto (o proceso o ser-
vicio). La taxonomía de Shenhar se representa en la figura 1.1.

FIGURA 1.1 Grado de

Taxonomta de Shenhar incertidumbre/riesgo
de los ttpos de proyectos
·-
tmplantacíón
Tecnología
de ERP en una
muy alta
multinacional

l . ... _., .... ... " .

Nuevo software Un radar

Tecnología
·~ con licencia avanzado
alta
codificada

Tecnología Nuevo teléfono

media celular

Tecnología Reparación
Construcción
baja ·de autos

Alto
Proyectos Proyectos Proyectos
de ensamble de sistemas de integración

Complejidad/alcance del sistema

6 CAPITULO 1 INTRODUCCIÓN A LA ADMIN ISTRACIÓN DE PROYECTOS

En todo este libro será útil conservar en mente la taxonomía de Shenhar. Como es de esperarse,
Shenhar encontró que la posición de un proyecto en su taxonomía tiene implicaciones significativas
en el diseño organiLacional, los sistemas de comunicación y control. la planeación y programación de
recursos, la extensión de las pruebas y en la necesidad de construir un prototipo. Conforme aumenta
la complejidad y el alcance del proyecto, por ejemplo, los proyectos requieren planeación y control,
y sistemas de comunicación más formales; las organizaciones relacionadas con estos tipos de proyec-
tos tienden a ser más grandes, más formales y con más burocracia. Estas implicaciones se estudian
con más detalle en el capírulo 3.
Una taxonomía alternativa para los tipos de proyectos de clesan·ollo fue sugerida por Wheel-
wright y Clark (1992) quienes también clasifican a los proyectos en <.los dimensiones: el grado de
cambio del producto y el grado de variación en el proceso de fabricación. Usando este esquema
de clasificación bidimensional. los autores identificaron varios tipos de proyectos que requieren
diferentes ni\'eles de recursos y estilos de administración. Por ejemplo. en el área de poco cambio
en el producto y e l proceso idemificaron provectos derivados como proyectos que realizan mejo-
ras relativamente menores a los productos exi~tentes. Según WheehHight y Clark Jos proyectos
derivados producen mejoras en el producto y/o en el proceso (por ejemplo, una modificación en e l
empaque, una característica nueva o mejoras en la calidad). Los proyecTos de pfaraforma realizan
modificaciOnes significati,·as en el producto y/o el proceso. pero evitan los cambios importantes
yue se presentan en los proyecTos inno,·adores. Los dos pnmeros tipos dan como resultado mejo-
ras Significativas en el producto y/o el proceso basada~ en tecnologías desanolladas y probadas (los
eJemplos incluyen la computadora iMac de Applc y algunos modelos nuevos de automóviles); los
proyectos de mnovación representan productos y procesos radicalmente nuevos (como el trasbor-
dador espacial de la NASA y el desanollo de los teléfono~ celulares). Los proyectos innovadores
dan corno resultado el desarrollo de nuevos mercados; estos proyectos tienen un alto grado de
nesgo y complejidad. La taxonomía sugerida por Wheelwright y Clark se presenta en la figura 1.2.

FIGURA 1.2
Taxonomía de proyectos
sugerida por
A lto
Wheelwrighl y Clark Producto de
base nueva

Producto de
la siguiente
gcnerac1ón
Cambio en
el producto
Adición a
un producto

Proyectos
derivados

Derivados
y mejoras
... Ba¡o

Cambio Aclualización Proceso de Proceso de

incremental en un solo la siguiente base nueva
departamento g en erac1ón

- - - -- - - Cambio en el proceso - - -- - -+
Bajo A lto
 MEDIDAS DE ÉXITO O FRACASO DE UN PROYECTO 7

PHOE"\IX, 4 de abril-No hace muchos años que Fife Symington consideraba orgullosamcnte como
su mayor logro el bienestar fiscal de Ari1.ona. Como gobernador durante la mayor pane de Jos ,u1os 90,
pr~sidió las acciones para reducir los impuestos, aumentar los ingresos y mejorar las mversioncs de
.~;apit:tl, una gesuón qul! lo convi rtió en una nueva estrella del Parudo Republicano.
Actualmente, las principales causas de orgullo profes ional del señor Symington incluyen un pastel
de queso cub1erto con queso crema italiano. un merengue helado relleno de crema de amarew y un pas-
tel de chocolate ~;on sabor a café, conocido como el Gobernador, su postre de ftrma. que promete "bajos
impuestos y alto sabor".
l'vlicntras OI IOS ex políticos se integran a la vida como ahogados, activistas o cj~cutivos corporativos,
el señor Symington es ese raro servidor público que se ha convertido en un chef tic repostería. Casi todas
las mnñJnJs, SJlc a trabajar a Franco's !tallan Caff¿. un nuevo rc!itaurame aquí, donde crea postres: el
dueño, Franco Fazzuolli, insiste que son tan populares como los apcritivos, entradas y p17.Zas que ofrece
en sus restaurantes en Maohauan --donde era propietario de Pome Vecch10, Cent'Anni y Zinno- ames
de cambiarse al oeste.
"Hay que poner atención en muchas cosas" dijo el otro día. "Siempre hay una ruta crític:.t para lograr
un menú o una comida, hay mucha presión. Pero también tiene su encanto trabaj.lf con un rr.aravilloso
grupo de personas en la cocina. Hny a quienes no les gustaría. Yo pienso que es mágico."
Fueme: M1chael Janofsky. "Di! la política a los pasteles: nueva vida para ex gobernador de Anzona", New York Times,
6 de abril del 2003.

MEDIDAS DE ÉXITO O FRACASO DE UN PROYECTO

Como la mayoría de los proyectos tienen metas de costo y tiempo claramente detinido::., es común
que se juzgue el éxito de un proyecto según s i terminó de ntro del presupuesto y antes de In fecha de
entrega Sin embargo, taJ juic1o puede resultar un poco ingenuo en el sentido de que la mayor parte
de los proyectos tienen muchas me tas ade más del presupuesto y la programación. Por ejemplo,
.. satisfizo el proyecto las espccificaciones?. ¿tuvo ¿xito el proyecto en el mercado?. ¿tuvo éxito en
aumentar la participac ió n de mercado, los ingresos. las ganancias, etcétera, a largo plazo?, ¿propor-
cionó el proyecto a la organ ización el aprendizaje que dará a proyectos futuros una mayor posibili-
dad de éxtto?
Por eJemplo considere el desarrollo de la película Tiranic que se presentó en 1997 después de
varios años de trabajo. Cuando finalme nte se presentó. la película tenía un retraso significativo res-
pecto a su plazo de entrega y $90 mil lone::. ar riba de su presupuesto o riginal de S 1 lO mi !Iones (un
costo 82% superior a lo previsw). Sm embargo, la película claramente tuvo éxito en el mercado,
ganó numerosos premios (inc luyendo la mejor pelícu la de 1997) y se convirtió en la primera pe lí-
cula de la hiswria que obwvo más de mil millones de dólares de ingresos. Este proyecto ¿fue un
éxito o un t'racaso?
En algunos casos los proyectos pueden fracasar aun cu::10do terminen a tiempo y d~n tro de l
presupuesto, como ocurrió con el proyecw Mars Lancler (vea el artículo adjunto). Aun cuando el
:Vtars se estrelló en el aterrizaje, e l proyecto no fue un fracaso tota l en el sentido de que generó
conocimientos nuevos que pueden proporcionar a la NASA una mayor posibilidad de éxito en
misiones futuras. En otros casos. los proyectos pueden emprenderse como "líde res de pé rd ida"; es
dec1r, una organización puede iniciar un proyecto que sabe que tendrñ pérdidas con objeto de ganar
una ventaja competiriva, cuando concurse por contratos futuros de proyectos similares, o p~tra ejer-
cer una presión competitiva sobre un rival en un mercado específico.
.:.. Aun cuando e l costo y el tiempo son los objetivos primordiales de un proyecto, tal vez sea difí-
cil o incluso poco realista lograrlos, en especial cuando fueron establecidos por adm inistrado res de
alto nivel que no están directamente involucrados en el proceso de planeación de proyectos. Según
8 CA PfTU LO 1 INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS

Frable (1990), "establecer plazos cortos en extremo parece haberse convertido en un asunto de
honor entre ciertos dueños y administradores de proyectos" . No es de sorprender que la empresa
asesora de AP, Robbins-Gioia Inc., informe que 44% de todos los administradores de proyectos tie-
nen costos superiores, entre 10 y 40%, a lo previsto y que solamente 16% de Jos administradores
cumplen de modo estable sus plazos de tenninación. En otro estudio (The Economist, 2000) se
informó que "alrededor de 85% de todos los proyectos de TI del sector público se consideran fra-
casos". El autor agrega, "esto no significa que sean un desastre total, sino que suele llevar más
tiempo ponerlos en marcha, cuestan más y proporcionan menos de lo que se planeó".
En un estudio para analizar el desempeño de los proyectos y asuntos organizacionales, Might
y Fischcr (1985) definieron seis medidas de éxito de un proyecto:
1. General: ¿cuál es la percepción general del éxito de un proyecto?
2. Costo: ¿es el costo final superior o inferior al presupuesto inicial?
3. Plazo: ¿el tiempo de tenninación fue mayor o menor que el programado?
4. Meta técnica 1: ¿cuál es la percepción general del desempeño técnico del proyecto
comparado con las especificaciones iniciales?
5. Meta técnica 2: ¿cuál es la percepción general del desempeño técnico del proyecto
comparado con otros proyecws de la organización?
6. Meta técn ica 3: ¿cuál es la percepción general del desempeño técnico del proyecto
comparado con los problemas encontrados durante el proyecto?
Might y Fischer consideraron también la posible correlación enLre estas medidas: ¿es más proba-
ble que un proyecto que cumple las especificaciones técnicas iniciales se considere un éxito res-
pecto a la segunda y tercera metas técnicas? En su estudio de 103 proyectos de desarrollo, Might
y Fischcr encontraron una correlación positiva (0.68) entre las metas de costo y de tiempo, lo que
implica que es más probable que los proyectos que se retrasan incurran en costos excedentes. Sin
embargo, algunas otras correlaciones indican que los administradores tienen que elegir entre las
metas técnicas por un lado y las de costo y tiempo por el OLrO. Los coeficientes de correlación
encontrados por Mighr y Fischer e ntre las medidas de éxito de un proyecto se dan en la figura 1.3.
Cuatro de estas seis medidas son más bien subjetivas (sólo las metas de costo y tiempo tienen
alguna base objetiva), enfatizándose así la importancia de satisfacer las expectativas para lograr e l
éxtto de un proyecto.
¿Por qué fracasan tantos proyectos en el cumplimiento de las expectativas? Un estudio de
Hughes (1986) aclara aJgunas de las causas de fracaso de un proyect.o; según Hughes hay tres fac-
tores principales:
• Una falta de comprensión de las herramientas de AP y un exceso de confianza en el
software para AP

FIGURA 1.3
Correlación entre las Éxito
medidas de éxito de global del Meta Meta Meta
un proyecto proyecto Costo Programa técnica 1 técnica 2 técnica 3

Éxito global del proyecto 0.55 0.54 0.68 0.42 0.37

Costo 0.68 0.30 0.32 0.41
Programa 0.36 0.29 0.40
Meta técnica 1 0.55 0.20
Meta técnica 2 0.28
Meta técnica 3

Fuente: R. Might yW. Fischer, 1985.

 MEDIDAS DE ÉXITO O FRACASO DE UN PROYECTO 9

• Problemas de comunicación
• No se aj usta de modo adecuado a los cambios que ocurren en el curso del proyecto
Además, Hughes observó que muchos administradores pierden de vista el proyecto al concen-
trarse en el software para AP y administrar la red de precedencias en lugar del proyecto. La obser-
vación de Hughes, también señalada por otros (incluyendo al autor), es una de las razones por las
que este libro no hace énfasis en el software para AP (aunque por supuesto se menciona), sino que
se enfoca en los conceptos bás icos y los trueques que los administradores deben comprender con
objeto de terminar con éxito un proyecto.
Hughes también observó que muchos administradores de proyectos no recompensan las accio-
nes de los empleados del proyecto que más contribuyen a las metas más importantes. Aunque puede
ser difícil detenninar el beneficio relativo a acciones individuales, Hughes hace notar que tales
recompensas pueden pagar dividendos significativos.
La comunicación es uno de los factores que más contribuyen a los resultados del proyecw;
Michalski (fOOO) observa e n su estudio de proyectos de biotecnología que "la buena comunicación
es la clave para una exitosa adrrúnistración de proyectos". Hughes indica que los proyectos fraca-
san cuando hay demasiadas personas involucradas en ellos, pues dificulta la comunicación, pero
que ningún proyecto ha fracasado por tener muy pocas personas. El fracaso también se presenta
cuando los administradores no comunican con efectividad las metas del proyecto a los otros parti-
cipantes y se centran en detalles poco importantes. A este respecto, el desarrollo de la tecnología
de la información ayuda a resolver los aspectos de comunicación; Internet, las máquinas de fax y
aun los teléfonos celu lares contribuyen a facilitar la comunicación entre los administradores del
proyecto y los equipos, los clientes y los conrratistas (Schm idt, 2000; Bagli, C. , 200). Los proble-
mas de comunicación y coordinación se revisan con más detalle en el capítulo 3.
Por último Hughes señala que los administradores no se ajustan a los cambios que siempre se
presentan durante la vida de un proyecto. Para adrrúnistrar con éxito un proyecto, un adrrúnistrador
debe incorporar todos los cambios en los planes, el presupuesto y los programas actualizados de
manera expHcita y comunicar estos cambios a todas las personas relacionadas con el proyecto.
Las conclusiones de Hughes son notablemente congruentes con los hallazgos de otros autores.
Exarrúnando numerosos estudios de casos de AP, Pinto y Slevin (1987) encontraron nueve facwres
cru~iales para e l éxito de muchos proyectos:

• Objetivos claramente definidos

• Administrador de proyecto competente
• Apoyo de la alta administración
• Miembros competentes en el equipo de PM
• Asignación de recursos suficientes
• Canales de comunicación adecuados
• Mecanismos de control
• Capacidades de retroalimentación
• Buena respuesta al cliente
Aunque Pinto y Slevin no indican la importancia relativa de estos factores, según varios estu-
dios parece que tener objetivos claramente definidos, e l apoyo de la alta adrrúnistración, la comu-
nicación adecuada y los mecanismos de control y retroalimentación son factores esenciales. Contar
con estos factores no garantiza el éxito del proyecto, pero es claro que el no tenerlos aumenta sig-
nificativamente la posibilidad de fracaso.
Muchos de los factores relacionados con el éxito y fracaso están interrelacionados; es decir,
cuando mejora un factor, con frecuencia mejorarán otros. Por ejemplo. considere el uso de software
para AP que ofrece la ventaja de ayudar con la programación, el presupuesto y el control del pro-
yecto. En este caso, lós paqDetes de software también pueden mejorar la comunicación entre los
10 CAPITULO 1 INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS

Considerado uno de
los mejores parqu es de
béisbo l constru idos en
los últimos años, Safeco
Field costó en tota l 350
mi llones de dólares, casi
100 millones más que su
presupuesto original.
Algunos responsables
afirman que tos
excedentes en costo
fueron el resultado de
una mala admin istración
y negl1gencia

participantes en el proyecto, en especial el software para AP basado en Internet que proporciona

también una retroalimentación decisiva y mecanismos de control.

Resulta do s de un proyecto de tecnolog ía de la información

Los proyectos de tecnología de la información (TI) tienen una tasa de fracaso alta debido al enorme
riesgo asociado a estos proyectos. Después de estudiar muchos proyectos de TI, Flowers ( 1994)
concluyó que todo proyecto de TI será un fracaso si:
• "el sistema como un todo no opera como se esperaba y si su desempeño global no es
ópti mo";
• "al implantarlo no se comporta corno se p retendía originalmente o si es tan hostil para
los usuarios que lo rechazan y lo usan poco"; ·
• "el costo de su desarrollo excede cualquier beneficio que pudiera producir durante su
vida útil", y
• "debido a proble mas con la complejidad del sistema o con la administración del pro-
yecto, se abandona el desarrollo del SI antes de terminarlo".
Un examen del esfuerzo realizado por la Health Care Financing Administration (HCFA; orga-
nismo que administra el plan Medicare de Estados Unidos), para desarrollar un sistema de TI para
administrar las reclamaciones de Medicare, arroja más información sobre las causas del fracaso de
un proyecto de Tl (vea el apéndice al final del capítulo). Frie! (2000) describió recientemente el
desafortunado esfuerzo realizado por HCFA para desarrollar un sistema de tramitación Medicare
que al fina l fue abandonado desp ués de seis años de desarTollo y $50 millones en costos. Después
de estudiar el fracaso del proyecto Frie! concluyó que del caso HCFA podían aprenderse las
siguientes lecciones:
• Establecer una programación realista.
• Saber q ué se quiere antes de pedirlo.
• Evitar que la misión pase inadvertida.
• Te11er un proceso de revisión de las inversiones.
• Manejar las expectativas.
• Reducir Jos riesgos tanto como sea posible.
 MEDIDAS DE ÉXITO O FRACASO DE UN PROYECTO 11

Friel señalo que HCFA había dado tres años al principal contrati5ta para presentar el producto
final, con poca o ninguna supervisión en el ínterin . Este error de no definir programas adecuados y
no v¡gilar el progreso del proyecto fue uno de los principales factores para el fracaso. Frie! men-
ciona que los administradores de HCFA no conocían por completo su sistema actual, ni lo que que-
óan que hiciera el nuevo sistema (no hubo objetivos identificados con claridad). Debido a esta falta
de entendimiento, los administradores de HCFA hacían numerosas modificaciones a las especifi-
cacJOnéS del nuevo sistema. ocasionando retrasos significativos y aumentos en los costos. Tamb1én
por la falta de conocimiento, la HCFA con11nuamente agregaba nuevos rcquenmientos al proyecto,
confonne sus administradores entendían más el func ionamiento de su propio sistema.
La comunicac ión fue también un problema. Según Friel, HCFA "prometió la luna y entregó
mucho menos". Es eviden te que la complej idad de l sis tema y la cantidad de personas involucra-
das aumentaron los problemas de comunicac ión en HCFA. Por último, la HCFA no implantó
incentivos y controles adecuados para sus contratistas ; Frie! indica que ahora HCFA ha cam-
biado, en sus proyectos de Tl, a contratos basados en el desempeño con la programación y los
incentivos adecuados.
Muchos de los proyectos de TI se emprenden sin establecer un propósito o visión claros, como
se ve en el proyecto de la HCFA. Más aún, cuando se establecen. con frecuencia no se comunican
al reslO del equtpo o de la organización del proyecto. qn segundo tema rdacionado que parece
común a muchos proyectos de TI, e.s no establecer metas realistas. No es de sorprender que esto
ocurra con frecuencia cuando la alta administración no incluye administradores de proyectos y
miembros del equ ipo en todas las etapas del proceso de planeación. La fa lta de una comunicación
efectiva parece ser un ingrédiente importante en la mayoría de los fracasos de proyectos de TI.
Por último, el fracaso de muchos proyectos de TI puede atribuirse a factores exógenos a la
organización La tecnología sigue cambiando con·· paso rápido y las predicciones que Gordon
Moore hizo en 1965 se siguen cumpliendo: cada dieciocho meses la velocidad de los procesadores
y la capac1dad de la memoria parece duplicarse por el mismo costo. La implicación es clara. En un
proyecto de TI que dura más de un año, lo más probable es que la tecnología sea obsoleta al tenru-
nar el proyecto, suponiendo que el proyecto termina a tiempo.

¿Cuándo "abandonar" un proyecto?

Relacionado con el tema del éxito o fracaso de un proyecto está saber cuándo abandonar un pro-
yecto en marcha. Suspender un proyecto sign ifica que debe existir un sistema efectivo de control y
supervisión, así como métricas que indiquen cu:indo el proyecto ha llegado a un punto en el que ya
no es efictente salvarlo. Es claro que esta es una decisión difícil y un reto en la mayoría de las orga-
nizaciones donde administradores y empleados están comprometidos con la terminación exitosa de
un proyecto.

't ~ .- e :.f.• f\!1-~r-~.-;c[f!..-...,1

~:~:0.:~'"''··.:;:
....~ -rl'~;.¡~~~~
. . ·~-~ ~~ t :},
·~--:;.·;~ . ~~:t~~~~:~~-:-- . . . ·."-l' .• ·
¡;,;¡¿~~~~~--:-»-·~~~....-
Las recientes fal las e n dos misiones a Marte s ugieren que la NASA se está presionando demasiado para
hacer más con menos din~~o y que está arriesgando el éx.ito al d~ una atención inadecuada a los ries-
gos, dijeron hoy dos paneles de examinadores. En su segundo informe al organismo, el consejo q ue
revisó la falla de la misión Mars Climate Orbitcr el año pasado dijo que las lecciones obtenidas de este
percance y de otras fallas con el enfoque de hacerlo más rápido y más barato indicaron que tal vez hubo
demasiado énfasis en reducir los gastos y realizar las misiones rápido. "El éxito de 'más rápido, mejor
y más barato' se contrarresta por el hecho de que algunos programas y proyectos han dado demasinda
importancia a la reducción de costos y tiempos", dijo el panel, el Mars Climate Orbiter :vlishap
Invesugation Board, un grupo de expertos de la NASA presididos por Arthur G. Stephenson, directOr de
Marshall S pace Fligh Center
' - .._
en
Ahibama.
, • , ~-. -
. . ; ~·· ' . ·.::
• .... • ":>0 ;- . , ...: ... ~ ... ·-~ • • •

Fuente: W. Lc¡u-y, New York 7imes, 14 de marzo del 2000.

12 CAPiTULO 1 INTRODUCCIÓN A LA ADM INISTRACIÓN DE PROYECTOS

Perder de vista los THE FAR S/()E• por(ib.RY lARSOW

objetivos de un proyecto
·- ·--,..,.,.~ .. o - -
puede llevar el proyecto
al fracaso.

"01gon ·-esperen un maldito m1nuto,

... olvidamos al gonado"

Staw y Ross (1987) tr::~tan este tema con más detalle, indicando que con frecuencia es bené-
fico para una organización diseñar un proyecto en forma modular. De esta manera, es posible que
la organización obtenga ganancias de un proyecto que se abandona antes de tiempo. Staw y Ross
crtan el proyecto del Túnel Profundo en Chicago hace varios años, como un ejemplo de un proyecto
así En ese caso el proyecto (para actualizar el sistema de drenaje de la ciudad) se diseñó de modo
que beneficiara a la ciudad sólo cuando estuviera terminado por completo. Cuando se interrumpió
el proyecto debido a falta de presupuesto, Chicago no tenía nada q ue mostrar como resultado de
sus esfuerzos y gastos considerables.
Cuando las fuerzas cambiantes del mercado hacen evidente que el proyecto no puede tener
éxito, los administradores deben interrumpir el proyecto prematuramente. Esto es crucial en espe-
cial en proyectos de TI debido a la naturaleza de cambios rápidos de la tecnología subyacente.
Es comprensible que muchos administradores se muestren .renuentes a abandonar un proyecto,
ya que carrera y ego se vinculan a Jos proyectos. También la fa lacia de los costos no recuperables
JUega un papel imponante (¿cómo vamos a terminar un proyecto cuando ya hemos invertido millo-
nes de dólares?). El resultado es que los proyectos continúan mucho más allá de un punto "sin
regreso" (o con regreso "negativo").
Para evitar este problema, los administradores deben supervisar y controlar los proyectos con
cuidado. En la etapa de planeación es necesario definir -y después hacer cumplir-los puntos cru-
ciales donde un proyecto debe de abandonarse si es necesario. Esto se disc ute ampliamente en el
capítulo 8 que se ocupa del tema de supervisión y control.

CICLO DE VIDA DE UN PROYECTO

Existen muchas maneras de ver el ciclo de vida de un proyecto. La figura 1.4 presenta una inter-
pretación que define cuatro etapas:
1. Formulación y selección
2. Planeación
3. Programación y control
4. Implantacrón y terminación del proyecto
En la primera etapa (formulación y selección), los administradores definen (y refinan) el pro-
yecto y su alcance, y consideran su impacto e n el plan estratégico de la organización. Suponiendo
 TRUEQUES EN LA ADMINISTRACIÓN DE PROYECTOS 13

FIGURA 1.4
Ciclo de vida de un
proyecto

"'
"

Tiempo
Et~pa 1 Etapa 11 Etapa 111 Etapa IV
=-.:·o.ul~c:on Planeación Programación lmplantacrón
·, s=:¿cc ..Sr. y control y terminación

que el proy~.:-w s<! elige para desa•rollarlo, los administradores procederán a una planeación más
detallada en 1:1 segunda erapa. En e lla definen las tareas específicas que constituirán el proyecto y
est1man los recursos (trabajadores, materiales, etcétera) que serán necesarios para terminar con
éx•to el proyecto. Como parte de la etapa de planeación. los administradores deciden qué tareas se
subconrr..tc.:1.r:in y ddinen las licitactones para estas tareas. La etapa de planeación es crítica; es aquí
que se define la regla 6P de la administración de proyectos:
Prior Planning Precludes Poor Project P erformance
(la planeación previa previene un pobre desempeño del proyecto)
El trabJjo en el proyecto es más intenso durante la tercera etapa; como se indica en la fi g ura
l 4, los recursos asignados a l proyecto alcanzan su máximo en esta etapa. Por último, en la cuarta
etapa el proyectO se implanta y se entrega a los usuarios (ésta es la erapa en la que los usuarios
ocupan un nuevo edificio o en la que se inserta una nueva componente al proceso de ensamble).
En d segundo capítulo se analiza con más detalle esta perspectiva del ciclo de vida de un pro-
yecto, así como el micio y selección del proyecto y la etapa de planeación del proyecto. l a rela-
ción emn: planeactón, progr:\mación y funciones de control se indica en la figura 1.5.
Como se ve en la fi gura 1.5, en la etapa de planeación el equipo del proyecto determina un pro-
nóstico base para el proyecto que sirve como punto de comparación o evaluación (benchmark) del
desempeño futu ro. Después, conforme se realiza el proyecto , el equipo vigila las desviaciones de
este plan de evaluación. El problema de controlar el proyecto se convierte en un problema de de ter-
minar si estas variaciones sor1 el resultado de fl uctuaciones aleatorias o representan un problema
estrucrural que debe ser atend1do por el equipo del proyecto. Cuando ocurre esto úhimo, e l equipo
del proyecto dt.:be emprender las acciones necesa.~ias para que el desempeño del proyecto quede de
nuevo bajo control.

TRUEQUES EN LA ADMINISTRACIÓN DE PROYECTOS

La administración de proyectos se puede ver como una serie de trueques entre objetivos múltiples;
los administradores tienen que decidir cuáles son las metas más importantes, y cuáles se pueden
relaJar, con objeto de lograr un éxito global para la organización. Por ejemplo, e n muchos proyec-
tos de desarrollo de un nuevo producto, el tiempo para lanzar los al mercado (o sea, la programa-
ción) es la meta más importante. mientras que la meta de presupuesto puede ser de menor
consideración. En otros proyectos donde el presupuesto es la mayor preocupación, ta l vez los admi-
nistradores deban revisnr el diseño y las especificaciones dt.:l proyecto a fin de terminar el proyecto
a tiempo y dentro del presupuesto señalado. Los administradores de una organización también tie-
nen que considerar los trueques entre la cartern de proyectos en curso y IÓS futuros, así como el
14 CAPÍTULO 1 INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS

FIGURA 1.5 Planeación del proyecto

Relación entre
planeación, WBS
programación y
control de un
proyecto

A ..

Program ación
del proye cto Co ntro l del proyecto

Red de
precedencias
Datos del
Desviaciones desempeño
1~ ·~ ~

(E¿
- 1
del plan real de la tarea 1

--~- ·- 1
1
1

.. -- 1
1

1
-- 1

Diagrama de Gann 1
1
1
1

1-=-- Tiempo Informes

1
1

periódicos
·- -··- --- de costos

Selección de
programación ~ ~-
-

- ..
1
CostoiX 1
1
1
Tiempo 1

- -- 1
1
1
1

Asigneci0n t;l<;> l - ....A.~.:.~.t;J:..

+.-.:4---R-..., ____
............ ':''11~
recursos ·-

• !"-''~..
•

~~!.1>~~ ..~;.. -~ "'

..

• 7:J[rlplilñt~ción{.
' ·J-- ·

~;.
.J;•, . . . .

:;;. ~d.;J,.PJ* ~ ~.:

-~~.,
·~ ~=-r-- . . . .. ,.,.i
.. g
'¡:;:~~~,,,..·:· "F,

----=""'
.. ~ ~-. --- -

rápidamente cambiante entorno tecnológico. Todos estos factores determinan la importancia rela-
tiva de cada proyecto y el nivel de recursos que se le pueden asignar.
Estos trueques pueden visualizarse si el proyecto se ve como un cubo en el que cada eje repre-
senta una meta importante del proyecto: costo, tiempo y alcance, con la calidad como cuarta
dimensión. En la figura 1.6 se representa la relación entre estas dimensiones.
 TRUEQUES EN LA ADMINI STRACIÓN Dé PROYECTOS 15

FIGURA 1.6
Tru eq ues e ntre tiempo, ., .
Diseño/ A lcance
cos to y diseño de u n
proyecto
.
~.... . . . .. .. .......
.- .. . .
~ • :r .~ ' .....: ' ..:. 4
Desempeño"' .. . ..
reque rid o ~~ ~- ..... ' '.i:· . '-

..· ......... : .· .-
,.
... -· .· :-.'~ .
•.1
.-.. ..';: :\:. ...,~
~ ~... '
'"~ ~--~( ;..,.,~~i.~~.'
• ..... ·..-·~--~~..,
~tl
•~
\:.;:· .-~-.LJ ··t·~'.~..:.'.:·,_:
' • •.
-·~: .- . ..~ ~)> ::~~ ~.:
,:.. • ""\ . t ..
•
,..
: _/ ,, 1 -~·
'f:- Trueque
tiempo-costo
.:· ...
óptimo

- . ':
e LID D

.."-.....·
'! ~ ...
Tiempo·
.:

Mllchos administradores de proyectos expetiml!ntados saben que en ténninos n::alistas p u ~;den

lograr una (o quizás dos) de estas metas en casi todos los casos. Dado que la meta de la calidad es
la menos vistble y la más difícil de medir, con frecuencia no se logra en los proyectos. Si el alcan-
ce se mantiene constante, es comprensible por qué las metas de costo y tiempo a menudo no se sa-
tisfacen.
En la et:~pa de planeación del proyecto, Jos administradores suelen suponer que una o más
metas son com;tames (como el alcance) y optimizan los objetivos restantes (como e l truque ttempo-
costo) Esto ocuríe con frecuencia en situaciones de licitaciones, es decir, el diseiío se considera
fijo y el cltcme propone uo presupuesto. El licitador. dado un diseño fijo, sólo puede competir con
base en el u~mpo y el costo (es raro que se tome en cuenta la calidad en estos mtercambros). Sin
embargo, cada vez más o rgan izaciones reconoce n la necesidad de cons iderar trueques simultáneos
entre las cuatro dimensiones. Para lograr esto, las empresas están usando equipos de proyecto mul-
tifuncionales (equipos de diseño-construcción), en lo::; que se mvolucra al contratista en el proceso
de diseño. así como en la determinación de l costo y la programación. Las empresas j aponesas. así
co mo algunas empresas estadounidenses, han empleado con gran éxito l!Ste enfoque.
Beck y Cleal ( 1999) van m<ís all:í. y sugieren que las organizaciones hagan contratos de
"alcance opc ional"; estos contratos requieren que e l proveedor cumpla las metas especiticadas
de tiempo, costo y calidaa. pero es libre de cambiar el alcance del proyecto. De este modo un con-
tratiSta, que encuentre problemas inesperados, puede modificar el alcance del proyecto, pero deberá
mantener las metas de tiempo, costo y calidad establecidas. Beck y Cleal afirman que un provee-
dor con un contrato de este tipo tendría aún e l incentivo de terminar un diseño razonable, con la
espe ranza de obtener otros contratos. Argumentan q_.e tales contratos podrían sa efectivos si en
ellos ~e mantJenen plazos conos y si hay un método claro para medir la calidad del proyecto •

'Alg uno s opman que los trabajadores subcon1ra1:1dos por muchas empresa~ reprcsc111:tn de hecho contratos d<!
"alcance opci onal".
1G CAPITULO 1 INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS

ALCANCE DE ESTE LIBRO

Este libro se ocupa de Jos aspectos de trueques o intercambios entre estaS cuatro dimensiones y de las
herramientaS y técnicas disponibles para ayudar a los admjnistradores en la toma de decisiones. Una
mejor comprensión de trueques conduce a mejores decisiones y mejor administración de proyectos.
Además, el libro hace hincapié en las herramientas disponibles para los administradores de
proyectos incluyendo la mayor parte de los paquetes de software para AP. Aunque el uso de estos
productos es amplio, tienen limitaciones significativas en su capacidad para analizar muchos de los
trueques o intercambios complejos que se presentan en casi todos los proyectos.
Para proporcionar un marco más general para el aná lisis de trueques en AP, se presentan varios
modelos en hojas de cálculo a lo largo del libro. El lector debe te ner en mente que la mayoría de los
paquetes de software dispunibles en el mercado hoy en día, son sólo a lgo más que modelos especia-
lizados en hojas de cálculo; todo lo que hace la mayor parte de los productos de software para AP
se puede hacer con una hoja de cálculo (aunque tal vez no tan rápido o tan sencillo). Sin embargo,
para proyectos pequeños los modelos en hojas de cálculo ofrecen mayor flexibilidad. Por ejemplo,
los administradores de proyectos pueden usar las características de optimización de los modelos en
hoja de cálculo para analizar los trueques (algo que no suelen incluir los productos de software para
AP). También pueden usar el generador de números aleatorios integrado en casi todo el software de
hojas de cálculo y construir modelos de simulación Monte Cario para analizar el riesgo de un pro-
yecto. Esperamos que el uso de modelos en hojas de cálculo proporcione al lector una mejor com-
prensión de las decisiones de truques que deben tomar los adm111istradcres de proyectos, así como
del software para AP existente como ayuda en la toma de estas decisiones.
Por último, debe mencionarse de manera explícita que la admims1ración de proyectos, igual
que la administración en general, es en esencia una actividad práctica. Es como andar en bicicleta:
muy difícil o casi imposible aprenderla en un libro. Sin embargo, el autor espera que este libro sen-
sibilice a los administradores de proyectos en cuanto a los aspectos que deben considerar al admi-
nistrar proyec1os complejos. Al enfocarse en los trueques y problemas de AP, Jos administradores
de proyectos 1endrán una mejor comprensión de Jos factores que llevan a los distintos resultados
(tanto buenos como malos) de los proyectos, y al hacerlo serán más capaces de manejar con efec-
tividad estos factores.

ADMINISTRACIÓN DE lOS RIESGOS DE UN PROY ECT O

Una parte crucial de la adminjstración de cualquier proyecto es definir y analizar los riesgos aso-
Ciados con ese proyecto. Los riesgos de un proyecto están definidos por dos elementos: 1) la pro-
babilidad de algún evento o resultado adverso y 2) la severidad o costo de ese evento o resultado.
La probabilidad de cualquier evento tiene influencia de factores tanto exógenos como endógenos;
por ejemplo, el mal tiempo (un factor exógeno) o la mala admirústración (un factor endógeno) pue-
den retrasar, de igual manera, la terminación de un proyecto. En cualquier caso, los costos para la
organización pueden ser los mismos (costos de retraso, pérdida de la confianza del cliente, elcé-
tera); sm embargo, a diferencia del mal tiempo, la mala administración a menudo puede evitarse.
Es1e ejemplo ilustra otro factor importante en la admmistración de riesgo. Después de analizar
los eventos adversos que pueden presentarse, el administrador de proyectos tiene dos opciones:
puede tomar algunas medidas preventivas antes de empezar el proyecto para reducir la posibilidad
de eventos adversos o de sus consecuencias, o puede planear algunas acciones de contingencia en
caso de que ocurra un evenro adverso. En e l caso de mal tiempo, el administrado r de proyec10s
puede colocar cubiertas o resguardos a una construcción (por ejemplo); esta acción preventiva
aumentará el costo del proyecto, pero mitigará el impacto negativo si el tiempo se vuelve incle-
mente. De manera alternativa, el administrador puede planear agregar trabajadores al proyecto en
el caso de que el tiempo cause retrasos en el programa. Este plan de contingencia se pondrá en mar-
cha sólo SI en realidad ocurre el evento negativo (mal tiempo).
;
 HISTORIA DE LA AOII.IINISTHAl:IUN Ut I"'HU• co...tu:. ''

En todos los proyectos hay numerosas fuen tes de incertidumbre, como variaCIOnes nlemorias en
el desempeño de una componente, datos inexactos o incompletos y no tener la posibilidad de hacer
un pronóstico por falta de infom1ación, experiencia o prevención. Para reducir el t icsgo general de
los proyecLOs, muchas organizaciones usan diferentes enfoques, que incluyen la selección de una
cartera de proyectos para minimizar e l riesgo, de la misma manera que un Invers ionista diversifica
una cartera de acciones. Subcontratar parte (o todo) el proyecto es otra manera de disminuir el riesgo
del proyecto; el tipo de contrato firmado con un contratista tiene implicac10ncs significativas en
cuanto a cómo se distribuirá el riesgo entre los interesados.
Los administradores de proyectos también deben reconocer que el reverso del riesgo es el
beneticio potencial. El riesgo abre nuevas oportunidades a una organ1zación para expandir su línea
de p10ductos, mejorar sus produclOs y mejorar su base de conocimiento. Entre mayor es el riesgo,
mayor será el beneficio potencial. El asunto no es controlar el riesgo, sino manejarlo.
Por último, hay que hacer nowr que la mayor parte del software de AP no LOma en cuenta el
riesgo directamente. Sin embargo, al usar los modelos de hoja de dlculo de este libro, los admi-
nistradores de proyectos podrán aprender cómo analizar el nesgo como parte de un plan del pro-
yecto. Los temas de análisis de riesgo y de admjnistración de riesgo se anali.~:an con más detalle en
el capítulo 7.

HISTORIA DE LA AD M INISTRACI ÓN DE P R OYECTOS

Desde el comienzo de la historia ha habido administradores de proyectos. De hecho, algunos teólo-
gos dirán que el primer adminjstrador de proyectos creó el cielo y la tietra en siete días (con un día
adicional como amortiguador para contingencias inesperadas). Muchos proyectos, como las pirámi-
des egipcias de Giza (2590 AC), el Coloso de Rodas (292 AC - 645 DC) y el Astrodomo de Houston
(1965), proporcionan ejemplos de una bue na administración de proyectos de construcción masiva.
Sin embargo, otros dos proyectos tuvieron quizá el mayor impacto en el desarrollo y pníctica de las
metodologías de administración de proyectos (Fondahl, 1987).
Al final de los años 50, los ingenieros de DuPont Corporation e~taban preocupados por el
ttempo de paro para mamc!rtimienw en su planta e n Louisville, Kentucky, que se había convertido
en un cuello de botella en su proceso de producción de neopreno. Para evitar la construcctón de
otra planta. los ejecutivos de DuPont contrataron a la empresa Camlttyc Construction Company
para que estudiara la planta de Louisvil le y sugiriera una manera de reducir el tiempo ele manteni-
miento. El estudio, que indicaba que era posible disminuir significativamente el tiempo de mante-
nimiento de la planta en Louisvi lle, estuvo basado en una nueva metodología que ahora se conoce
como el método de la rttta crítica (CPM, critica/ path method). Como resultado de esté estudio. los
ingenieros pronosticaron que la producción en la planta de Louisville podía aumentarse a un nivel
tal, que ya no sería cuello de botella ni sería necesaria 01ra planta.
Aproximadamente al mismo tiempo, los asesores de la empresa Booze, Alfe n y Hami lton
desarrollaban un nuevo sistema de AP para el programa Polans Fleet Ballistic ivltssile de la
Oficina de Proyectos Especiales de la Marina de Estados Unidos (US Navy's Spec ial Proyects
Office). El misil Polaris, el prime r misil balístico imercontinental que podría ser lanzado ¡,k:,;d.; un
submarino sumergido en el agua, representaba el mayor (y uno de los más tu-riesgados) intenw de
investigación y desarrollo realizado a la fecha. Dada la incertidumbre involucrada en el proyecto,
los administradores querían una metodología que no sólo incorporara la incertidumbre en la pla-
neación, sino que también les permitiera estimar probabilidades de eventos 1m portantes (por ejem-
plo, si el sistema de propulsión avanza como fue planeado, ¿cuál es la probabi lidad de que:
podamos hacer un Ianzamient·..) de prueba en una fec ha dete rminada?). La metodolog ía desarro-
llada para ayudar en la administración de este proyecto se conoció como PERT (técntca ck revi-
sión y evaluación de programas, o Program Emluation and Review Technique) e introducía
explícitamente la incertidumbre a la programación y el proceso de asignación dd proyecto. Los
18 CAPÍTULO 1 INTRODUCCIÓN A LA ADM INISTRACIÓN DE PROYECTOS

conceptos básicos de PERT, así como sus ventajas, y desventajas y las herramientas correspon-
dientes se anal izan con más detalle en el capítulo 6.
El estudio de DuPont y las ventajas potenciales de las nuevas técnicas de CPM y PERT se
publicaron e n Business Week (1959) y en Fortune (1962). En 1963, Levy et al. (1963) publicaron
un texto sobre CPM en Harvard Business Review. Después de la publicación de este artículo, tanto
CPM como PERT se usaron ampliamente en organizaciones públicas y privadas (alg unas estaban
dispuestas, otras no). Estas tecnologías forman la base de la mayoría de los sistemas de AP que se
usan actualmente.
Aunque los términos CPM y PERT con frecuencia se usan como sinónimos, este libro usa
estos acrónimos según su definición original. Específicamente, CPM se refiere a casos en los que
la duración de las tareas y otros parámetros son deterrninísticos y se conocen con total certeza,
mtentras que el modelo de PERT supone que las duraciones de las tareas son variables aleatorias
que pueden describirse mediante una distribución de probabilidad adecuada. Es importante hacer
notar que la vasta mayoría de los programas de software comerciales para AP se bas:m en el modelo
CPM (aun cuando muchos de ellos usan el término PERT en su documentación o en su título).

SOFTWARE PAR A ADMINISTRACIÓN DE PROYECTOS

Los paquetes de software para AP tienen hoy una amplia difusión y los hay de muchos precios. Casi
todos los programas caen en una de dos categorías: programas de bajo costo, diseiiados para un solo
usuario en una computadora personal, y programas de mayor costo, diseñados para una red de un
conJunto de computadoras. Parece que la tendencia actual va hacia el segundo tipo de programas;
dada la importancia de una comunicación efectiva para el éxito de la administración de proyectos,
es crucial tener un mecanismo que permita a todos Jos que participan en el proyecto compartir datos
e infonnaci6n en tiempo real.
Como se observó, la mayoría de Jos paquetes comerciales de software para AP se basan en el
método de la ruta crítica (CPM); es decir, se supone que todos los parámetros, como la duración de
las tareas, son conocidos y constantes. Casi todos los paquetes de software sirven para dibujar dia-
gramas de Gantt (diagramas de barras), redes de precedencias e histogramas de niveles de recur-
$OS, así como para realizar cálculos básicos y proporcionar otros dwgramas y cálculos para
planeación y control. En este libro se demuestran casi todas las funciones empleadas en los pro-
ductos populares de software paraAP, mediante plantillas de hojas de cálculo que refl~j an esas fun-
ciones. El lector podrá tomar los ejemplos dados en el libro e introducir este material en el software
de su elección (como Microsoft Project, que se proporciona en el d1sco compacto que acompaña al
libro).
Además del software para AP, hay cada vez. más "complementos" que incrementan la funciona-
lidad de los productos para AP. Por ejemplo, hay programas que permüen al usuario incluir simula-
CIOnes de Monte Cario en el software para AP. De esta manera se puede incluir dtrectameme la
incerttdumbre en la etapa de planeación del proyecto y se pueden realizar análisis de sensibilidad. De
nuevo, se demostrará la funcionalidad de estos complementos usando plantillas de hojas de cálculo.

PROJECT MANAG EMENT INSTITUTE

El ProJeCt Management Institute (lnstttuto para la Administración de Proyectos) es una organización
profesional no lucrativa que promueve la administración de proyectos. Fundado en 1969, el PMI se
ha convertido en una organización internacional que tiene actualmente más de siete mil miembros.
El PMl patrocina seminarios y talleres, así como un proceso de ce1tificación que cubre sus doce
áreas de "conocimientos" (project management body of knowledge, PMBOK®). El PMJ ha promo-
v¡do la tdea de que la administración de proyectos requiere un conjunto de habilidades y un cuerpo
de conocimientos que son únicos para administrar proyectos. Puede encontrar más información
sobre el PMI en el si tio www.pmi.org.
 APENDICE lA. TRANSACCIONES MEDICARE: UNA LECCIÓN EN ADMINISTRACION DE PROYECTOS DE 50 MILLONES OE DÓlARES 19

MODELOS DE MA DUREZ EN ADMINISTRACIÓN D E P ROY ECTOS

Reconociendo que la administración de proyectos es un proceso avanzado que es más que herra-
mientas y software, algunos investigadores han desarrollado metodologws para evaluar el nivel de
competencia en AP de una organización. La motivación detrás de estas metodologías es que las
organizaciones mejorarán su capacidad para la AP si evalúan con cuidado su competencia actual y
tienen lineamientos para mejorar. Muchos de estos modelos se basan en amplias investigaciones
empíncas que sirven como bases de datos para práctica, así como de lineamientos para mejorar
procesos.
Mucho del trabajo inicial en esta área fue desarrollado por inv~sligado res del lnstimto de
Ingeniería de Software (SEI, Software Engineering lnstitute) de Camagie-Mellon University con
objeto de mejorar los procesos de desarrollo de software; el Modelo de Madurez de Capacidades
del SEI (SE1 Capabilicy /V!awrity Model), antecesor de la mayoría de los modelos de madurez,
con:sta de seis niveles de capacidades:
• Incompleto
11 Realizado
• Administrado
• Definido
• Administrado cuantitativamente
• Optimizado
Se han consrruido muchos otros modelos de madurez de AP Sigtuendo el marco de trabajo de
SEL Puede obtener más inforrnac.ión de los modelos de madurez de AP en Kerzner (200 1) así como
en los sitios de Internet de SEI y del Project Management Instimte (PMI).

APÉNDICE 1A. TR ANSACCIONES MEDICARE: UNA L EC C IÓN EN

ADMINISTRACIÓ N DE PROYECTOS DE 50 M I LLON E S DE DÓLARES
La admmistración del financiamiento para la at~nción de la salud (HCFA, liealth Care Financing
Admirzlstrmion), la dependencia que administra Medicare , invirtió seis años, de 1991 a 1997, y por
lo menos 50 millones de dólares en el desarrollo del Medicare Transaction System. Hoy, el plan
estratégico de ochenta y dos p<1ginas de la HCFA para tecnolog ía ele la información en los próxi-
mos cinco años, no menciona el desafortunado sistema y sólo hace referencia a los "esfuerzos de
inversión en TI anteriores de la HCFA". E l director de información de la HCFA, Gary Christoph,
contratado después de que se canceló el desarrollo del MTS. dijo que la dependencia está cam-
biando.
"Algunos de los conceptos del MTS eran realmente buenos conceptos. Lo que falló fue la
implementación" dice Christoph. "Cuando uno crece. primero aprende a gatear, luego camina,
luego corre, luego aprende a andar en bicicleta. Uno no salta de pronto a un Ferrari."
La historia de los problemas computacionales de HCFA son problemas típicos de las depen-
dencias federales: a lo largo de los años el Congreso ha creado numerosos programas bajo el domi-
niO de la dependencia. Para cada nuevo programa. la dependencia constmye un nuevo sistema de
mformación usando lenguajes de programación, plataformas y contratistas diferentes. Cada sistema
parece ser de propiedad exclusiva (lo que dificulta actualizarlo o lograr que comparta información)
y estar escrito en lenguajes populares en los años 50 y 60, como el COBOL.
Después, en algún momento de los 80, la dependencia se da cuenta de que su sistema se vol-
vía mmanejable. Así, decide construir un gran sistema integrado para manejar todos los programas
de la dependencia, una solución que espera que con el tiempo logre grandes ahorros (por supuesto
después de una significativa inver.s~ón in ic ial). Es evidente que manejar un sistema es menos cos-
toso que manejar muchos sistemas. Los gerentes de tecnología se imaginan ya el glorioso día den-
tro de cinco años cuando corten el listón, desempaquen el nuevo sistema, y disfruten el aplauso del
20 CAPITULO 1 INTRODUCCIÓN A LA ADMIN ISTRACIÓN De" PROYECTOS

administrador de Ja dependencia, el entusiasmo de los miembros del Congreso Y la aprobación de

los contribuyentes.
Pero usted conoce los resultados.
En el caso de la HCFA, la dependencia publicó una solicitud de propuestas para su mega-sis-
tema el 17 de septiembre de 1992. Pero aun antes de que se publicara la solicitud, el inspector gene-
ral del Departamento de Servicios de la Salud y Humanos recomendó a la HCFA que esperara y
"s1guiera un enfoque más orientado a la estrategia para simplificar, consolidar e integrar el proce-
samiento de los trámites de Medicare".
Cuatro meses después de que saliera la solicitud para propuestas, el inspector general sugirió
que la HCFA necesitaba definir con mayor claridad qué quería que hiciera el Sistema de
Transacciones de Medicare. El inspector general recomendó también que la HCFA se asegurara
que los contratistas comprendieran que Medicare es un programa en cambio constante que nece-
sita un software adaptable y flexible. En respuesta, la HCFA estableció once grupos de trabajo para
examinar los diversos aspectos del procesamiento de Medicare y proporcionar información a los
contratistas. Después el número de grupos de trabajo se ampliaría a veinticuatro.
Entre tanto, en enero de 1994, la dependencia otorgó a GTE Govennent Service el contrato
para el MTS. En abril de 1994 la HCFA contrató a Intennetrics lnc., una pequeña empresa en
Virginia, hoy conocida como AverStar, para vigilar independientemente el progreso de l contrato.
"Este nuevo sistema hará realidad una nueva era de servicio y conveniencia para los beneficia-
nos de Medicare" anunció la secretaria del HHS, Donna Shalala, en un comunicado de prensa en
enero de 1994. "Este nuevo sistema emplea los últimos avances de la tecnología para remplazar los
formatos e inconvenientes que han caracterizado a Medicare en el pasado." El sistema quedará ter-
minado a fines de 1998, decía el comunicado.
GTE empezó a planear una estrategia para combinar en un sistema los catorce sistemas de
Medicare que se encontraban en sesenta sitios operados por más de setenta contratistas, mientras
Jos grupos de trabajo intentaban darle sentido a la arquitectura del sistema de la dependencia.
Por todos lados había señales de peligro. En diciembre de 1994, el inspector general indicó,
una vez más, a la HCFA que no había proporcionado suficiente información a GTE para ayudarle
a planear la complejidad del procesamiento de Medicare. El año siguiente HCFA aseguró al ins-
pector general que había empezado a proporcionar información amplia a GTE. El sistema estaba
bajo control y se implementaría en septiembre de 1999.
En nO\'iembre de 1995, la oficina de contraloría general resalló varias inquietudes respecto al
MTS en un informe a la comisión de reformas del gobie rno, que inc luían falta de claridad en los
requenmientos del contrato, un programa muy apretado y falta de información confiable de costo-
beneficiO.
El administrador de la HCFA, Bruce Vladeck, respondió: "estamos conscientes de que se trata
de un proyecto de alto riesgo. Estamos realizándolo con una clara visión de la necesidad de admi-
nistrar el riesgo invo lucrado". A mediados de 1996, lntennetrics advirtió a la HCFA y a GTE q ue
la agenda de desarrollo del MTS tenía demasiados ev~n tos importantes que se traslapaban, pero esa
advertencia no fue escuchada según lo atestiguó un oficial de Intermelrics en una audienc~a en
mayo de 1997.
Un mes antes de esa audiencia, la HCFA ordenó a GTE suspender 90 días el trabajo en todos
Jos segmentos del MTS, excepto uno, para evaluar las razones del excesivo aume nto en Jos costos
y el retraso constante en las fechas de entrega.
En mayo de 1997,la oficina de contraloría insistió en que el MTS tenía grandes problemas. La
HCFA no había planeado una programación adecuada del proyecto, no tenía medidas de desem-
peño para evaluar el progreso, y no había usado "un análi sis costo-beneficio ni otras herramientas
para el seguimiento y evaluación continuos de los fondos gastados en el MTS y si contribui-
rían para e l retorno sobre la inversión", dUo la· oficina de contraloría. Además, los costos del pro-
yecto del MTS se habían incrementado de $151 millones a $1 000 millones. La contraloría estimó
 PROBLEMAS PARA ESTUDIO 21

que la HCFA había gastado hasta entonces $80 millones en el proyecto, aunqu~ la HCFA asegu-
raba que el gasto total en el MTS fue $50 mi ll ones. En respuesta, HCFA, GTE e incluso
Intermetrics prometieron que terminarían el MTS. si bien, quizá no antes del2000. T res meses des-
pués la HCFA canceló su contrato con GTE.
"Cometimos un error importante en la experiencia (del MTS) y quizá fue confiar demasiado
en la habilidad de los contratistas para cumplir con su entrega", dice Vladeck, el administrador
anterior. Hasta mediados del 1998, la HCFA siguió trabajando pru·a reducir el número de sistemas
en los que se apoyaba. Entonces suspendió todo intento de modernización pttra asegumrse de que
los cincuenta millones de líneas de código de software no tuvieran fallas técnicas potenciales para
el año 2000.
La HCFA no salió del proyecto del MTS con las manos vacías. La dependencia redujo el número
ele contratistas y de sitios que administraba e l sistema de procesamiento de Medicare e integró sus
catorce sistemas en seis. Además, el proyecto les dio a los funcionarios de la dependencia una mejor
comprensión cómo operan sus sistemas controlados en principio por los contratistas.
"La HCFA obtuvo del MTS una estrategia mucho más clara de corto a r1ediano plazo, para la
administración del procesamiento de solicitudes", dice Vladeck.
De hecho, Vladeck afirma que tal vez se hubiera podido salvar el MTS después del fracaso de
GTE excepto por dos factores . Primero, el Congreso y la administración de Clinton no considera-
ron muchos de los beneficios que podrían justificar el alto costo de un solo sistema integrado, que
incluyen mejor detección de fraudes y mayor eficiencia en e l procesamiento. Segundo, el proyecto
fue víctima de la noción que aún prevalece y que fue primero defendida por el director anterior de
administración y presupuesto, Frankil n Raines. de que los proyectos tan grandes simplemente no
funcionan.
El proyecto no logró realizar la visión propuesta por Shabla en 1994. No ex iste un sistema
único para el procesamiento de Medicare. Según el nuevo p lan a cinco años para tecnología de la
información de la HCFA, su sistema actual aún "refleja claramente la filosofía de negocios y diseño
de sistemas de una era en la que, por ejemplo, el procesamiento de soliciwcles era en gran pa11e una
función a través ele documentos .. . a pesar de operar e n equipo más nuevo".
Fuente: B. Friel, "Medicare Transactions: A S50 t'vlill i0 n Lesson fn Project Managemcnt", Government
Execuril·e (abri l 2000).

PROBLEMAS PARA EST U DI O

1. ¿Cuáles sedan los beneficios de una aplicación de técnicas de AP en un proyecto en el que
ha estado involucrado? Considere cómo definirla las tareas específicas y su duración en este
"proyecto''. ¿Cuáles fue ron las metas de l proyecto? ¿Qué restricc iones se impus ieron al
administrador del proyecto?
2. Considere la formación de un equipo de proyecto. ¿Qué características piensa usted que
deben tener los miembros del equipo? ¿Debe estar compuesto por miembros con capacita-
ción y antecedentes similares o deben tener habi lidades y preparación diferentes? ¿Cómo
debe operar el equipo de un proyecto? ¿Quién debe tener la responsabilidad final del
desempeño del equipo?
3. Considere la re lación entre el equipo de un proyecto y las partes funcio nales de una orga-
nización. ¿Quién debe tener la responsabilidad de aprobar tareas específicas? Si una tarea
de ingenieiÍa se extiende m:is allá ele la duración y e l presupuesto propuestos, ¿quién es el
responsable, e l director del área de ingenieiÍa o el administrador del proyecto? En general.
¿cómo cree que debe manejar los proyectos una compañía organizada por funciones?
4. Suponga que su empresa puede escoger entre mál_ de una docena de proyectos, pero sólo
puede elegir un número limitado de ellos. ¿Qué criterios sugeriría para clasificar los pro-
yectos? ¿Cómo decidiría qué proyectos seleccionar?
22 CAPITULO 1 INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS

5. Investigue los modelos de madurez para AP. Empleando una de las herramientas de autoe-
valuación que se encuentran en Internet, investigue cuál es el nivel de capacidades de su
organización. ¿Cómo podría mejorar la competencia de su organización en AP?

REFERENCIAS
Bagh, C. "D•gitally Speakmg, Builders Remain on thc Ground Floor", New York Ttmes, 13 de diciembre, 2000, 4.
Beck, K. y D. Clcal "Oplional Scope Contracts" (1999), URL: www.xprogramming.com/flp/Optional+scope
+contracts. pdf.
"Beuer Plans Come From Study of Anmomy of an Enginecring Job", Business Weck, 21 de marzo ele 1959. 60-66.
Boehm, G. A.W. "Hel ping lhe Executive 10 Make Up His Mmd". Fomme, abril, 1962, 127.
Bounds, G. "The Las! Word on Project Managcrnent", /lE SolutiOIIl (noviembre, 1998).
Brown, S.L., y K.M. Eisenhardl. "Thc Art of Cominuous Changc: Linking Complexily Thcory and Time-paced F"olution
m Relentlessly Shifting Organizations", Admi11istrative Scicnce Quarterly 42 (1997): 1- 34.
Eisenhardt. K.M. y B.N. Tabrizi. "Accelcrating Adapuve Proccsses: Product lnnovation in lhc Global Computer lndustry",
Adminisrrorive S<:icnce Quarrerly 40 ( 1995): 84- 11O.
Frable. F. "Delaycd Openings Are a Fact of Life in lhe Foodservicc. Ho~pitality lndustry", Nmion 's Resrartront News ( 12
de abril, 1999): 18.
Frie!, B. "Med1care Transactions: A $50 Mi Ilion Lesson in Project Managcmem", Go•·cmment Executive, NJ ti onal Joumal
(abril, 2000): 68.
Griffin, A. y A. Page. "An Failure'', Mrmagemem 9, núm. 1 ( 1993): 291-308.
Hughcs, M.W. "Why Projects Fail: Thc Effcct~ oflgnoring the Obnous'',lndmtnal Engmecrmg (abril, 1986): 14-18.
Kahneman, O.P., P. Slnvic y A. Tvcrsky. "Judgment Under Uncertainty: lieuristiC$ and Biases", Cnmbndgc, U.K.:
Cambridge University Press. 1982.
Kcrzner, H Straugic Plonning for Project Mallagem('nt Using a Project Managcment Mamriry Model. Nueva York: John
\V¡Jey and Sons, lnc., 2001.
Levy, F., G.L. Thompson y J.D. \Vicst. "Thc ABC's of the Cri tic~ l Path Mcthod", Harvard Business Review (septiem-
bre-octubre, 1963): 98-108.
A Cuide ro tire Project Managemenr Body of KnOII'Iedge (PMBO~ Cuide). :--1ewton Square. Pa.: ProJeCt Man~gemcnt
lnSlllUle (PMT), 2000.
Might, R.J. y W.A. Fischer. "The Role of Structural Factors 111 Deterrn ining Project Managcment Success", IEEE
Transacnons on Engineering Managcment EM-32, núm. 2, m3yo, 1985.
P11110, J. ] D. Slevm. "Critica! Factors in Succe~sful Project lmplementauon", IEEE Tranmctions on Engineering
Management EM-34, núm. 1, (1 de febrero, 1987): 22-27.
"Riot-Ravaged Taco Bell Rebuilt in 48 Hours Using Project Planning Software", Industrial Engineering (septiembre,
1992): 18.
Shenhar. A. "One Stze Does No! Fit All Projccts: Exploring Classica1 Contingency Domains", Managcment Science 47,
núm. 3 (mar~o 200 1): 394-4 14.
"Stave Falls Wins Projecl of lhe Year Award", Water Power 011d Dam Construction. Wilming10n Publi~hing Ltd. (31 de julio.
2000): 3
Staw. B. y J Ross "Knowing When to Pul! the Plug", Han·ord Business Re•·iew (marzo-abril, 1987): 68-74.
Schmidl, E. "Regional Con~truction Industry Is Going Through a Communications Revolutton", New York Construcuon 48.
núm 8 (marzo, 2000): 59.
P Slov¡c, y A. Tv~!rsky, Judgment under Uncertainry: Heurwrcs and Bias es. Cambridge, UK Cambridge Umversity Prcss.
! 982.
Standish Group. 1999. URL: www.standishgroup.com/.
Takeucht, H y J. Nonaka. "The New Ncw Product Dcvcloprncnt Gamc," lfar..-ard Bus•ncss Rcl'iew (enero-febrero, 1986).
A. Vazsonyi, "L'Histoire de Grandeur et de la Decadence de la .Mclhode PERT", Managemc/11 Science 16, núm. 8 (at>ril,
1970): B449-455.
Walker, R "Dig This: Building Boom Ex poses E. Germans' Pre-Communist Past'', Christian Science Ma11itor ( 12 de
agosto, 1996): 6 . .
Wheclwright, S. C. y K. B. Clark. "Creating Project Plans lO Focus", Han,ard Business Re,.iew (marzo-abril, 1992): 70-82.
Yap, C.M. y W.E. Soudcr. "Factors Innuenctng New Product Success and Fai1ure •n Small Emreprcneurial High-
Technology Electronics Finns", Joumal of Product ilmomtio11 Managcme111 11 (1994): 4 18-432.
Yang, S. "CSOC's Shorten Des•gn Cycles", Copyright Elecrronics News (15 de mayo, 2000): 22.
Youker. R. "A New Look at lhe WBS: Project Breakdown Stntcturcs (PBS)", Projecr Managemem Jormwf (1989): 54-59