De eso no se habla
Por qué fracasan los proyectos de TI y cómo evitarlo
Pocas veces el naufragio de una iniciativa informática obedece al factor tecnológico. Un análisis exhaustivo demuestra falencias de liderazgo, comunicación deficiente o, sencillamente, debilidad del business case.
Por Horacio Serebrinsky
Aunque poco se habla de los fracasos, es conocido que una cantidad muy significativa
de los proyectos de informática que encaran empresas e instituciones terminan
en fracasos. La media docena de estudios de dominio público realizada en
los últimos 10 años ubica la tasa de fracasos entre 40% y 70% del
total de los proyectos iniciados, ocasionando un costo sideral y un lucro cesante
no menos importante. Si tomamos en cuenta que la inversión mundial anual
en TI estuvo en el orden de US$ 3,3 trillones para 2002, según Gartner,
resulta paradojal la persistencia de este problema. Y también el poco esfuerzo
que parece prestarse a su solución.
Según las encuestas realizadas, las causas principales de fracaso se
atribuyen a la mala comunicación entre los grupos humanos involucrados,
la pobre planificación y conducción de los proyectos, la falta
de compromiso de los directivos, el enunciado de requerimientos incompletos
y/o malentendidos, y falta de participación de los usuarios. Es llamativo
que rara vez son factores tecnológicos los que determinan el fracaso.
Cuando se exploran más detalladamente los factores que están por
detrás de las causas invocadas, resulta posible ordenarlos en cuatro
áreas claramente diferenciadas, que son: a) las que hacen al problema
en sí; b) las que hacen al liderazgo del proyecto; c) los factores humanos
y del contexto en que se encara el proyecto; d) la conducción del proyecto
propiamente dicha.
Todos estos factores están ya presentes –aunque sean entonces imperceptibles–
en el momento mismo de inicio de los trabajos; comprenderlos y abocarse a ellos
posibilitaría sin duda reducir la tasa ulterior de fracasos. Asimismo,
aun si esta tarea resultara infructuosa, sería posible abortar tempranamente
el proyecto, con un costo entonces mínimo. A título de ejemplo,
éstos son algunos de los factores que hacen al problema en sí:
la solución;
los riesgos asociados;
y especificaciones; y
(ingeniería vs. creatividad).
Con respecto al papel del líder (dueño o sponsor del proyecto),
aparecen estos factores:
proyecto.
Los factores humanos y de contexto tienen que ver con:
Finalmente, con respecto al desarrollo efectivo de la conducción del
proyecto inciden, entre otros:
inestabilidad, etc.);
diversas de provisión); y
¿Por dónde comenzar, entonces? Como en todos los casos de problemas
complejos, hay “mejores prácticas” disponibles que ayudan a
buscar una mejor perspectiva para los proyectos de informática. Existe
multitud de “mejores prácticas” adecuadas para cada una de
las facetas de desarrollo de proyectos: son aquellas prácticas que –si
bien no aseguran el éxito– sí describen y resumen el comportamiento
de aquellas empresas que son ejemplo de un desempeño exitoso.
Una primera constatación indica también que estas dificultades
en la ejecución de proyectos no se presentan de igual modo en las pequeñas
o medianas empresas que en las grandes, o en el ámbito estatal. La primera
responsabilidad corresponde siempre al “dueño” del proyecto
(que será el dueño de una Pyme, el gerente general en una mediana
empresa, el director de Finanzas o Sistemas en una gran firma, el funcionario
estatal de jerarquía, etc.), quien deberá hacerse cargo del delicado
tema en sus manos, esto es, 40% a 70% de posibles fracasos…
Ayudará sin duda el preparar una guía con las eventuales dificultades,
personalizando y completando, quizá, para su caso particular los ejemplos
que hemos listado más arriba. También –considerando que la
falta de una visión multidireccional es tema que impregna todos los asuntos
mencionados– será conveniente utilizar cuestionarios bien diseñados
que ayuden a cada sector a comprender la perspectiva de los otros sectores;
asimismo, convendrá promover entre los colaboradores el uso de técnicas
que ayuden a objetivar y documentar puntos de vista, criterios y pautas de valor
(del tipo análisis de decisión, por ejemplo).
Como ya hemos indicado, los problemas residen fundamentalmente en la interacción
de las personas; por ende, la capacitación será fundamental, atendiendo
expresamente a los problemas listados. Por supuesto, existen distintas formas
de capacitación, tutoría, coaching, training-on-the-job, etc.,
que son adecuadas para el propósito mencionado.
Será también fundamental que el project sponsor tome en cuenta
sus propios sesgos, impaciencias y eventual desinterés.
La elección de un adecuado e idóneo líder de proyecto –con
equilibrada combinación de experiencia, talento técnico, habilidad
para escuchar y manejo de recursos humanos– será clave. Oportunamente,
también él deberá pasar por un ciclo de capacitación
con respecto a los temas que lo involucran.
Finalmente, debemos subrayar que nada ayudará más al éxito
de un proyecto que la temprana toma de conciencia respecto de los riesgos y
modos de su eventual fracaso. Y tranquilizará el saber que –con
enfoques como los aquí sugeridos– muchas empresas han definitivamente
escapado a las otrora inevitables “leyes de Murphy” del desarrollo
de sistemas informáticos.
Por Horacio Serebrinsky
Aunque poco se habla de los fracasos, es conocido que una cantidad muy significativa
de los proyectos de informática que encaran empresas e instituciones terminan
en fracasos. La media docena de estudios de dominio público realizada en
los últimos 10 años ubica la tasa de fracasos entre 40% y 70% del
total de los proyectos iniciados, ocasionando un costo sideral y un lucro cesante
no menos importante. Si tomamos en cuenta que la inversión mundial anual
en TI estuvo en el orden de US$ 3,3 trillones para 2002, según Gartner,
resulta paradojal la persistencia de este problema. Y también el poco esfuerzo
que parece prestarse a su solución.
Según las encuestas realizadas, las causas principales de fracaso se
atribuyen a la mala comunicación entre los grupos humanos involucrados,
la pobre planificación y conducción de los proyectos, la falta
de compromiso de los directivos, el enunciado de requerimientos incompletos
y/o malentendidos, y falta de participación de los usuarios. Es llamativo
que rara vez son factores tecnológicos los que determinan el fracaso.
Cuando se exploran más detalladamente los factores que están por
detrás de las causas invocadas, resulta posible ordenarlos en cuatro
áreas claramente diferenciadas, que son: a) las que hacen al problema
en sí; b) las que hacen al liderazgo del proyecto; c) los factores humanos
y del contexto en que se encara el proyecto; d) la conducción del proyecto
propiamente dicha.
Todos estos factores están ya presentes –aunque sean entonces imperceptibles–
en el momento mismo de inicio de los trabajos; comprenderlos y abocarse a ellos
posibilitaría sin duda reducir la tasa ulterior de fracasos. Asimismo,
aun si esta tarea resultara infructuosa, sería posible abortar tempranamente
el proyecto, con un costo entonces mínimo. A título de ejemplo,
éstos son algunos de los factores que hacen al problema en sí:
la solución;
los riesgos asociados;
y especificaciones; y
(ingeniería vs. creatividad).
Con respecto al papel del líder (dueño o sponsor del proyecto),
aparecen estos factores:
proyecto.
Los factores humanos y de contexto tienen que ver con:
Finalmente, con respecto al desarrollo efectivo de la conducción del
proyecto inciden, entre otros:
inestabilidad, etc.);
diversas de provisión); y
¿Por dónde comenzar, entonces? Como en todos los casos de problemas
complejos, hay “mejores prácticas” disponibles que ayudan a
buscar una mejor perspectiva para los proyectos de informática. Existe
multitud de “mejores prácticas” adecuadas para cada una de
las facetas de desarrollo de proyectos: son aquellas prácticas que –si
bien no aseguran el éxito– sí describen y resumen el comportamiento
de aquellas empresas que son ejemplo de un desempeño exitoso.
Una primera constatación indica también que estas dificultades
en la ejecución de proyectos no se presentan de igual modo en las pequeñas
o medianas empresas que en las grandes, o en el ámbito estatal. La primera
responsabilidad corresponde siempre al “dueño” del proyecto
(que será el dueño de una Pyme, el gerente general en una mediana
empresa, el director de Finanzas o Sistemas en una gran firma, el funcionario
estatal de jerarquía, etc.), quien deberá hacerse cargo del delicado
tema en sus manos, esto es, 40% a 70% de posibles fracasos…
Ayudará sin duda el preparar una guía con las eventuales dificultades,
personalizando y completando, quizá, para su caso particular los ejemplos
que hemos listado más arriba. También –considerando que la
falta de una visión multidireccional es tema que impregna todos los asuntos
mencionados– será conveniente utilizar cuestionarios bien diseñados
que ayuden a cada sector a comprender la perspectiva de los otros sectores;
asimismo, convendrá promover entre los colaboradores el uso de técnicas
que ayuden a objetivar y documentar puntos de vista, criterios y pautas de valor
(del tipo análisis de decisión, por ejemplo).
Como ya hemos indicado, los problemas residen fundamentalmente en la interacción
de las personas; por ende, la capacitación será fundamental, atendiendo
expresamente a los problemas listados. Por supuesto, existen distintas formas
de capacitación, tutoría, coaching, training-on-the-job, etc.,
que son adecuadas para el propósito mencionado.
Será también fundamental que el project sponsor tome en cuenta
sus propios sesgos, impaciencias y eventual desinterés.
La elección de un adecuado e idóneo líder de proyecto –con
equilibrada combinación de experiencia, talento técnico, habilidad
para escuchar y manejo de recursos humanos– será clave. Oportunamente,
también él deberá pasar por un ciclo de capacitación
con respecto a los temas que lo involucran.
Finalmente, debemos subrayar que nada ayudará más al éxito
de un proyecto que la temprana toma de conciencia respecto de los riesgos y
modos de su eventual fracaso. Y tranquilizará el saber que –con
enfoques como los aquí sugeridos– muchas empresas han definitivamente
escapado a las otrora inevitables “leyes de Murphy” del desarrollo
de sistemas informáticos.
