Está en la página 1de 24

EL INFORME STANDISH GROUP

CHAOS

"Los puentes romanos de la antigedad eran muy


ineficientes estructuras. Segn los estndares modernos,
que usan demasiada piedra, y como resultado,
demasiada mano de obra para construir. Durante los aos
hemos aprendido a construir puentes de manera ms
eficiente, utilizando menos materiales y menos mano de
obra para llevar a cabo la misma tarea.

En 1986, Alfred Spector, presidente


Corporation, co-autor de un documento

de

Transarc

la comparacin de la construccin de puentes para el


desarrollo de software. La premisa: Los puentes son
normalmente construida en tiempo, presupuesto situ, y
no caer. Por otro lado, software
Nunca viene en el tiempo o en el presupuesto. Adems,
siempre se rompe.
(Sin embargo, la construccin de puentes no siempre
tienen un historial tan estelar. Muchos
proyectos de construccin de puentes rebasen sus
presupuestos, plazos, y algunos incluso cayeron
hacia abajo.
Una de las mayores razones por las que los puentes
vienen en el tiempo, dentro del presupuesto y no se
caigan
es debido a la extrema detalle de diseo. El diseo es
congelado y el contratista
tiene poca flexibilidad en el cambio de las
especificaciones. Sin embargo, en rpido movimiento de
hoy
entorno empresarial, un diseo
acomoda a los cambios en el

congelado

no

se

prcticas empresariales. Por lo tanto un modelo ms


flexible debe ser utilizado. Esto podra ser
y se ha utilizado como una razn para el fracaso del
desarrollo.

Pero hay otra diferencia entre los fallos de software y los


fracasos del puente, al lado
3.000 aos de experiencia. Cuando un puente se cae, se
investiga y un informe
que est escrito en la causa de la falla. Esto no es as en
la industria informtica, donde
fracasos estn cubiertos hasta, ignorados, y / o
racionalizarse. Como resultado, mantenemos la toma
los mismos errores una y otra vez.
En consecuencia, el enfoque de este ltimo proyecto de
investigacin en el Grupo Standish tiene
sido identificar:
El alcance del fracaso de los proyectos de software.
Los principales factores que causan los proyectos de
software fallen.
Los ingredientes clave que pueden reducir el fracaso de
los proyectos.

expediente de la falta
En los Estados Unidos, gastamos ms de $ 250 mil
millones cada ao en la aplicacin informtica
desarrollo de aproximadamente 175.000 proyectos. El
costo promedio de un desarrollo
proyecto para una compaa grande es 2.322 millones
dlares; para una empresa mediana, que es $ 1.331
millones;
y para una pequea empresa, es $ 434.000. Una gran
parte de estos proyectos se producir un error.
Proyectos de desarrollo de software estn en el caos, y
ya no pueden imitar los tres
monos - or ningn fracaso, ver ningn fracaso, no hable
ni fracasos.
La investigacin Standish Group muestra un asombroso
31,1% de los proyectos ser de
cancelado antes de que alguna vez se completan. Otros
resultados indican el 52,7% de los proyectos
tendr un costo de 189% de sus estimaciones originales.
El costo de estos fracasos y excesos son
slo la punta del iceberg. Los costos de oportunidad
perdidos no son medibles,
pero podra ser fcilmente en los billones de dlares. Uno
slo tiene que mirar a la Ciudad de
Denver para darse cuenta de la magnitud de este
problema. La falta de presentacin de software fiable

para manejar el equipaje en el nuevo aeropuerto de


Denver est costando a la ciudad $ 1.1 millones por da.
Sobre la base de esta investigacin, The Standish Group
estima que en 1995 Amrica
empresas y agencias gubernamentales gastarn $ 81 mil
millones para el software cancelado
proyectos. Estas mismas organizaciones pagarn un
adicional de $ 59,000,000,000 para el software
proyectos que se completaron, pero superarn sus
estimaciones de tiempo originales. El riesgo es
siempre un factor al empujar el sobre tecnologa, pero
muchos de estos proyectos
eran tan mundano como una base de datos de licencia de
conducir, un nuevo paquete de contabilidad, o un
ordenar sistema de entrada.
Por el lado de xito, el promedio es de slo el 16,2% de
los proyectos de software que son
completado On tiempo y dentro del presupuesto. En las
grandes empresas, la noticia es an
peor: slo el 9% de sus proyectos vienen en a tiempo y
dentro del presupuesto. Y, aun cuando
estos proyectos se han completado, muchos no son ms
que una mera sombra de su
requisitos de las especificaciones originales.
proyectos realizados por el ms grande de Amrica

Los

compaas tienen slo aproximadamente el 42% de las


caractersticas propuestas originalmente, y
funciones. Las empresas ms pequeas lo hacen mucho
mejor. Un total de 78,4% de su software
proyectos conseguirn desplegado con al menos el
74,2% de sus caractersticas y funciones originales.
2014 Proyecto Inteligente. Reservados todos los
derechos.
metodologa
La encuesta realizada por The Standish Group fue tan
completa como sea posible, por debajo de la
meta inalcanzable de la topografa de cada empresa con
SIG en el pas. los resultados
se basan en lo que en el Grupo Standish definir como
"hallazgos clave" de nuestra
encuestas de investigacin y varias
personales. Los encuestados fueron Italia

entrevistas

gerentes ejecutivos. La muestra incluy a grandes,


medianas y pequeas empresas
a travs de segmentos importantes de la industria, por
ejemplo, la banca, los valores, la fabricacin, el comercio
minorista,
al por mayor, de atencin de salud, seguros, servicios y
locales, estatales y federales
organizaciones. El tamao total de la muestra fue de 365
encuestados y represent 8.380

aplicaciones. Adems, The Standish Group llev a cabo


cuatro grupos de discusin y
numerosas entrevistas personales para proporcionar
contexto cualitativo de los resultados de la encuesta.
Para: efectos del Estudio, los Proyectos se clasifican en
tres Tipos de Resolucin:
Resolucin de tipo 1, o el xito del Proyecto: El
Proyecto se minar A Tiempo
y Dentro del Presupuesto, Con todas las Caractersticas y
Funciones Especificado inicialmente.
Tipo Resolucin 2, o Proyecto desafiados: El Proyecto
this Terminado y
en FUNCIONAMIENTO, Pero el Exceso de Presupuesto,
Sobre la estimacion de Tiempo, y Ofrece Menos
Caractersticas
especificados.

Funciones

Que

originalmente

Tipo Resolucin 3, o con Proyectos problemticos: El


Proyecto se Cancelo en ALGN
Momento Durante el ciclo de Desarrollo.
En general la Tasa de xito FUE Slo del 16,2%,
MIENTRAS Que los Proyectos impugnados representaron
El 52,7%, y con discapacidad (cancelado) el 31,1%.

Fracaso Estadsticas
El Grupo Standish segmentado an ms estos resultados
por las grandes, medianas y pequeas
empresas. Una gran empresa es toda empresa con ms
de 500 millones de dlares
en ingresos por ao, una empresa mediana se define
como tener $ 200 millones a $ 500
millones de dlares en ingresos anuales, y una pequea
empresa es de $ 100 millones a $ 200 millones.
Las cifras de fracaso fueron igualmente desalentador en
las empresas de todos los tamaos. Slo el 9%
de proyectos en grandes empresas tuvieron xito. En
16,2% y 28%, respectivamente,
medianas y pequeas empresas fueron algo ms xito.
Una friolera de 61,5%
de se desafiaron todos los grandes proyectos de la
empresa (Tipo Resolucin 2) en comparacin con
46,7% para las empresas medianas y el 50,4% para las
pequeas empresas. Las mayora de los proyectos,
El 37,1%, fueron impedimentos y
cancelada (Tipo Resolucin 3) en medio

posteriormente

empresas, en comparacin con 29.5% en las grandes


empresas y el 21,6% en las pequeas empresas.
Reinicia
Una de las principales causas de ambos sobrecostos y el
tiempo se reinicia. Por cada 100

proyectos que se inician, hay 94 reinicios. Esto no quiere


decir que el 94 de 100 tendr
reinicio, algunos proyectos puede tener varios reinicios.
Por ejemplo, el California
Proyecto del Departamento de Vehculos de Motor, un
escenario de fracaso resume ms adelante en este
artculo, tena muchos reinicios.
sobrecostos
Igualmente elocuente fueron los resultados de los
excesos de costes, los excesos de tiempo, y el fracaso de
la
aplicaciones
para
proporcionar
caractersticas
esperadas. Para combinado tipo 2 y tipo 3
proyectos, casi un tercio sobrecostos experimentados de
150 a 200%. el promedio
en todas las empresas es el 189% de la estimacin inicial
de costes. El coste medio
rebasamiento es de 178% para las grandes empresas,
182% para las empresas medianas, y 214% para
pequeas empresas.

IMAGEN

Tiempo Los desbordes


Por los mismos proyectos impugnados y deficientes
combinados, ms de un tercio tambin
los excesos de tiempo experimentados de entre 200 y
300%. El rebasamiento promedio es de 222% de la
estimacin de tiempo original. Para las grandes
empresas, el promedio es de 230%; para el medio
empresas, el promedio es de 202%; y para las pequeas
empresas, el promedio es de 239%.

IMAGEN

Las deficiencias de contenido


Para los proyectos con problemas, ms de un cuarto se
completaron con slo el 25% a 49%

de
caractersticas
y
funciones
especificado. En promedio, slo el
originalmente

originalmente
61% de los

caractersticas y funciones especificadas estaban


disponibles en estos proyectos. Las grandes empresas
con los peores resultados con slo el 42% de las
caractersticas y funciones en la final
producto. Para las empresas medianas, el porcentaje es
del 65%. Y para las pequeas empresas,
el porcentaje es del 74%.
En la actualidad, las 365 empresas tienen un total
combinado de 3.682 aplicaciones bajo
desarrollo. Slo 431 o el 12% de estos proyectos son a
tiempo y dentro del presupuesto.

IMAGEN

% De Caractersticas / Funciones% de las respuestas


Menos del 25% 4,6%
25-49% 27,2%
50-74% 21,8%
75-99% 39,1%
100% 7,3%
2014 Proyecto Inteligente. Reservados todos los
derechos. 7Chaos Reportar
xito / Perfiles de fallo
El aspecto ms importante de la investigacin es
descubrir por qu los proyectos fracasan. para hacer
esto, The Standish Group encuest a los directores de TI
ejecutivos por sus opiniones sobre
por qu los proyectos tengan xito. Las tres razones
principales de que un proyecto tenga xito son usuario
participacin, apoyo a la gestin ejecutiva, y una
declaracin clara de
requisitos. Hay otros criterios de xito, pero con estos
tres elementos en
lugar, las posibilidades de xito son mucho mayores. Sin
ellos, la posibilidad de fracaso
aumenta dramticamente.

Grupos de Enfoque
Para aumentar los resultados de la encuesta, The
Standish Group llev a cabo cuatro grupos focales
con los ejecutivos de TI de las grandes empresas. Los
asistentes eran de una seccin transversal de
industrias, incluyendo
federal, retail, banca,

seguros,

gobierno

estatal

valores, fabricacin y servicio. Dos de los grupos focales


fueron en Boston. la
otros dos, en San Francisco. Cada grupo focal tuvo un
promedio de diez participantes
con un total general de cuarenta y un ejecutivos de TI. El
propsito de estos enfoque particular
grupos fue para solicitar opiniones sobre por qu los
proyectos fracasan. Adems, el Grupo Standish
Las entrevistas realizadas a varios administradores de TI.
Algunos de sus comentarios son
esclarecedor sobre la variedad de problemas que aquejan
a la elaboracin de proyectos.
Muchos de los comentarios se hicieron eco de las
conclusiones de la encuesta Standish Group. "Tenemos
500 proyectos. Ninguno de ellos es a tiempo y dentro del
presupuesto. Este ao, el 40% va a quedar cancelado "
dijo Edward, Vicepresidente de MIS en una compaa
farmacutica.

Otros comentarios fueron directamente a las razones del


fracaso. Jim, el Director de TI en un
importante fabricante de equipos mdicos, dijo: "Siendo
que es una forma de pensar, es muy
difcil de obtener toda la gestin - es incluso en el nivel
local, ni siquiera en un
nivel mundial - para obtener todos los de la gestin a un
acuerdo sobre un conjunto de reglas .... Eso es un
reto en s mismo, porque tienes que, en algunos casos,
convencerlos de que esto es
mejor para la empresa, no necesariamente lo mejor para
ellos, pero lo mejor para la empresa. y
usted tiene que tener esa buy-in. Si usted no tiene que
buy-in, usted va a fracasar. Yo no
importa lo grande o pequeo que sea el proyecto es ".
John, Director de MIS en una agencia de gobierno
agreg: "Probablemente el 90% de aplicacin
el fracaso del proyecto se debe a la poltica! "Y Kathy, un
programador en una telecomunicacin
empresa, ofreci un comentario ms mordaz en la
poltica: "A veces tienes
para tomar una decisin que no le gusta. Incluso en
contra de su propia naturaleza. Dices bien, es
mal, pero a tomar esa decisin de todos modos. Es como
tomar un martillo a su dedo del pie. ella
duele ".

Bob, el Director de MIS en un hospital, coment sobre los


factores externos que contribuyen a
fracaso del proyecto. "Nuestro mayor problema est
compitiendo prioridades", dijo. "Acabamos de tener una
reorganizacin hoy. As que ahora que va a minar todos
los recursos. Y explicar a
la alta direccin de que, 'Bueno, es realmente nos
tomarse el tiempo dijimos que iba a
tomar. Pero debido a que ha reorganizado la empresa, me
voy a tomar otros seis
meses en este otro proyecto, porque estoy haciendo algo
ms para ti. 'Esa es la
. el mayor problema que tengo "Bill, el Director de MIS en
una empresa de valores, ha aadido:" Los cambios,
cambios, cambios; ellos son los verdaderos asesinos ".
Algunos de los comentarios fueron humor negro. "Los
usuarios de muerte cerebral, simplemente braindead
usuarios ", dijo Peter, un analista de aplicaciones en un
banco." Cuando el proyectado
comenz a fallar ", dijo Pablo, un programador en un
fabricante de productos personal", la
gestin se puso detrs de ella - muy por detrs ".
El comentario ms indicativo del caos en el desarrollo del
proyecto provino de Sid, un

gerente de proyectos de una compaa de seguros. "El


proyecto era de dos aos de retraso y
tres aos en el desarrollo ", dijo." Tuvimos una treintena
de personas en el proyecto. nosotros
entregado una aplicacin que el usuario no necesitaba.
Haban dejado de vender el producto
ms de un ao antes ".
Estudios de caso
Para una mayor comprensin de fracaso y el xito, The
Standish Group mir detenidamente
dos de tipo 3 (cancelado) proyectos famosa resolucin y
dos Tipo Resolucin 1
proyectos (con xito). Para efectos de comparacin, los
criterios de xito de proyectos de
se utiliz la encuesta de gerentes ejecutivos de TI para
crear un "potencial de xito" grfico.
A continuacin, se ponderaron los criterios de xito,
basado en la entrada de la TI encuest
gerentes. El criterio ms importante "participacin de los
usuarios," se le dio 19 "xito
puntos "Lo menos importante -." trabajadora, personal
enfocado "- se le dio tres
puntos. Dos criterios de xito muy importantes "expectativas realistas" y los "ms pequeos
los hitos del proyecto "- fueron ponderados en diez y
nueve puntos respectivamente Finalmente, como.

presentado ms adelante en este informe, cada uno de


los estudios de casos se calific.
DMV de California
En 1987, el Departamento de Vehculos Motorizados de
California (DMV) se embarc en un importante
proyecto para revitalizar sus conductores licencia y el
proceso de solicitud de registro. por
1993, despus de $ 45 millones de dlares ya haban sido
gastados, el proyecto fue cancelado.
Segn un informe especial emitido por el DMV, la razn
principal para volver a desarrollar
esta aplicacin fue la nueva tecnologa de adopcin. Ellos
declararon pblicamente: "La especfica
objetivo del proyecto 1987 fue utilizar la tecnologa
moderna para apoyar el DMV
misin y sostener su crecimiento mediante el
posicionamiento estratgico del proceso de datos del
DMV
medio ambiente para responder rpidamente a los
cambios. "Adems, de acuerdo con la especial DMV
informe "La eliminacin fue cambiado varias veces, pero
la comunidad tcnica DMV
nunca fue realmente confa en su viabilidad .... "
El proyecto no tuvo retorno de la inversin monetaria, no
fue apoyado por el ejecutivo

gestin, no tuvo participacin de los usuarios, tuvo la


mala planificacin, diseo pobre
especificaciones y objetivos poco claros. Tampoco
contaba con el apoyo del estado de
personal de gestin de la informacin.
El proyecto DMV no era una ciencia exacta. Hay
aplicaciones mucho ms duro que el
licencias de conducir y registros. Pero debido a la poltica
de estado internas, claro
objetivos, y la mala planificacin, el proyecto estaba
condenado desde el principio.
American Airlines
A principios de 1994, American Airlines instal su pleito
con Budget Rent-A-Car,
Marriott Corp. y Hoteles Hilton despus de la 165 millones
dlares de alquiler de coches y CONFIRM
Hotel de proyecto del sistema de reservas se derrumb
en el caos.
Este proyecto fracas porque
cocineros y la sopa en mal estado.

haba

demasiados

La direccin ejecutiva no slo apoy el proyecto, eran


proyecto activo
gerentes. Por supuesto, para un proyecto de este tamao
falle, debe haber tenido muchas fallas.
Otras causas importantes incluyen una declaracin
incompleta de los requisitos, la falta de

participacin de los usuarios, y el cambio constante de


los requisitos y especificaciones.
Hyatt Hotels
Mientras que la cadena Marriott
marchamos de su reserva no

Hilton

Hotels

sistema, Hyatt era el registro. Hoy en da, se puede


marcar desde un avin celular
telfono al 35 000 pies, comprobar en su habitacin del
hotel Hyatt, programar la cortesa
bus para que lo recoja, y tienen las llaves que le esperan
en el mostrador expresa. este
nuevo sistema de reserva era antes de lo previsto, por
debajo del presupuesto, con caractersticas adicionales por un simple de dinero contante y sonante $ 15 millones.
Utilizaron un moderno software, los sistemas abiertos
con
una base de datos Informix y el monitor de transacciones
SMOKING, el basado en Unix
hardware.
Hyatt tena todos los ingredientes necesarios para el
xito: la implicacin del usuario, ejecutivo
apoyo a la gestin, una declaracin clara de las
necesidades, la planificacin adecuada y pequea
los hitos del proyecto.

Banco Itamarati
Un ao despus de una reorientacin estratgica, Banco
Itamarati, un banco brasileo de propiedad privada,
producido un crecimiento del beneficio neto anual de
51% y pas de 47 a 15 lugar en
la
industria
bancaria
brasilea.
fundamentales explican Banco

Tres

razones

El xito de Itamarati. Primero, tenan una visin clara con


especfica documentada
objetivos. En segundo lugar, su nivel de arriba hacia
abajo de la participacin permiti Banco Itamarati a
mantener el rumbo. Y, por ltimo, el banco produjo,
resultados medibles incrementales
durante
todo
implementacin.

el

perodo

de

planificacin

Claro objetivo de negocio de Banco Itamarati es ser uno


de los cinco mejores de capital privado de Brasil
bancos para el ao 2000. Sus objetivos incluyen el
mantenimiento de una estrecha relacin
con sus clientes para mejorar
comprensin de sus necesidades,

ofreciendo
soluciones
financieras
garantizando la satisfaccin del cliente, y

mantener

una

competitivas,

finalmente producir resultados equilibrados para el


Grupo Itamarati. Banco Itamarati de

objetivos se incorporaron en un plan estratgico que


identifica claramente medible
resultados y la propiedad individual.
Su plan estratgico de tecnologa hizo un componente
clave de la estrategia de negocio.
Itamarati utiliza monitor de OLTP GRIP de Itautec como
una herramienta bsica para la integracin de software
componentes. Segn Henrique Costabile, director de
Organizacin
Desarrollo, "Somos uno de los primeros bancos para
implementar un cliente-servidor
arquitectura que maximiza el
arquitectura. "liderazgo ejecutivo,

potencial

de

esta

un plan bien comunicada, y un equipo diverso experto


proporcionaron la base para
Banco Itamarati para lograr su objetivo a largo plazo,
posiblemente antes de lo previsto.
Conclusiones Estudio de caso
El estudio de cada proyecto incluy la suma de puntos de
xito en el "xito
tabla potencial ".
Con slo 10 puntos de xito, el proyecto DMV tena
prcticamente ninguna posibilidad de xito.
Con 100 puntos de xito, el proyecto de la reserva del
Hyatt tena todos los ingredientes adecuados para

el xito. Con slo 29 puntos de xito, el proyecto


CONFIRMAR tena pocas posibilidades de
el xito. Con 85, Itamarati, aunque no es tan seguro como
Hyatt, comenz con una alta
probabilidad de xito.
El puente hacia el xito
No obstante, este estudio es apenas en profundidad
suficiente para proporcionar una solucin real a
un problema de enormes proporciones como las actuales
tasas de fracaso del proyecto. El software de aplicacin
proyectos son verdaderamente en ro revuelto. Con el fin
de poner orden en el caos, nos
que examinar por qu los proyectos fracasan. Al igual
que los puentes, cada falla de software importante
debe ser investigado, estudiado, informado y compartido.
Debido a que es el producto de las ideas de los
administradores de TI, el "xito potencial" carta
puede ser una herramienta til tanto para pronosticar el
xito potencial de un proyecto o
evaluar el fracaso del proyecto.
Investigacin en el Grupo Standish tambin indica que
los marcos de tiempo ms pequeo, con
la entrega de componentes de software temprano y con
frecuencia, aumentar la tasa de xito.

Marcos de tiempo ms cortos resultan en un proceso


iterativo de diseo, prototipos, desarrollar, probar,
y desplegar elementos pequeos. Este proceso se
conoce como "creciente" de software, como
opuesto al viejo concepto de software "en desarrollo".
Cultivo de software se acopla a la
usuario anteriormente, cada componente tiene
propietario o un pequeo conjunto de propietarios, y

un

expectativas se establecen de manera realista. Adems,


cada componente de software tiene una clara
y declaracin precisa y un conjunto de objetivos. Los
componentes de software y los pequeos
proyectos tienden a ser menos compleja. Hacer los
proyectos ms simple es una pena
esforzar porque complejidad hace que slo confusin y
mayor costo.
Hay un ltimo aspecto a considerar en cualquier grado de
fracaso del proyecto. todos
xito se basa en cualquiera suerte o el fracaso. Si usted
comienza con suerte, se aprende nada
pero la arrogancia. Sin embargo, si usted comienza con el
fracaso y aprender a valorarla, tambin
aprender a tener xito. Si no engendra conocimiento.
Fuera de conocimientos que adquiera la sabidura,
y es con la sabidura que puede convertirse en un
verdadero xito.

The Standish Group 1995. Reproducido aqu con fines


acadmicos nicos con escrito
permiso de The Standish Group.

También podría gustarte