Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

EL INFORME DEL GRUPO ESTÁNDAR

© The Standish Group 1995. Reimpreso aquí con fines académicos exclusivos con
permiso de The Standish Group.

CAOS
"Los puentes romanos de la antigüedad eran estructuras muy ineficientes. Según los estándares modernos,
usaban demasiada piedra y, como resultado, demasiada mano de obra para construir. Con los años hemos
aprendido a construir puentes de manera más eficiente, utilizando menos materiales y menos labor
para realizar la misma tarea ".

Tom Clancy (La suma de todos los miedos)

INTRODUCCIÓN
En 1986, Alfred Spector, presidente de Transarc Corporation, fue coautor de un artículo que compara la
construcción de puentes con el desarrollo de software. La premisa: los puentes normalmente se
construyen a tiempo, dentro del presupuesto y no se caen. Por otro lado, el software nunca llega a tiempo
o dentro del presupuesto. Además, siempre se estropea. (Sin embargo, la construcción de puentes no
siempre tuvo un récord tan estelar. Muchos proyectos de construcción de puentes excedieron sus
estimaciones, plazos y algunos incluso se derrumbaron).

Una de las principales razones por las que los puentes llegan a tiempo, dentro del presupuesto y no
se caen es por los detalles extremos del diseño. El diseño está congelado y el contratista tiene poca
flexibilidad para cambiar las especificaciones. Sin embargo, en el entorno empresarial de rápido
movimiento actual, un diseño congelado no se adapta a los cambios en las prácticas comerciales.
Por tanto, se debe utilizar un modelo más flexible. Esto podría ser y se ha utilizado como
justificación del fracaso del desarrollo.

Pero hay otra diferencia entre fallas de software y fallas de puente, además de
3000 años de experiencia. Cuando un puente se cae, se investiga y se redacta un informe
sobre la causa del fallo. Esto no es así en la industria de la computación, donde las fallas
se ocultan, ignoran y / o racionalizan. Como resultado, seguimos cometiendo los mismos
errores una y otra vez.

En consecuencia, el enfoque de este último proyecto de investigación en The Standish Group ha sido
identificar:

  El alcance de las fallas de los proyectos de software

  Los principales factores que provocan el fracaso de los proyectos de
  software Los ingredientes clave que pueden reducir los fracasos del proyecto

Sra. Ing. Oscar Zocón Alva 1

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

REGISTRO DE FALLOS
En los Estados Unidos, gastamos más de $ 250 mil millones cada año en el desarrollo de
aplicaciones de TI de aproximadamente 175,000 proyectos. El costo promedio de un proyecto
de desarrollo para una gran empresa es de $ 2,322,000; para una empresa mediana, es $
1,331,000; y para una empresa pequeña, es $ 434.000. Muchos de estos proyectos fracasarán.
Los proyectos de desarrollo de software están en un caos, y ya no podemos imitar a los tres
monos: no escuche fallas, no vea fallas, no hable fallas.

La investigación de Standish Group muestra que un asombroso 31,1% de los proyectos se cancelarán
antes de que se completen. Otros resultados indican que el 52,7% de los proyectos costarán el 189% de
sus estimaciones originales. El costo de estos fracasos y sobrecostos es solo la punta del proverbial
iceberg. Los costos de oportunidad perdida no se pueden medir, pero fácilmente podrían ascender a
billones de dólares. Uno solo tiene que mirar a la ciudad de Denver para darse cuenta de la magnitud de
este problema. La falla en producir un software confiable para manejar el equipaje en el nuevo
aeropuerto de Denver le está costando a la ciudad $ 1.1 millones por día.

Con base en esta investigación, The Standish Group estima que en 1995 las empresas estadounidenses y las
agencias gubernamentales gastarán 81 mil millones de dólares en proyectos de software cancelados. Estas
mismas organizaciones pagarán $ 59 mil millones adicionales por proyectos de software que se completarán,
pero excederán sus estimaciones de tiempo originales. El riesgo siempre es un factor a la hora de ampliar los
límites de la tecnología, pero muchos de estos proyectos eran tan mundanos como una base de datos de
licencias de conducir, un nuevo paquete de contabilidad o un sistema de entrada de pedidos.

