Los criterios para el xito de un proyecto de TI

El 69% de los proyectos tecnolgicos fracasa, segn The Standish Group

Hay una tradicin en la direccin de proyectos de TI que establece que un proyecto es un
xito si se cumple en plazo, sin pasarse del presupuesto y con las funciones requeridas.
Cumplir esos parmetros es bastante complicado. De hecho, un estudio realizado por The
Standish Group seala que slo el 29% de los proyectos tiene xito.
Un estudio elaborado por The Standish Group muestra, tras analizar retrospectivamente
72 proyectos de TI en 57 empresas distintas desde 1999, que proyectos que haban
cumplido todos los criterios tradicionales para considerarlos un xito (tiempo y dinero)
haban acabado, pese a todo, en fracaso porque no supieron atraer a los usuarios
potenciales o porque no implicaron demasiados beneficios para la empresa. Estos casos
se denominan por la consultora xitos fallidos, ya que el proyecto cumpla con todos los
requisitos, pero no consigui integrarse en los procesos financieros de la compaa, con
lo que, al final, pasaron desapercibidos. Segn explic el CIO de una gran empresa, la
aplicacin funciona al 100% cuando hay una participacin del 100% y al 0% cuando lo
utiliza un 95%.
Del mismo modo, algunos proyectos, que se podran considerar un fracaso segn los
parmetros tradicionales de TI, pueden acabar siendo exitosos porque, pese a sus
problemas de coste o tiempo, el sistema triunfa entre su audiencia potencial o acaba
dando unos beneficios inesperados.
Nuevos principios
Muchas veces, puede que el verdadero impacto de un proyecto no se llegue a apreciar
hasta mucho tiempo despus de que se complete su implantacin. Segn la consultora
Standish Group, en un proyecto, ms all de las tradicionales medidas de tiempo y coste,
deben aplicarse otros criterios para determinar su xito, como son el grado de utilizacin
del sistema o servicios, y de beneficio, donde el proyecto influye directamente en un
aumento de la eficiencia de la empresa. Otro criterio es la formacin, que el proyecto
aumente los conocimientos de los participantes y prepare mejor a la organizacin de cara
a futuros retos.
En el informe realizado por Standish Group se pone de manifiesto que, tras analizar a
todos los involucrados (jefes de proyecto, sus equipos, patrocinadores del proyecto, altos
ejecutivos y usuarios), los tres criterios principales por los que stos juzgaban el xito de
un proyecto fueron producto, uso y valor, respectivamente. Por contra, el gasto ocup el
ltimo lugar del ranking. Ninguno de los grupos mencionaron la formacin (prepararse
para el futuro) entre sus tres criterios principales, aunque todos ellos sugirieron que esta
formacin era un asunto de, al menos, una importancia moderada. Aunque los jefes de
proyecto y los miembros de sus equipos parecan estar ms preocupados por llevar a
cabo el proyecto segn las caractersticas requeridas (a tiempo y sin salirse del
presupuesto), los usuarios estaban ms preocupados de si el sistema se podra usar tal y
como se pretenda. Es difcil asumir esta perspectiva durante el curso del proyecto. Los
asuntos que preocupan ms a los usuarios son, uso y valor, no pueden resolverse hasta
que el proyecto est completo en su sentido tradicional. Si maximizar la satisfaccin
general de los afectados e involucrados por el proyecto es importante, los altos ejecutivos
deberan centrarse ms en los criterios de producto, uso y valor.
Esta es la razn por la que es crucial que los CIOs revisen los proyectos tanto durante
como despus de la implantacin si quieren crear y mantener una tasa de xito a largo
plazo. De esta forma, las retrospectivas deberan llevarse a cabo despus de alcanzar
cada objetivo principal dentro de los grandes proyectos, y una o dos semanas despus de

su finalizacin. El anlisis de los beneficios debera llevarse a cabo ms tarde, cuando se

