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.