Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
Artículos
 
Por qué fracasa la Gestión de Proyectos


Por Norberto Figuerola [acerca del autor]



Existen cientos de artículos que nos hablan acerca de las top 5, 10 o 101 causas principales del porqué pueden fallar los proyectos. No es precisamente la intención del presente artículo armar un nuevo ranking. Probablemente la estadística más popular al respecto sea la del Standish Group. Desde el año 1994, el Standish Group ha sido líder en la provisión de encuestas, reportes y estadísticas sobre project management a través de sus informes Chaos Report.

Por mucho tiempo esta organización ha analizado cuan exitosos han sido los proyectos de TI, y en el caso de fallas cuales son las más importantes. En el año 1994, Standish reportó un magro 16% de proyectos exitosos, otro 53% de proyectos con problemas y un31% de proyectos cancelados. En sus reportes subsiguientes cambiaron algunas cifras, pero en definitiva se sugiere que por más esfuerzos y mejores prácticas que mejoren la gestión de proyectos, sólo hubo un pequeño éxito. El gráfico que se muestra a continuación refleja cómo fueron variando las cifras.

El siguiente gráfico es la torta del reporte 2009 sobre proyectos exitosos, con problemas o cancelados.

Estas cifras han atraído la atención de varios observadores y en muchos casos se discute que para proyectos de desarrollo de software que utilicen métodos ágiles las cifras son muy diferentes. Por otro lado existen artículos que cuestionan como se elabora dicho reporte, la veracidad y validez del mismo, y la problemática acerca de la diferencia entre un proyecto exitoso o con problemas (“successful” o “challenged”).

El costo del fracaso en un proyecto es sin duda mayor de lo que uno presupone. Los proyectos se ejecutan para hacer realidad la estrategia de la empresa. En muchos otros casos se realizan proyectos para satisfacer necesidades particulares de los clientes, también cambiantes, como desarrollo de una aplicación, una capacitación, un producto a la medida, o nueva infraestructura. La falla en los proyectos arrastra incumplimiento de objetivos estratégicos, la insatisfacción de los clientes, o ambas.

Hoy ya no nos podemos darnos estos lujos. Cualquier fracaso en proyectos importantes significa destinar recursos (de inversionistas, de préstamos o de los clientes) a realizar acciones que no logran beneficios; es decir gastamos recursos sin provecho. Además provocan el despilfarro cada vez más valioso del tiempo de empleados y colaboradores, lo que traería desánimo, desgaste y deterioro en la organización. Cuando en los proyectos para clientes no se logran los resultados, esto provoca frecuentemente pérdida de mercado, deterioro de la reputación ganada y un impacto negativo en las utilidades, afectando en el corto y largo plazo a la empresa.

La cuestión es que los debates sobre cuáles son las causas más importantes que ponen en riesgo o definitivamente cancelan proyectos, son realizados en forma periódica, a través de diversos grupos, organizaciones, artículo e incluso debates en Blogs o Linkedin.

Usted puede ver por ejemplo el artículo The Top Reasons Projects are Unsuccessful de Richard Morreale publicado en el PM World Journal de Diciembre 2012 . Si bien el artículo es claro y concreto respecto de las principales causas de proyectos no exitosos, en verdad existen muchas otras razones del porqué un proyecto puede fracasar, algunas más simples y otras más complejas, pero su número en verdad puede ser infinito. Las razones más comunes y frecuentemente enunciadas serían las siguientes:


En su Blog, Ugo Micoli destaca una encuesta hecha en PM Link Group en Linkedin acerca de las principales razones por las cuales fracasa un proyecto. Lo interesante es que no siendo esta una investigación científica sino una encuesta entre colegas, se destacan como importantes “problemas en comunicaciones” y “pobre definición del alcance”, dos causas de las más comunes que siempre aparecen en cualquier otra encuesta y que a mi criterio son las más conflictivas, pero además las que más remarcan las diferencias entre proyectos de TI o no TI.

Para los proyectos de tecnología de información se privilegia siempre una buena comunicación entre el grupo y el cliente. Lo malo es cuando se piensa que la definición del alcance para este tipo de proyectos, no es de tanta importancia, dado que es normal definir los objetivos a lo largo del camino. Las metodologías Agiles están en línea con esta forma de pensamiento, una “aproximación adaptativa”, sobre todo para los proyectos de desarrollo de software. Si bien la experiencia demuestra que este tipo de aproximación reporta beneficios en varios proyectos, no ofrecería una buena gestión o no sería una buena aproximación para proyectos de otros campos o industrias.

En ese sentido estoy de acuerdo dado que no me puedo imaginar un proyecto aeroespacial o de construcción que comiencen sin una configuración determinada. Para otro tipo de proyectos y cuando se utiliza una metodología tradicional con un PM, es más importante una buena organización, planificación y un alcance y definición detallada de los objetivos y requerimientos del proyecto (al menos los iniciales o más importantes).