aprecie de forma legtima su impacto en el negocio.
Las ventajas de mirar atrs
Muchas veces las retrospectivas ofrecen una variedad de ventajas potenciales. Las
revisiones permiten a los participantes ver ms all de sus impresiones personales del
proyecto y presentan una visin ms amplia del impacto en la organizacin. Las
revisiones tambin dan la oportunidad de hacer mejoras en los procesos, procedimientos
e intenciones, en vez de tratar cada proyecto como algo nico, olvidando o ignorando las
lecciones de los anteriores. Es posible estimar y planificar mejor los futuros proyectos,
dado que las revisiones recogen datos histricos acerca del tiempo y el esfuerzo real que
requirieron y su verdadero alcance. Finalmente, estas revisiones tienen un aspecto
humano imposible de cuantificar. Si un proyecto funcionara mal, los profesionales podran
reconocer y reparar sus problemas personales en la relacin de trabajo para que los
futuros lo hicieran mejor. Si el proyecto acaba en xito, la revisin le permite a uno
deleitarse en lo que ha hecho bien antes de lidiar con el siguiente problema.
Las revisiones de proyectos llevan ms all el concepto de la planificacin temporal de un
proyecto. Los directores de stos deben negociar las ventajas y los obstculos entre
proceso (tiempo y coste) y resultado (uso, formacin y beneficio comercial). El documento
inicial del proyecto debera incluir patrones de xito, la gua de camino debera permitir
mediciones en tiempo real, y la retrospectiva del proyecto debera documentar los
resultados reales para obtener, como conclusin, la satisfaccin general de todos los
involucrados.
Razones Por qu fracasan los proyectos
Por Tom Carlos PMP
En un mundo perfecto, cada proyecto sera "a tiempo y dentro del presupuesto." Pero la
realidad (especialmente el estadsticas comprobadas) cuenta una historia muy diferente. No
es raro que los proyectos fracasen. Incluso si el presupuesto y el calendario se cumplen, hay
que preguntarse "qu el proyecto de entregar los resultados y la calidad que
espera? "xito verdadero proyecto debe ser evaluado en los tres componentes. De lo
contrario, un proyecto podra ser considerado como un "fracaso".
Alguna vez has visto una situacin en la que los proyectos comienzan a mostrar signos de
desorganizacin, apareces fuera de control, y tienen un sentido de la fatalidad y el fracaso?
Ha sido testigo de configuracin donde todo el mundo trabaja en un silo y nadie parece saber
lo que el otro miembro del equipo que est haciendo? Qu pasa con los miembros del equipo
que viven por el credo "Voy a hacer mi parte (como yo lo veo conveniente) y despus de eso,
es su problema."
Peor an es cuando los miembros del equipo recurren a sealar con el dedo. Situaciones
similares a estos escenarios apuntar a un cartel que dice "peligro". Y si lees la letra pequea
debajo de la palabra "peligro", se lee, "su proyecto tiene que ser controlada o de lo contrario
podra fallar."
Cuando los proyectos comienzan a mostrar signos de estrs y el fracaso, todo el mundo mira
al jefe de proyecto en busca de respuestas. Puede parecer injusto que la carga de la
condenacin recae sobre un solo individuo. Pero esto es
la razn por la que eligi para administrar proyectos para ganarse la vida! Usted ha sido
entrenado para reconocer y hacer frente a este tipo de situaciones.
Hay muchas razones por qu los proyectos (simples y complejos) fallan; el nmero de razones
puede ser infinita. Sin embargo, si aplicamos la regla 80/20 las razones ms comunes de falla
se pueden encontrar en la siguiente lista:

Objetivos no definidos deficientemente administradas y metas