En el lado del éxito, el promedio es solo del 16,2% para los proyectos de software que se completan a
tiempo y dentro del presupuesto. En las empresas más grandes, la noticia es aún peor: solo el 9% de sus
proyectos llegan a tiempo y dentro del presupuesto. E, incluso cuando estos proyectos se completan,
muchos no son más que una mera sombra de sus requisitos de especificación originales. Los proyectos
completados por las empresas estadounidenses más grandes tienen solo aproximadamente el 42% de las
características y funciones propuestas originalmente. A las empresas más pequeñas les va mucho mejor.
Un total del 78,4% de sus proyectos de software se implementarán con al menos el 74,2% de sus
características y funciones originales.

Estos datos pueden parecer desalentadores y, de hecho, el 48% de los ejecutivos de TI en

nuestra muestra de investigación sienten que hay más fallas actualmente que hace solo cinco
años. La buena noticia es que más del 50% siente que hay menos o el mismo número de fallas
hoy que hace cinco y diez años.

METODOLOGÍA
La encuesta realizada por The Standish Group fue lo más completa posible, sin alcanzar el objetivo
inalcanzable de encuestar a todas las empresas con MIS en el país. Los resultados se basan en lo
que en The Standish Group definimos como "hallazgos clave" de nuestras encuestas de
investigación y varias entrevistas personales. Los encuestados eran directores ejecutivos de TI. La
muestra incluyó empresas grandes, medianas y pequeñas en los principales segmentos de la
industria, por ejemplo, banca, valores, manufactura, minorista, mayorista, atención médica,
seguros, servicios y organizaciones locales, estatales y federales. El tamaño total de la muestra fue
de 365 encuestados y representó 8.380 solicitudes. Además, The Standish Group

Sra. Ing. Oscar Zocón Alva 2

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

llevó a cabo cuatro grupos focales y numerosas entrevistas personales para proporcionar un contexto cualitativo
para los resultados de la encuesta.

Para efectos del estudio, los proyectos se clasificaron en tres tipos de resolución:

  Tipo de resolución 1, o éxito del proyecto: el proyecto se completa a tiempo y dentro del presupuesto,
con todas las características y funciones como se especificó inicialmente.
  Tipo de resolución 2, o proyecto desafiado: el proyecto está terminado y en funcionamiento, pero
sobrepasa el presupuesto, en el tiempo estimado, y ofrece menos características y funciones de
las que se especificaron originalmente.
  Resolución Tipo 3, o proyecto deteriorado: el proyecto se cancela en algún momento
durante el ciclo de desarrollo.

En general, la tasa de éxito fue solo del 16,2%, mientras que los proyectos desafiados representaron
52,7% y deteriorado (cancelado) el 31,1%.

ESTADÍSTICAS DE FALLA
Standish Group segmentó aún más estos resultados por empresas grandes, medianas y pequeñas. Una
empresa grande es cualquier empresa con más de $ 500 millones de dólares en ingresos por año, una
empresa mediana se define como una empresa que tiene entre $ 200 millones y $ 500 millones en
ingresos anuales, y una pequeña empresa tiene entre $ 100 millones y $ 200 millones.

Las cifras de fracaso fueron igualmente desalentadoras en empresas de todos los tamaños. Solo el 9% de
los proyectos de las grandes empresas tuvieron éxito. Con un 16,2% y un 28% respectivamente, las
empresas medianas y pequeñas tuvieron algo más de éxito. Un enorme 61,5% de todos los proyectos de
grandes empresas fueron cuestionados (Resolución Tipo 2) en comparación con el 46,7% de las empresas
medianas y el 50,4% de las pequeñas. La mayoría de los proyectos, 37,1%, fueron deteriorados y
posteriormente cancelados (Resolución Tipo 3) en empresas medianas, en comparación con
29,5% en grandes empresas y 21,6% en pequeñas empresas.

