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 de Transarc Corporation,
co-autor de un documentola comparacin de la construccin de puentes
para el desarrollo de software. La premisa: Los puentes
sonnormalmente construida en tiempo, presupuesto situ, y no caer.
Por otro lado, softwareNunca 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.
Muchosproyectos de construccin de puentes rebasen sus presupuestos,
plazos, y algunos incluso cayeronhacia abajo.
Una de las mayores razones por las que los puentes vienen en el
tiempo, dentro del presupuesto y no se caiganes debido a la extrema
detalle de diseo. El diseo es congelado y el contratistatiene poca
flexibilidad en el cambio de las especificaciones. Sin embargo, en
rpido movimiento de hoyentorno empresarial, un diseo congelado no
se acomoda a los cambios en elprcticas empresariales. Por lo tanto
un modelo ms flexible debe ser utilizado. Esto podra sery 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 lado3.000 aos de experiencia. Cuando un puente se cae,
se investiga y un informeque est escrito en la causa de la falla.
Esto no es as en la industria informtica, dondefracasos estn
cubiertos hasta, ignorados, y / o racionalizarse. Como resultado,
mantenemos la tomalos mismos errores una y otra vez.En
consecuencia, el enfoque de este ltimo proyecto de investigacin en
el Grupo Standish tienesido 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 faltaEn los Estados Unidos, gastamos ms de $
250 mil millones cada ao en la aplicacin informticadesarrollo de
aproximadamente 175.000 proyectos. El costo promedio de un
desarrolloproyecto 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 tresmonos - or ningn fracaso, ver
ningn fracaso, no hable ni fracasos.
La investigacin Standish Group muestra un asombroso 31,1% de los
proyectos ser decancelado antes de que alguna vez se completan.
Otros resultados indican el 52,7% de los proyectostendr un costo de
189% de sus estimaciones originales. El costo de estos fracasos y
excesos sonslo 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 deDenver para darse
cuenta de la magnitud de este problema. La falta de presentacin de
software fiablepara 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 Amricaempresas y agencias gubernamentales gastarn $ 81
mil millones para el software canceladoproyectos. Estas mismas
organizaciones pagarn un adicional de $ 59,000,000,000 para el
softwareproyectos que se completaron, pero superarn sus
estimaciones de tiempo originales. El riesgo essiempre un factor al
empujar el sobre tecnologa, pero muchos de estos proyectoseran tan
mundano como una base de datos de licencia de conducir, un nuevo
paquete de contabilidad, o unordenar sistema de entrada.
Por el lado de xito, el promedio es de slo el 16,2% de los
proyectos de software que soncompletado On tiempo y dentro del
presupuesto. En las grandes empresas, la noticia es anpeor: slo el
9% de sus proyectos vienen en a tiempo y dentro del presupuesto. Y,
aun cuandoestos proyectos se han completado, muchos no son ms que
una mera sombra de surequisitos de las especificaciones originales.
Los proyectos realizados por el ms grande de Amricacompaas tienen
slo aproximadamente el 42% de las caractersticas propuestas
originalmente, yfunciones. Las empresas ms pequeas lo hacen mucho
mejor. Un total de 78,4% de su softwareproyectos conseguirn
desplegado con al menos el 74,2% de sus caractersticas y funciones
originales. 2014 Proyecto Inteligente. Reservados todos los
derechos.
metodologaLa encuesta realizada por The Standish Group fue tan
completa como sea posible, por debajo de lameta inalcanzable de la
topografa de cada empresa con SIG en el pas. los resultadosse basan
en lo que en el Grupo Standish definir como "hallazgos clave" de
nuestraencuestas de investigacin y varias entrevistas personales.
Los encuestados fueron Italiagerentes ejecutivos. La muestra incluy
a grandes, medianas y pequeas empresasa 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
federalesorganizaciones. El tamao total de la muestra fue de 365
encuestados y represent 8.380aplicaciones. Adems, The Standish
Group llev a cabo cuatro grupos de discusin ynumerosas 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 Tiempoy Dentro del Presupuesto, Con todas las
Caractersticas y Funciones Especificado inicialmente. Tipo
Resolucin 2, o Proyecto desafiados: El Proyecto this Terminado yen
FUNCIONAMIENTO, Pero el Exceso de Presupuesto, Sobre la estimacion
de Tiempo, y Ofrece MenosCaractersticas y Funciones Que
originalmente especificados. Tipo Resolucin 3, o con Proyectos
problemticos: El Proyecto se Cancelo en ALGNMomento Durante el
ciclo de Desarrollo.En general la Tasa de xito FUE Slo del 16,2%,
MIENTRAS Que los Proyectos impugnados representaronEl 52,7%, y con
discapacidad (cancelado) el 31,1%.
Fracaso EstadsticasEl Grupo Standish segmentado an ms estos
resultados por las grandes, medianas y pequeasempresas. Una gran
empresa es toda empresa con ms de 500 millones de dlaresen ingresos
por ao, una empresa mediana se define como tener $ 200 millones a $
500millones 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 con46,7% para las
empresas medianas y el 50,4% para las pequeas empresas. Las mayora
de los proyectos,El 37,1%, fueron impedimentos y posteriormente
cancelada (Tipo Resolucin 3) en medioempresas, en comparacin con
29.5% en las grandes empresas y el 21,6% en las pequeas
empresas.ReiniciaUna de las principales causas de ambos sobrecostos
y el tiempo se reinicia. Por cada 100proyectos que se inician, hay
94 reinicios. Esto no quiere decir que el 94 de 100 tendrreinicio,
algunos proyectos puede tener varios reinicios. Por ejemplo, el
CaliforniaProyecto del Departamento de Vehculos de Motor, un
escenario de fracaso resume ms adelante en esteartculo, tena muchos
reinicios.
sobrecostosIgualmente elocuente fueron los resultados de los
excesos de costes, los excesos de tiempo, y el fracaso de
laaplicaciones para proporcionar caractersticas esperadas. Para
combinado tipo 2 y tipo 3proyectos, casi un tercio sobrecostos
experimentados de 150 a 200%. el promedioen todas las empresas es
el 189% de la estimacin inicial de costes. El coste
mediorebasamiento es de 178% para las grandes empresas, 182% para
las empresas medianas, y 214% parapequeas empresas.
IMAGEN
Tiempo Los desbordesPor los mismos proyectos impugnados y
deficientes combinados, ms de un tercio tambinlos excesos de tiempo
experimentados de entre 200 y 300%. El rebasamiento promedio es de
222% de laestimacin de tiempo original. Para las grandes empresas,
el promedio es de 230%; para el medioempresas, el promedio es de
202%; y para las pequeas empresas, el promedio es de 239%.
IMAGEN
Las deficiencias de contenidoPara los proyectos con problemas,
ms de un cuarto se completaron con slo el 25% a 49%de
caractersticas y funciones originalmente especificado. En promedio,
slo el 61% de los originalmentecaractersticas y funciones
especificadas estaban disponibles en estos proyectos. Las grandes
empresascon los peores resultados con slo el 42% de las
caractersticas y funciones en la finalproducto. 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 bajodesarrollo. Slo 431 o el 12% de estos
proyectos son a tiempo y dentro del presupuesto.
IMAGEN
% De Caractersticas / Funciones% de las respuestasMenos 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 Reportarxito /
Perfiles de falloEl aspecto ms importante de la investigacin es
descubrir por qu los proyectos fracasan. para haceresto, The
Standish Group encuest a los directores de TI ejecutivos por sus
opiniones sobrepor qu los proyectos tengan xito. Las tres razones
principales de que un proyecto tenga xito son usuarioparticipacin,
apoyo a la gestin ejecutiva, y una declaracin clara derequisitos.
Hay otros criterios de xito, pero con estos tres elementos enlugar,
las posibilidades de xito son mucho mayores. Sin ellos, la
posibilidad de fracasoaumenta dramticamente.
Grupos de EnfoquePara aumentar los resultados de la encuesta,
The Standish Group llev a cabo cuatro grupos focalescon los
ejecutivos de TI de las grandes empresas. Los asistentes eran de
una seccin transversal deindustrias, incluyendo seguros, gobierno
estatal y federal, retail, banca,valores, fabricacin y servicio.
Dos de los grupos focales fueron en Boston. laotros dos, en San
Francisco. Cada grupo focal tuvo un promedio de diez
participantescon un total general de cuarenta y un ejecutivos de
TI. El propsito de estos enfoque particulargrupos fue para
solicitar opiniones sobre por qu los proyectos fracasan. Adems, el
Grupo StandishLas entrevistas realizadas a varios administradores
de TI. Algunos de sus comentarios sonesclarecedor 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. "Tenemos500 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 unimportante fabricante de
equipos mdicos, dijo: "Siendo que es una forma de pensar, es
muydifcil de obtener toda la gestin - es incluso en el nivel local,
ni siquiera en unnivel mundial - para obtener todos los de la
gestin a un acuerdo sobre un conjunto de reglas .... Eso es unreto
en s mismo, porque tienes que, en algunos casos, convencerlos de
que esto esmejor para la empresa, no necesariamente lo mejor para
ellos, pero lo mejor para la empresa. yusted tiene que tener esa
buy-in. Si usted no tiene que buy-in, usted va a fracasar. Yo
noimporta lo grande o pequeo que sea el proyecto es ".
John, Director de MIS en una agencia de gobierno agreg:
"Probablemente el 90% de aplicacinel fracaso del proyecto se debe a
la poltica! "Y Kathy, un programador en una telecomunicacinempresa,
ofreci un comentario ms mordaz en la poltica: "A veces tienespara
tomar una decisin que no le gusta. Incluso en contra de su propia
naturaleza. Dices bien, esmal, pero a tomar esa decisin de todos
modos. Es como tomar un martillo a su dedo del pie. elladuele
".
Bob, el Director de MIS en un hospital, coment sobre los
factores externos que contribuyen afracaso del proyecto. "Nuestro
mayor problema est compitiendo prioridades", dijo. "Acabamos de
tener unareorganizacin hoy. As que ahora que va a minar todos los
recursos. Y explicar ala alta direccin de que, 'Bueno, es realmente
nos tomarse el tiempo dijimos que iba atomar. Pero debido a que ha
reorganizado la empresa, me voy a tomar otros seismeses 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 braindeadusuarios ", dijo Peter, un
analista de aplicaciones en un banco." Cuando el proyectadocomenz a
fallar ", dijo Pablo, un programador en un fabricante de productos
personal", lagestin se puso detrs de ella - muy por detrs ".El
comentario ms indicativo del caos en el desarrollo del proyecto
provino de Sid, ungerente de proyectos de una compaa de seguros.
"El proyecto era de dos aos de retraso ytres aos en el desarrollo
", dijo." Tuvimos una treintena de personas en el proyecto.
nosotrosentregado una aplicacin que el usuario no necesitaba. Haban
dejado de vender el productoms de un ao antes ".
Estudios de casoPara una mayor comprensin de fracaso y el xito,
The Standish Group mir detenidamentedos de tipo 3 (cancelado)
proyectos famosa resolucin y dos Tipo Resolucin 1proyectos (con
xito). Para efectos de comparacin, los criterios de xito de
proyectos dese 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
encuestgerentes. El criterio ms importante "participacin de los
usuarios," se le dio 19 "xitopuntos "Lo menos importante -."
trabajadora, personal enfocado "- se le dio trespuntos. Dos
criterios de xito muy importantes - "expectativas realistas" y los
"ms pequeoslos 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 CaliforniaEn 1987, el Departamento de Vehculos
Motorizados de California (DMV) se embarc en un importanteproyecto
para revitalizar sus conductores licencia y el proceso de solicitud
de registro. por1993, 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 desarrollaresta
aplicacin fue la nueva tecnologa de adopcin. Ellos declararon
pblicamente: "La especficaobjetivo del proyecto 1987 fue utilizar
la tecnologa moderna para apoyar el DMVmisin y sostener su
crecimiento mediante el posicionamiento estratgico del proceso de
datos del DMVmedio ambiente para responder rpidamente a los
cambios. "Adems, de acuerdo con la especial DMVinforme "La
eliminacin fue cambiado varias veces, pero la comunidad tcnica
DMVnunca fue realmente confa en su viabilidad .... "El proyecto no
tuvo retorno de la inversin monetaria, no fue apoyado por el
ejecutivogestin, no tuvo participacin de los usuarios, tuvo la mala
planificacin, diseo pobreespecificaciones y objetivos poco claros.
Tampoco contaba con el apoyo del estado depersonal de gestin de la
informacin.El proyecto DMV no era una ciencia exacta. Hay
aplicaciones mucho ms duro que ellicencias de conducir y registros.
Pero debido a la poltica de estado internas, claroobjetivos, y la
mala planificacin, el proyecto estaba condenado desde el
principio.
American AirlinesA 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
CONFIRMHotel de proyecto del sistema de reservas se derrumb en el
caos.Este proyecto fracas porque haba demasiados cocineros y la
sopa en mal estado.La direccin ejecutiva no slo apoy el proyecto,
eran proyecto activogerentes. 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 departicipacin de los usuarios, y el cambio constante de
los requisitos y especificaciones.
Hyatt HotelsMientras que la cadena Marriott y Hilton Hotels
marchamos de su reserva nosistema, Hyatt era el registro. Hoy en
da, se puede marcar desde un avin celulartelfono al 35 000 pies,
comprobar en su habitacin del hotel Hyatt, programar la cortesabus
para que lo recoja, y tienen las llaves que le esperan en el
mostrador expresa. estenuevo 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
conuna base de datos Informix y el monitor de transacciones
SMOKING, el basado en Unixhardware.Hyatt tena todos los
ingredientes necesarios para el xito: la implicacin del usuario,
ejecutivoapoyo a la gestin, una declaracin clara de las
necesidades, la planificacin adecuada y pequealos hitos del
proyecto.
Banco ItamaratiUn 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 enla industria bancaria brasilea. Tres razones fundamentales
explican BancoEl xito de Itamarati. Primero, tenan una visin clara
con especfica documentadaobjetivos. En segundo lugar, su nivel de
arriba hacia abajo de la participacin permiti Banco Itamarati
amantener el rumbo. Y, por ltimo, el banco produjo, resultados
medibles incrementalesdurante todo el perodo de planificacin /
implementacin.
Claro objetivo de negocio de Banco Itamarati es ser uno de los
cinco mejores de capital privado de Brasilbancos para el ao 2000.
Sus objetivos incluyen el mantenimiento de una estrecha relacincon
sus clientes para mejorar y mantener una comprensin de sus
necesidades,ofreciendo soluciones financieras competitivas,
garantizando la satisfaccin del cliente, yfinalmente producir
resultados equilibrados para el Grupo Itamarati. Banco Itamarati
deobjetivos se incorporaron en un plan estratgico que identifica
claramente medibleresultados 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 softwarecomponentes.
Segn Henrique Costabile, director de OrganizacinDesarrollo, "Somos
uno de los primeros bancos para implementar un
cliente-servidorarquitectura que maximiza el potencial de esta
arquitectura. "liderazgo ejecutivo,un plan bien comunicada, y un
equipo diverso experto proporcionaron la base paraBanco Itamarati
para lograr su objetivo a largo plazo, posiblemente antes de lo
previsto.
Conclusiones Estudio de casoEl estudio de cada proyecto incluy
la suma de puntos de xito en el "xitotabla 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 parael
xito. Con slo 29 puntos de xito, el proyecto CONFIRMAR tena pocas
posibilidades deel xito. Con 85, Itamarati, aunque no es tan seguro
como Hyatt, comenz con una altaprobabilidad de xito.
El puente hacia el xitoNo obstante, este estudio es apenas en
profundidad suficiente para proporcionar una solucin real aun
problema de enormes proporciones como las actuales tasas de fracaso
del proyecto. El software de aplicacinproyectos son verdaderamente
en ro revuelto. Con el fin de poner orden en el caos, nosque
examinar por qu los proyectos fracasan. Al igual que los puentes,
cada falla de software importantedebe ser investigado, estudiado,
informado y compartido.Debido a que es el producto de las ideas de
los administradores de TI, el "xito potencial" cartapuede ser una
herramienta til tanto para pronosticar el xito potencial de un
proyecto oevaluar el fracaso del proyecto.
Investigacin en el Grupo Standish tambin indica que los marcos
de tiempo ms pequeo, conla 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, comoopuesto al
viejo concepto de software "en desarrollo". Cultivo de software se
acopla a lausuario anteriormente, cada componente tiene un
propietario o un pequeo conjunto de propietarios, yexpectativas se
establecen de manera realista. Adems, cada componente de software
tiene una claray declaracin precisa y un conjunto de objetivos. Los
componentes de software y los pequeosproyectos tienden a ser menos
compleja. Hacer los proyectos ms simple es una penaesforzar porque
complejidad hace que slo confusin y mayor costo.Hay un ltimo
aspecto a considerar en cualquier grado de fracaso del proyecto.
todosxito se basa en cualquiera suerte o el fracaso. Si usted
comienza con suerte, se aprende nadapero la arrogancia. Sin
embargo, si usted comienza con el fracaso y aprender a valorarla,
tambinaprender 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 escritopermiso de The Standish Group.