Falta de gestin
compromiso
La falta de un slido plan de proyecto Falta de Falta de entrada de usuario de apoyo
organizacional
Gestin proactiva centralizada
iniciativas para combatir los riesgos del proyecto
Gestin de la empresa de los recursos del presupuesto
Proporciona plantillas universales y documentacin
Papeles mal definidos y responsabilidades Inadecuada o imprecisa conflicto requisitos de las
partes interesadas debilidades del equipo
Plazos poco realistas y tareas que compiten prioridades
Mala comunicacin La insuficiencia de recursos
(fondos y personal) la poltica de negocio Incumplimiento de los horarios y los costos
estimados para el costo y horario son errneos
La falta de priorizacin y gestin de cartera de proyectos
Alcance fluencia No hay control de cambios expectativas de los usuarios finales Reunin
proceso
Haciendo caso omiso de las seales de advertencia de proyectos prueba Incorrecta
procesos Malas decisiones Incluso con la mejor de las intenciones o planes slidos, proyecto
puede ir mal si no se manejan correctamente. Con demasiada frecuencia, pueden ocurrir
contratiempos (y usualmente lo hacen). Esto es cuando el director del proyecto
debe reconocer una seal de peligro y tomar medidas. Si usted entiende la diferencia entre
sntomas y problemas y pueden identificar las seales de advertencia de fracaso del proyecto,
su formacin le ayudar a tomar medidas para enderezar el barco antes de que se desploma.
S, es la responsabilidad del director del proyecto para corregir la lista de nadie ms. Adems
de aplicar la clase de gestin inproject lucha procesos y principios tau, tambin puede utilizar
sus habilidades para el trabajo personal de comunicacin, gestin, liderazgo, resolucin de
conflictos y la diplomacia para tomar medidas correctivas.
Durante el transcurso de la gestin de un proyecto, el director del proyecto debe monitorear
activi dades (y distracciones) de muchas fuentes y direcciones. La complacencia puede
configurar fcilmente. Cuando esta sucede, el proceso de "supervisin" se rompe. Por ello, el
director del proyecto debe permanecer en el control de un proyecto y estar al tanto de
cualquier actividad que presenta un riesgo de fracaso del proyecto. S, es por eso que "se le
paga mucho dinero."
Tom Carlos tiene ms de 20 aos de experiencia acumulada en los negocios, tcnica, y
capacitacin ambientes. l es un Certified Project Management Professional (PMP) y miembro
de la Sacramento Valley Captulo PMI. Para otros artculos sobre el tema similar, se puede
visitar
www.carlosconsulting.com o pngase en contacto con l en tom@carlosconsulting.com.
El Grupo Standish
El Standish Group International, Inc., es una empresa de investigacin de mercado y
consultora especializada en
misin crtica software y comercio electrnico. Sus productos incluyen una informacin
continua servicio basado en un mximo al da el anlisis de mercado; VirtualADVISOR, un
servicio de soluciones de expertos cuya suscriptores disfrutan de privilegios de consulta de
gestin de proyectos ilimitadas; y la Universidad de CAOS, un retiro anual en la que los
ejecutivos de alto nivel (Tecnologa de la Informacin) de TI se unen para compartir

