Translate - Traduce

diciembre 03, 2009

¿Por qué fracasan los proyectos de TI? (Segunda parte: Las razones de Standish Group)

Un segundo artículo titulado “Why a project fails?” de Amit Sarkar refiere a un estudio de Standish Group cuyos resultados muestran que las diez razones más frecuentes por las que fallan los proyectos de TI son:


1. Mala planeación. Los administradores tienden a pensar en la planeación como una pérdida de tiempo con el argumento erróneo de que es mejor ocupar el tiempo actuando que planeando.

2. Objetivos y metas poco claras. Esta causa también aparece en el post anterior. En este caso la causa se atribuye a que muchos proyectos de TI se elaboran en forma progresiva y se planea por oleadas.



Si al principio la toma de requerimientos es incompleta, el alcance del proyecto puede no ser claro y provocar que toda la evolución del proyecto (desde la elaboración del cronograma) este fundada en bases erróneas. Definir claramente los requerimientos del proyecto requiere de mucho tiempo y buena comunicación.

Si los objetivos del proyecto se modifican se pueden producir cambios no controlados en el alcance del proyecto o en las características del producto final, impactando al proyecto en forma negativa.


3. Manejo inadecuado de los intereses de los Stakeholders. Cuando hay interesados que no son identificados desde el principio del proyecto, es de esperarse que soliciten cambios que a su vez provoquen atrasos.

Además, cualquier cambio tardío es más costoso y difícil de integrar pudiendo incluso provocar que todo el proyecto falle.



4. Estimaciones de tiempo o recursos que son irreales. Es frecuente que los administradores cometan costosos errores cuando estiman recursos o tiempo.

Un error común se comente durante la creación de la WBS, asumiendo que la duración de una tarea es el tiempo que tarda en completarse, sin considerar que se presentarán interrupciones.

La duración de una tarea es el tiempo que tarda en completarse incluyendo las interrupciones.

Otro problema común es usar aproximaciones lineales al estimar los tiempos. Por ejemplo, integrar el doble de programadores no va a reducir la duración del proyecto a la mitad.



5. Asignación inapropiada de tareas y responsabilidades. Ocurre cuando el administrador no asigna tareas y responsabilidades en forma adecuada según las capacidades de los miembros del equipo, provocando confusión y (eventualmente) re trabajo.


6. Falta de apoyo gerencial e involucramiento de los usuarios. Los administradores de proyectos de TI enfrentan muchas dificultades cuando controlan proyectos. Si el administrador trabaja coordinando y facilitando el avance del proyecto pero sin al apoyo de la gerencia entonces no podrá tomar decisiones propias o reforzar las decisiones del equipo.


7. No comunicar en forma adecuada y no actuar como un equipo integrado. Los proyectos fallarán si la comunicación no es adecuada.


8. Falta de una administración de riesgos apropiada. Otra potencial causa de falla es la falta de habilidad de los administradores para categorizar cuantitativa y cualitativamente los riesgos e implementar medidas correctivas.


9. No contar con el equipo humano adecuado. Los rápidos cambios tecnológicos hacen difícil predecir las capacidades que se requerirán del equipo de TI, agregando dificultades al proyecto.


10. Capacidades inadecuadas del administrador.


Algunas recomendaciones que se extraen del artículo de Amit para enfrentar estas situaciones son:
  • Involucrar a administradores de proyecto con la experiencia adecuada desde la etapa de planeación.

  • Identificar a los interesados desde el principio del proyecto.

  • Tratar de obtener (y entender) todos los requerimientos antes de iniciar el trabajo.

  • Delimitar el alcance, preparar la WBS tomando en cuenta todos los requerimientos al elaborar la línea base del proyecto.


  • Establecer un control de cambios de alcance efectivo, incluyendo los cambios en la línea base, analizando el impacto de cada cambio de alcance en términos de costo, calendarios, planeación de recursos, entregables, etc.

  • El plan de administración de alcance debe incluir un proceso de control de cambios y este debe seguirse para identificar su origen y minimizar los efectos.

  • Cuando se está preparando el detalle del enunciado de alcance del proyecto hay que trabajar en un ambiente colaborativo con el equipo, consultando con los interesados siempre que sea posible.

  • Usar técnicas adecuadas para estimar la duración de cada tarea.


  • Organizar al equipo de forma que cada quien trabaje en su área de especialización


  • Identificar riesgos (pasados, presentes, potenciales), clasificarlos cuantitativa y cualitativamente e implementar acciones correctivas.

  • Asignar el rol de "dueño o responsable de los riesgos" a una o dos personas deberán identificarlos, discutirlos con el equipo y sugerir e implementar soluciones.

  • El administrador debe inspirar al equipo, compartir la visión y crear un ambiente que motive al equipo, por lo que se sugiere integrar al proyecto administradores que tengan capacidades de comunicación, planeación y organización adecuadas.



Finalmente, algunas notas personales:

La única sugerencia contra la mala planeación es… planificar. Tomando todo el tiempo que sea necesario, hacerlo en forma iterativa a lo largo de todo el proyecto, ajustando lo que se deba ajustar, etc. El plan de proyecto nos dice hacia dónde vamos, por lo que más vale que sea claro desde el principio.
Se debe escuchar con cuidado a la gerencia y al patrocinador del proyecto para conocer sus puntos de vista sobre el proyecto. Por otro lado, para crear soluciones que sirvan a los usuarios, estos deben estar involucrados en todo el proceso de planeación.

En otros post he destacado ya la importancia de la comunicación (
aquí y un poco aquí). Se debe comunicar a loa interesados en forma regular y efectiva: los hechos relevantes, los temas que puedan provocar preocupación, el progreso, los cambios y actualizaciones al plan de administración. Se deben considerar la forma en que cada uno de ellos puede afectar al proyecto.

Por último, hay que prevenir los cambios fuera de control. Si un cambio es necesario, todos deben conocer su impacto en el proyecto y estar de acuerdo con ello.
Nota final: La presente entrada se publica en forma simultánea en este blog y en greatcomments.com

No hay comentarios.:

Entradas populares