Reinicia

Una de las principales causas de los excesos de tiempo y costes son los reinicios. Por cada 100 proyectos
que se inician, hay 94 reinicios. Esto no significa que 94 de 100 tendrán un reinicio, algunos proyectos
pueden tener varios reinicios. Por ejemplo, el proyecto del Departamento de Vehículos Motorizados de
California, un escenario de falla resumido más adelante en este artículo, tuvo muchos reinicios.

Sobrecostos

Igualmente reveladores fueron los resultados de sobrecostos, sobrecostos y fallas de las

aplicaciones para proporcionar las características esperadas. Para los proyectos combinados
de Tipo 2 y Tipo 3, casi un tercio experimentó sobrecostos de 150 a 200%. El promedio de
todas las empresas es el 189% del costo estimado original. El sobrecoste promedio es del 178%
para las grandes empresas, del 182% para las medianas y del 214% para las pequeñas.

Sra. Ing. Oscar Zocón Alva 3

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

Costos excesivos% de respuestas

Menos de 20% 15,5%
21 - 50% 31,5%
51 - 100% 29,6%
101-200% 10,2%
201 - 400% 8,8%
Más del 400% 4,4%

Exceso de tiempo

Para los mismos proyectos desafiados y deteriorados combinados, más de un tercio también experimentó
retrasos en el tiempo del 200 al 300%. El rebasamiento promedio es el 222% del tiempo estimado original.
Para las grandes empresas, la media es del 230%; para las medianas empresas, el promedio es 202%; y
para las pequeñas empresas, el promedio es del 239%.

% De respuestas excedidas en el tiempo

Menos de 20% 13,9%

21 - 50% 18,3%
51 - 100% 20,0%
101-200% 35,5%
201 - 400% 11,2%
Más del 400% 1,1%

Deficiencias de contenido

Para los proyectos desafiados, más de una cuarta parte se completaron con solo del 25% al 49% de las
características y funciones especificadas originalmente. En promedio, solo el 61% de las características y
funciones especificadas originalmente estaban disponibles en estos proyectos. Las grandes empresas
tienen el peor historial con solo el 42% de las características y funciones en el producto final. Para las
empresas medianas, el porcentaje es del 65%. Y para las pequeñas empresas, el porcentaje es del 74%.

% de características / funciones% de respuestas

Menos del 25% 4,6%
25 - 49% 27,2%
50 - 74% 21,8%
75 - 99% 39,1%
100% 7,3%

Actualmente, las 365 empresas tienen un total de 3.682 aplicaciones en desarrollo. Solo 431 o el 12% de
estos proyectos se realizan a tiempo y dentro del presupuesto.

PERFILES DE ÉXITO / FRACASO

El aspecto más importante de la investigación es descubrir por qué fracasan los proyectos. Para hacer esto, The
Standish Group encuestó a los gerentes ejecutivos de TI para conocer sus opiniones sobre por qué

Sra. Ing. Oscar Zocón Alva 4

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

los proyectos tienen éxito. Las tres razones principales por las que un proyecto tendrá éxito son la
participación del usuario, el apoyo de la dirección ejecutiva y una declaración clara de requisitos.
Hay otros criterios de éxito, pero con estos tres elementos en su lugar, las posibilidades de éxito son
mucho mayores. Sin ellos, la posibilidad de fracaso aumenta drásticamente.

Factores de éxito del proyecto % de respuestas

1. Participación del usuario 15,9%
2. Apoyo a la gestión ejecutiva 13,9%
3. Declaración clara de requisitos 13,0%
4. Planificación adecuada 9,6%
5. Expectativas realistas 8,2%
6. Hitos del proyecto más pequeños 7,7%
7. Personal competente 7,2%
8. Propiedad 5,3%
9. Visión y objetivos claros 2,9%
10. Personal dedicado y trabajador 2,4%
Otros 13,9%