sus experiencias y encontrar soluciones a problemas comunes. The Standish Group ofrece
crtico informacin y soluciones activas para gerentes, gerentes de desarrollo de aplicaciones
de proyectos y de TI ejecutivos preocupados por el desarrollo e implementacin de soluciones
de negocio. Este documento informativo servicio se basa en una investigacin en profundidad
primaria con el apoyo de una mejora riguroso proceso ciclo. Mejora del proceso constante,
junto con un sistema de retroalimentacin formal, asegura la ltima en el pensamiento
avanzado.
Su sitio web es www.standishgroup.com
Informes trimestrales de investigacin del Grupo Standish son un resumen de nuestros
programas de investigacin.
Recogidos durante el ao calendario es de datos de DARDOS (Requisitos de evaluacin de la
demanda Tracking Survey), CENTAVOS mensuales, CAOS Investigacin y Focus Groups. Para
actualizar la informacin que se centra en cuestiones y tendencias en la comunidad est
organizada y acentuados con fullcolor tablas y grficos. Estos informes son tambin una
caracterstica de nuestra INTELIGENTE (Gestin Standish Advisory Research Triangle)
"investigacin activa" del Programa junto con DARDOS mensuales
y el VirtualBEACON (un boletn electrnico semanal).
The Standish Group en Gestin de Proyectos
The Standish Group se centra en la planificacin de la inversin en TI. Cuando las empresas
invierten en TI
proyectos de desarrollo que quieren un cambio de su inversin. El Grupo Standish tiene
investig los proyectos de TI ya travs de su investigacin caos que han hecho algunas
conclusiones.
Puntos destacados del informe CHAOS (1994)
"En 1986, Alfred Spector, presidente de Transarc Corporation, co-autor de un artculo
comparando la construccin de puentes para el desarrollo de software. La premisa: Los
puentes se construyen normalmente a tiempo, en presupuesto, y no se caiga. Por otra parte, el
software nunca llega a tiempo o en presupuesto.
Adems, siempre se rompe. (Sin embargo, la construccin de puentes no siempre tienen tal
brillante trayectoria. Muchos de los proyectos de construccin de puentes rebasen sus
presupuestos, plazos, y algunos incluso se cay.)
Una de las razones ms grandes puentes vienen a tiempo, dentro del presupuesto y no se caen
es porque de 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 entorno
empresarial de hoy en da, un congelado diseo no se acomoda a los cambios en las prcticas
comerciales. Por lo tanto una ms flexible modelo debe ser utilizado. Esto podra ser y ha sido
utilizado como una razn para el fracaso del desarrollo.
Pero hay otra diferencia entre los fallos de software y fallos de puente, al lado de 3.000 aos
de experiencia. Cuando un puente se cae, se investiga y se redacta un informe sobre la causa
de la el fracaso. Esto no es as en la industria de la computacin donde las fallas son
encubiertos, ignorados, y / o racionalizado. Como resultado de ello, seguimos cometiendo los
mismos errores una y otra vez. "Datos adicionales:
Los resultados indican el 52,7% de los proyectos tendr un costo de 189% de sus previsiones
iniciales.
Los costos de oportunidad perdidos no son medibles, pero podra ser fcilmente en los
billones de dlares. en 1.995 empresas estadounidenses y agencias gubernamentales gastarn
$ 81 mil millones para proyectos de software cancelados. Estas mismas organizaciones
pagarn un adicional de $ 59,000,000,000 para proyectos de software que lo har
ser completado, pero superar sus estimaciones de tiempo originales.

Slo el 9% de sus proyectos vienen en el tiempo y en presupuesto. Y, aun cuando estos