En un caso la comunicación es más importante que la definición completa del alcance y en el otro es al revés. Pero haciendo una abstracción general del tipo de proyecto o industria, para cualquier proyecto en general es importante conocer muy bien hacia donde uno debe ir y los objetivos del proyecto, como así también lograr una buena y fluída comunicación en el mismo. Los proyectos son hechos por personas, por lo que la comunicación asi como las relaciones interpersonales son vitales y partiendo de esta premisa todo el mundo debería saber hacia dónde y el porqué del objetivo del proyecto antes de que el mismo comience.

Es por eso que los cursos de gestión de proyectos se centran en el liderazgo y la comunicación, dado que nadie puede gestionar un proyecto sólo con procedimientos, herramientas, SW, manuales, o certificaciones. Y si bien las habilidades relacionales son una necesidad, recordemos que la "competencia" es la capacidad de mantener nuestro rol (liderazgo), y esto es imposible sin autoridad y un claro alcance.

Probablemente lo más destacado y jugoso de la encuesta hecha en Linkedin son los comentarios ofrecidos por los participantes. Los mismos agregan detalles sobre el porqué de una causa u otra y además otros motivos conexos interesantes.
Los comentarios más destacados los exponemos a continuación:

“Yo voté por comunicación porque no incluyeron como categoría un liderazgo efectivo, el cual creo que es el principal problema”

“Pienso que un alcance poco claro y requerimientos no acordados son los que provocan al comienzo mismo del proyecto errores y supuestos equivocados de estimación. Esta es la razón por la cual el rendimiento demostrado del proyecto durante el 15% inicial es típicamente el rendimiento promedio de ejecución del mismo.”

“Yo votaría por mala gestión de los interesados, en términos de inadecuada involucración y problemas de expectativas. No obstante creo que uno de los factores claves que contribuyen a este tipo de situaciones son los problemas políticos y de lucha de poder, que normalmente están por encima del PM. Por este motivo voto por pobre comunicación”

“Yo voto por pobre comunicación básicamente porque la mayoría de los otros problemas identificados pueden resolverse con mejores y efectivas comunicaciones, ya sean dentro del team o externas a los stakeholders”

“Yo vote por pobre comunicación. Ante todo si el alcance no está claro por supuesto el proyecto fracasará. Sin embargo, se puede obtener un alcance claro via una comunicación activa entre el PM y los stakeholders. Y aún si el proyecto ya tuviese un alcance claro, puede fallar igualmente por la inexperiencia del PM en la inhabilidad para comunicarse.”

“Creo que todos son argumentos válidos, pero en mi opinión un sponsor pobre del proyecto es el principal problema. Sin un sponsor ejecutivo, las comunicaciones, el alcance y el resto de los problemas vienen a continuación.”

“El principal factor de falla es un alcance poco claro. Usted puede ser un efectivo comunicador, excelente planificador, tener certificaciones de PM, pero si no tiene aclarado los requerimientos del proyecto, será imposible que pueda gestionarlo adecuadamente. Simplemente, ha comenzado con el pie equivocado.”

“Toda mi experiencia de proyectos está en desarrollo de software. Si tuviera que votar por una de las opciones , yo tendría que decir la falta de comunicación, sobre todo porque la mayor parte del trabajo de un PM es la comunicación y muchos de los otros procesos requieren una buena comunicación para trabajar. La mayoría de los proyectos que he visto con problemas de alcance se debió a que los requisitos no estaban claros o no firmados por el cliente / patrocinador, o el mismo ha ido cambiando de opinión, o incluso proyectos en donde las diferentes partes interesadas querían cosas excluyentes mutuamente.”

“Mi elección fue la necesidad de un alcance claro. Creo una buena gestión de alcance es la respuesta. Pueden existir de hecho requisitos acordados por escrito y luego tener que modificarlos por cambios, de ahí que un buen proceso de control de cambios es también un factor importante para el éxito del proyecto.”

“Ha habido cerca de 20 años de investigación en este tema. Nunca dejamos de tratar de entender las causas y seguimos repitiendo los mismos errores fundamentales. Uno de los problemas es que existen factores de riesgo que son internos (o bajo el control del equipo del proyecto) y un número aún mayor de factores que son externos al equipo del proyecto. Uno de estos factores externos está referido a cómo se creó y apoyó el sistema y metodología de gestión del proyecto en la organización. Una queja común que he escuchado repetidas veces durante las entrevistas con los PM es que el proyecto fue "creado" para el fracaso. La ejecución de los proyectos se rige en gran medida por el sistema y cultura corporativo donde se trabaja, lo cual es responsabilidad del management .”

 



Esta página ha sido calificada como:
Califica esta página:   

Temas relacionados:
"Houston, tenemos un problema"


+





Alcanzando el éxito del proyecto con los requerimientos (Jorge Victoria)
+
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.