También se preguntó a los participantes de la encuesta sobre los factores que hacen que los proyectos sean
desafiado.

Factores desafiados del proyecto % de respuestas

1. Falta de participación del usuario 12,8%
2. Requisitos y especificaciones incompletos 12,3%
3. Requisitos y especificaciones cambiantes 11,8%
4. Falta de apoyo ejecutivo 7,5%
5. Incompetencia tecnológica 7,0%
6. Falta de recursos 6,4%
7. Expectativas poco realistas 5,9%
8. Objetivos poco claros 5,3%
9. Marcos de tiempo poco realistas 4,3%
10. Nueva tecnología 3,7%
Otro 23,0%

Las opiniones sobre por qué los proyectos se ven perjudicados y finalmente cancelados clasificaron los requisitos
incompletos y la falta de participación del usuario en la parte superior de la lista.

Factores perjudiciales del proyecto % de respuestas

1. Requisitos incompletos 13,1%
2. Falta de participación de los usuarios 12,4%
3. Falta de recursos 10,6%
4. Expectativas poco realistas 9,9%
5. Falta de apoyo ejecutivo 9,3%

Sra. Ing. Oscar Zocón Alva 5

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

6. Cambio de requisitos y especificaciones 8,7%

7. Falta de planificación 8,1%
8. Ya no lo necesitaba 7,5%
9. Falta de gestión de TI 6,2%
10. Analfabetismo tecnológico 4,3%
Otro 9,9%

Otro hallazgo clave de la encuesta es que un alto porcentaje de gerentes ejecutivos

cree que hay más fallas de proyectos ahora que hace cinco y diez años. Esto a pesar de
que la tecnología ha tenido tiempo de madurar.

Hace más de 5 años Hace más de 10 años

Significativamente más 27% 17%
fallas Un poco más fallas 21% 29%
Ningún cambio 11% 23%
Algo menos fallas 19% 23%
Significativamente menos fallas 22% 8%

GRUPOS DE ENFOQUE

Para aumentar los resultados de la encuesta, The Standish Group realizó cuatro grupos focales con
ejecutivos de TI de las principales empresas. Los asistentes provenían de una muestra representativa de
industrias, incluidas las de seguros, gobierno estatal y federal, comercio minorista, banca, valores,
manufactura y servicios. Dos de los grupos focales se realizaron en Boston. Los otros dos, en San
Francisco. Cada grupo de enfoque tuvo un promedio de diez participantes con un total general de
cuarenta y un ejecutivos de TI. El propósito de estos grupos focales en particular fue solicitar opiniones
sobre por qué fracasan los proyectos. Además, The Standish Group realizó entrevistas con varios gerentes
de TI. Algunos de sus comentarios son esclarecedores sobre la variedad de problemas que acechan el
desarrollo de proyectos.

Muchos de los comentarios se hicieron eco de los hallazgos de la encuesta de The Standish Group.
"Tenemos 500 proyectos. Ninguno está a tiempo y dentro del presupuesto. Este año, se cancelará el 40%",
dijo Edward, vicepresidente de MIS en una compañía farmacéutica.

Otros comentarios se dirigieron directamente a las razones del fracaso. Jim, el director de TI de
un importante fabricante de equipos médicos, dijo: "Dado que se trata de una mentalidad, es
muy difícil lograr que toda la administración, incluso a nivel local, ni siquiera a nivel mundial,
obtenga toda la gerencia para acordar un conjunto de reglas ... Eso es un desafío en sí mismo
porque, en algunos casos, debe convencerlos de que esto es lo mejor para la empresa, no
necesariamente lo mejor para ellos, pero lo mejor para la empresa . Y tienes que tener esa
aceptación. Si no tienes esa aceptación, fracasarás. No me importa cuán grande o pequeño sea
el proyecto ".