proyectos son completado, muchos no son ms que una mera sombra de sus requisitos de las
especificaciones originales.
Los proyectos realizados por las ms grandes empresas estadounidenses tienen slo
aproximadamente el 42% de la originalmente propuesto caractersticas y funciones.
Reinicia
Una de las principales causas de ambos sobrecostos y el tiempo se reinicia. Para cada 100
proyectos que comienzan, hay 94 reinicios. sobrecostos La media de todas las empresas es de
189% de la estimacin inicial de costos. El coste medio rebasamiento es de 178% para las
grandes empresas, 182% para las empresas medianas, y 214% para los pequeos empresas.
Tiempo Rebasamientos
El rebasamiento promedio es de 222% de la estimacin de tiempo original. Para las grandes
empresas, el promedio es de 230%; para las empresas medianas, el promedio es de 202%; y
para las pequeas empresas, el promedio es de
239%.
Las deficiencias de contenido
Para los proyectos con problemas, ms de un cuarto se completaron con slo el 25% a 49% de
originallyspecified caractersticas y funciones. En promedio, slo el 61% de las caractersticas
especificadas originalmente y funciones disponibles en estos proyectos. Las grandes empresas
tienen el peor rcord con slo el 42% de las caractersticas y funciones en el producto final.
Para las empresas medianas, el porcentaje es del 65%.
Y para las pequeas empresas, el porcentaje es del 74%. xito / Perfiles de fallo
El aspecto ms importante de la investigacin es descubrir por qu los proyectos fracasan.
Para ello, el Standish Group encuest a los directores ejecutivos de TI de sus opiniones acerca
de por qu los proyectos tengan xito.
Las tres razones principales de que un proyecto tenga xito son la implicacin del usuario, la
direccin ejecutiva apoyo, y una declaracin clara de los requisitos.
"Probablemente el 90% de fracaso de los proyectos de aplicacin se debe a la poltica!"
DMV de California Falla - El proyecto no tuvo recuperacin monetaria, no fue apoyada por
ejecutivo gestin, no tuvo participacin de los usuarios, tuvo la mala planificacin,
especificaciones de diseo y pobres objetivos poco claros. Tampoco contaba con el apoyo de
personal de gestin de la informacin del estado.
American Airlines fracaso - Este proyecto fracas porque haba demasiados cocineros y la
sopa en mal estado. La direccin ejecutiva no slo apoy el proyecto, estaban proyecto activo
gerentes. Por supuesto, para un proyecto de este tamao falle, que debe haber tenido muchos
defectos. otro importante causas incluyen una declaracin incompleta de requisitos, la falta de
participacin de los usuarios, y la constante cambiante de los requisitos y especificaciones.
Hoteles Hyatt xito - Hyatt tena todos los ingredientes para el xito: participacin de los
usuarios, apoyo ejecutivo de gestin, una declaracin clara de las necesidades, la planificacin
adecuada, y pequeas los hitos del proyecto.
Banco Itamarati xito - En primer lugar, tena una visin clara de los objetivos especficos
documentados.
En segundo lugar, su nivel de arriba hacia abajo de la participacin permiti Banco Itamarati
mantener el rumbo. y Finalmente, el banco produjo resultados incrementales y medibles en
todo el planificacin / perodo de aplicacin.
Para obtener ms informacin acerca de la planificacin de proyectos y la investigacin CAOS,
consulte la siguiente pgina web
http://www.standishgroup.com/sample_research/index.php
Sin terminar Voyages seguimiento al informe CHAOS

El logro de las respuestas a la solucin de fracaso del proyecto se encuentra a menudo en el

desarrollo de la comunicacin escrita
tales como declaraciones de problemas, planes de proyectos, y especificaciones detalladas. Sin
embargo, uno de los
problemas con cualquier comunicacin escrita es el nivel de los participantes (del lector) de
entendimiento. Como
tecnlogos, que pensar, escribir, y hablar de una manera que no est comprendido fcilmente
por muchas personas
fuera de nuestra industria. Aparte de sonar intimidante, se corre el peligro de que el lector
realmente
pensando que entienden lo que est diciendo, mientras que su significado puede ser en
realidad del todo
diferente. Parafraseando las palabras del poeta Ingls, Samuel Taylor Coleridge "Hasta que
entender la ignorancia del lector, presumir mismo ignorante de su entendimiento ". En otro
Es decir, escribir el documento carece de todos los trminos tcnicos y trminos tcnicos
seudo. esto incluye
palabras usadas por nuestra industria, pero rara vez se utiliza fuera de nuestra industria.
Palabras como paradigma, mtrica,
abstraccin, y ortogonal, no deben utilizarse en ningn documento si desea que el lector
normal
entender. Recuerde que es su trabajo para que el lector entienda el plan. No es su trabajo para
mostrar lo inteligente que eres o para demostrar que se puede utilizar grandes palabras.
El xito del proyecto Criterios Tabla
Beneficios de la Gestin de Proyectos Formal
Proporciona una imagen realista del proyecto y los recursos necesarios
Participacin de los usuarios
Apoyo a la gestin
objetivos de negocio claros
Gestor de proyectos con experiencia
hitos pequeos
Requisitos de negocio Firm
Personal competente
Una planificacin adecuada
Propiedad
Otros
Define y asigna los recursos, lo que conduce al xito de los trabajadores y la satisfaccin
laboral
Crea metas pequeas y manejables que lleva a proyectar la previsibilidad y aumentos
proyecto
xito
Identifica y administra dependencias, contingencias y riesgos que reduce el fracaso del
proyecto
Por lo tanto, proyectos fallidos terminan ms rpido reduce los costos y libera recursos
Proporciona un un proceso de comunicacin de informes