John, director de MIS en una agencia gubernamental, agregó: "¡Probablemente el 90% de los fallos
en los proyectos de aplicaciones se deben a la política!" Y Kathy, programadora de una empresa de
telecomunicaciones, ofreció un comentario aún más mordaz sobre política: "A veces tienes que

Sra. Ing. Oscar Zocón Alva 6

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

toma una decisión que no te guste. Incluso en contra de tu propia naturaleza. Dices bueno, está mal, pero
tomas esa decisión de todos modos. Es como recibir un martillo en el dedo del pie. Duele."

Bob, el director de MIS en un hospital, comentó sobre los factores externos que contribuyen al
fracaso del proyecto. "Nuestro mayor problema son las prioridades en competencia", dijo.
"Acabamos de tener una reorganización hoy. Así que ahora eso va a agotar todos los recursos. Y
explicarle a la alta gerencia que, 'Bueno, realmente nos está tomando el tiempo que dijimos que iba
a tomar. Pero debido a que usted reorganizó la empresa , Voy a tomarme otros seis meses en este
otro proyecto, porque estoy haciendo otra cosa por ti '. Ese es el mayor problema que tengo ". Bill, el
director de MIS en una firma de valores, agregó: "Cambios, cambios, cambios; son los verdaderos
asesinos".

Algunos de los comentarios fueron de humor oscuro. "Usuarios con muerte cerebral, simplemente
usuarios con muerte cerebral", dijo Peter, un analista de aplicaciones en un banco. "Cuando lo proyectado
comenzó a fallar", dijo Paul, un programador de un fabricante de productos personales, "la administración
lo apoyó, muy atrasado".

El comentario más indicativo del caos en el desarrollo de proyectos provino de Sid, un gerente
de proyectos en una compañía de seguros. "El proyecto tenía dos años de retraso y tres años
en desarrollo", dijo. "Teníamos treinta personas en el proyecto. Entregamos una aplicación que
el usuario no necesitaba. Habían dejado de vender el producto más de un año antes".

ESTUDIOS DE CASO

Para obtener más información sobre el fracaso y el éxito, The Standish Group examinó
detenidamente dos proyectos famosos de Resolución Tipo 3 (cancelados) y dos proyectos de
Resolución Tipo 1 (exitosos). A efectos de comparación, se utilizaron los criterios de éxito del
proyecto de la encuesta a los directores ejecutivos de TI para crear un cuadro de "potencial de
éxito". A continuación, se ponderaron los criterios de éxito en función de las aportaciones de
los directores de TI encuestados. El criterio más importante, "participación del usuario", recibió
19 "puntos de éxito". El menos importante - "personal dedicado y trabajador" - recibió tres
puntos. Dos criterios de éxito muy importantes - "expectativas realistas" e "hitos del proyecto
más pequeños" - se ponderaron en diez y nueve puntos, respectivamente. Finalmente, como
se presenta más adelante en este informe,

DMV de California

En 1987, el Departamento de Vehículos Motorizados de California (DMV) se embarcó en un proyecto

importante para revitalizar su licencia de conducir y el proceso de solicitud de registro. Para 1993,
después de que ya se habían gastado $ 45 millones de dólares, el proyecto fue cancelado.

Según un informe especial emitido por el DMV, la razón principal para volver a desarrollar esta
aplicación fue la adopción de nueva tecnología. Declararon públicamente: "El objetivo
específico del proyecto de 1987 era utilizar tecnología moderna para respaldar la misión del
DMV y mantener su crecimiento al posicionar estratégicamente el entorno de procesamiento
de datos del DMV para responder rápidamente al cambio". Además, según el informe especial
del DMV "La fase se cambió varias veces, pero la comunidad técnica del DMV nunca tuvo
verdadera confianza en su viabilidad ..."

Sra. Ing. Oscar Zocón Alva 7

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

El proyecto no tuvo una recuperación monetaria, no contó con el apoyo de la dirección ejecutiva, no contó con la
participación de los usuarios, tuvo una planificación deficiente, especificaciones de diseño deficientes y objetivos
poco claros. Tampoco contó con el apoyo del personal de gestión de información del estado.

El proyecto del DMV no era ciencia espacial. Hay aplicaciones mucho más difíciles que las licencias
de conducir y los registros. Pero debido a la política estatal interna, los objetivos poco claros y la
mala planificación, el proyecto estuvo condenado al fracaso desde el principio.

aerolíneas americanas

A principios de 1994, American Airlines resolvió su demanda con Budget Rent-A-Car, Marriott Corp. y
Hilton Hotels después de que el proyecto de sistema de reserva de hotel y alquiler de automóviles
CONFIRM de 165 millones de dólares se derrumbó en el caos.

Este proyecto fracasó porque había demasiados cocineros y la sopa se echó a perder. La dirección
ejecutiva no solo apoyó el proyecto, sino que también fueron directores de proyecto activos. Por
supuesto, para que un proyecto de este tamaño fracase, debe haber tenido muchos defectos. Otras
causas importantes incluyeron una declaración incompleta de requisitos, la falta de participación del
usuario y el cambio constante de requisitos y especificaciones.

Hoteles Hyatt

Mientras los hoteles Marriott y Hilton estaban saliendo de su sistema de reserva fallido, Hyatt se
estaba registrando. Hoy, puede marcar desde el teléfono celular de un avión a 35,000 pies,
registrarse en su habitación de hotel Hyatt, programar el autobús de cortesía para que lo recoja y
tenga sus llaves esperando en el mostrador exprés. Este nuevo sistema de reservas se adelantó a lo
programado, por debajo del presupuesto, con funciones adicionales, por tan solo $ 15 millones en
efectivo. Utilizaron un software moderno de sistemas abiertos con una base de datos Informix y el
monitor de transacciones TUXEDO, en hardware basado en Unix.

Hyatt tenía todos los ingredientes adecuados para el éxito: participación del usuario, apoyo de la
dirección ejecutiva, una declaración clara de requisitos, planificación adecuada e hitos de proyectos
pequeños.

Banco Itamarati

Un año después de una reorientación estratégica, Banco Itamarati, un banco brasileño de

propiedad privada, produjo un crecimiento anual de la utilidad neta del 51% y pasó del lugar 47 al
15 en la industria bancaria brasileña. Tres razones fundamentales explican el éxito del Banco
Itamarati. Primero, tenían una visión clara con objetivos específicos documentados. En segundo
lugar, su nivel de participación de arriba hacia abajo permitió al Banco Itamarati mantener el
rumbo. Y finalmente, el banco produjo resultados incrementales y mensurables a lo largo del
período de planificación / implementación.

El claro objetivo comercial de Banco Itamarati es ser uno de los cinco principales bancos privados de
Brasil para el año 2000. Sus objetivos incluyen mantener una relación cercana con sus clientes para
mejorar y mantener la comprensión de sus necesidades, ofreciendo soluciones financieras
competitivas, garantizando la satisfacción del cliente. , y finalmente producir resultados equilibrados
para el Grupo Itamarati. Los objetivos del Banco Itamarati fueron

Sra. Ing. Oscar Zocón Alva 8

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

incorporado en un plan estratégico que identifica claramente los resultados mensurables y la

propiedad individual.

Su plan estratégico hizo de la tecnología un componente clave de la estrategia comercial. Itamarati

utilizó el monitor GRIP OLTP de Itautec como herramienta básica para integrar componentes de
software. Según Henrique Costabile, Director de Desarrollo Organizacional, "Somos uno de los
primeros bancos en implementar una arquitectura cliente-servidor que maximiza el potencial de
esta arquitectura". El liderazgo ejecutivo, un plan bien comunicado y un equipo diverso capacitado
proporcionaron la base para que Banco Itamarati logre su objetivo a largo plazo, potencialmente
antes de lo programado.

CONCLUSIONES DEL ESTUDIO DE CASO

El estudio de cada proyecto incluyó la suma de puntos de éxito sobre el "potencial de éxito"
gráfico.

Criterios de éxito Puntos DMV CONFIRM HYATT ITAMARATI

SÍ
1. Participación del usuario 19 NO (0) NO (0) SÍ (19)
(19)
2. Apoyo a la gestión SÍ
dieciséis NO (0) SI (16) SÍ (16)
ejecutiva (dieciséis)

3. Declaración clara SÍ
15 NO (0) NO (0) NO (0)
de requisitos (15)
SÍ
4. Planificación adecuada 11 NO (0) NO (0) SÍ (11)
(11)
SÍ SÍ
5. Expectativas realistas 10 SÍ (10) SÍ (10)
(10) (10)
6. Hitos del proyecto más pequeños 9 NO (0) NO (0) SI (9) NO SÍ (9)
7. Personal competente 8 NO (0) (0) SI (8) NO (0) SI SÍ (8)
8. Propiedad 6 NO (0) (6) NO (0) SI (3) SÍ (6)
9. Visión y objetivos claros 3 NO (0) SI: 3)
10. Personal dedicado y
3 NO (0) SI (3) SI (3) SI: 3)
trabajador
TOTAL 100 10 29 100 85

Con solo 10 puntos de éxito, el proyecto del DMV prácticamente no tenía posibilidades de éxito. Con 100
puntos de éxito, el proyecto de reserva de Hyatt tenía todos los ingredientes adecuados para el éxito.
Con solo 29 puntos de éxito, el proyecto CONFIRM tenía pocas posibilidades de éxito. Con
85, Itamarati, aunque no tan seguro como Hyatt, comenzó con una alta probabilidad de éxito.

EL PUENTE DEL ÉXITO

No obstante, este estudio no es lo suficientemente profundo como para proporcionar una solución real a un
problema tan abrumador como las tasas actuales de fracaso del proyecto. Los proyectos de software de
aplicación están realmente en aguas turbulentas. Para poner orden en el caos, necesitamos examinar

Sra. Ing. Oscar Zocón Alva 9

Universidad Nacional de Cajamarca Administración de Proyectos de Sistemas

por qué fracasan los proyectos. Al igual que los puentes, cada falla importante de software debe investigarse,
estudiarse, informarse y compartirse.

Debido a que es el producto de las ideas de los gerentes de TI, el cuadro "Potencial de éxito" puede
ser una herramienta útil para pronosticar el éxito potencial de un proyecto o evaluar el fracaso del
proyecto.

La investigación en The Standish Group también indica que los marcos de tiempo más pequeños, con la entrega
de componentes de software temprano y con frecuencia, aumentarán la tasa de éxito. Los períodos de tiempo
más cortos dan como resultado un proceso iterativo de diseño, prototipo, desarrollo, prueba e implementación
de pequeños elementos. Este proceso se conoce como software "en crecimiento", a diferencia del antiguo
concepto de software "en desarrollo". El software en crecimiento involucra al usuario antes, cada componente
tiene un propietario o un pequeño grupo de propietarios, y las expectativas se establecen de manera realista.
Además, cada componente de software tiene una declaración y un conjunto de objetivos claros y precisos. Los
componentes de software y los proyectos pequeños tienden a ser menos complejos. Hacer los proyectos más
simples es un esfuerzo que vale la pena porque la complejidad solo causa confusión y aumenta el costo.

Hay un aspecto final a considerar en cualquier grado de fracaso del proyecto. Todo éxito tiene sus raíces
en la suerte o en el fracaso. Si comienzas con suerte, no aprendes nada más que arrogancia. Sin embargo,
si comienza con el fracaso y aprende a evaluarlo, también aprende a tener éxito. El fracaso engendra
conocimiento. A partir del conocimiento obtienes sabiduría, y es con sabiduría que puedes llegar a ser
verdaderamente exitoso.

Sra. Ing. Oscar Zocón Alva 10