Categoría: Consultoría

Clasificación de los riesgos de un proyecto

Identificados los probables riesgos que podrían surgir en forma de problemas en la ejecución de un proyecto (ver post anterior), deberíamos clasificar los riesgos identificados. El documento de referencia nos sugiere una clasificación que facilite la comprensión en base a las siguientes categorías:


Identificados los riesgos que podrían surgir en forma de problemas en la ejecución de un proyecto (ver post anterior), a continuación, deberíamos clasificar los riesgos identificados.  El documento de referencia nos sugiere una clasificación que facilite la comprensión en base a las siguientes categorías:

  • Riesgos Técnicos
  • Riesgos Externos
  • Riesgos Organizativos
  • Riesgos de gestión del proyecto

Estas categorías podrían ser subdivididas del siguiente modo:

Adicionalmente, en cada riesgo identificado se debería señalar a que aspecto(s) del proyecto afecta (factores impulsores del proyecto):

  • Alcance
  • Calendario
  • Presupuesto
  • Recursos
  • Calidad

Referencia: ISBN 978-84-415-3225-0

Identificación de los riesgos de un proyecto

Ningún proyecto de implementación de cualquier tecnología se escapa de los contratiempos, pero la probabilidad que estos ocurran y las consecuencias que podrían causar, en muchas ocasiones son previsibles. Esta posibilidad que algo ocurra y genere incertidumbre, es decir la posibilidad que algo “inesperado” tenga lugar y que ocasione el incumplimiento de otras cosas, se denomina riesgo. Por ejemplo: Se utilizará un producto que incluye “recientes avances” de un uso práctico y real muy bajo (seguro que conlleva riesgos).


Ningún proyecto de implementación de cualquier tecnología se escapa de los contratiempos, pero la probabilidad que estos ocurran y las consecuencias que podrían causar, en muchas ocasiones son previsibles.  Esta posibilidad que algo ocurra y genere incertidumbre, es decir la posibilidad que algo “inesperado” tenga lugar y que ocasione el incumplimiento de otras cosas, se denomina riesgo.  Por ejemplo: Se utilizará un producto que incluye “recientes avances” de un uso práctico y real muy bajo (seguro que conlleva riesgos).

Para controlar estas situaciones “inesperadas” es necesario definir un plan de gestión de riesgos, el primer paso es identificar con antelación los riesgos a los que se enfrenta el proyecto.  Usando técnicas como la de “tormenta de ideas” son útiles para detectar los riesgos de un proyecto, pero además se debería contemplar las siguientes vías:

  • Revisar la estructura desglosada de tareas. Hay funciones y tareas de negocio críticas que nunca antes se han realizado que tienden a incrementar los riesgos.
  • Revisar lecciones aprendidas de proyectos similares.
  • Reuniones con expertos.
  • Diagramar las tareas del proyecto (diagrama de causas y efectos) para facilitar el análisis el uso del tiempo y los recursos.
  • Realizar un análisis DAFO (debilidades, amenazas, fortalezas y oportunidades).

Referencia: PMP Notes

La consultoría informática necesita su libro de historia

Dicen que “la historia se repite” o que “es necesario conocer el pasado para comprender el presente”, frases de uso frecuente que bien se podrían aplicar a la consultoría informática, que si se recopilara anécdotas e historias bien podrían tomar forma de más de un libro. Algunas anécdotas o historias no tan agradables como pueden ser las demandas de un cliente porque no está muy contento con el resultado de un proyecto de implementación, por causas como los que señala el artículo de referencia:


Dicen que “la historia se repite” o que “es necesario conocer el pasado para comprender el presente”, frases de uso frecuente que bien se podrían aplicar a la consultoría informática, que  si se recopilara anécdotas e historias bien podrían tomar forma de más de un libro.  Algunas anécdotas o historias no tan agradables como pueden ser las demandas de un cliente porque no está muy contento con el resultado de un proyecto de implementación, por causas como los que señala el artículo de referencia:

  • Problemas o diferencias políticas.
  • Incremento desproporcionado de los costes de los proyectos.
  • No se logran cubrir los objetivos esperados, insatisfacción de los usuarios.
  • Considerable incumplimiento de los plazos de entrega (“dijeron que podían hacerlo en siete semanas. Les dimos siete meses, y tenemos cero…”).
  • Presentación de un “demo” amañado en la preventa
  • Asignar consultores sin experiencia al proyecto.
  • Errores informáticos que generan incorrectamente pagos millonarios (Diagnóstico de auditoría: “el sistema se puso en marcha antes de superar ciertos hitos de prueba”).

Conocer un poco más sobre estos casos serían verdaderas lecciones para clientes y consultores.  Por ejemplo, interesante resulta el argumento de defensa de Oracle ante una demanda: “… Cuando los problemas surgieron durante el transcurso del proyecto, se hizo evidente que el cliente no comprendió adecuadamente la tecnología, como tampoco sabía los pasos que debía seguir para completar el proyecto…”

Referencias: aquí y aquí

Para el desarrollo de sistemas, ¿deberíamos utilizar más prototipos?

Si la metodología en cascada no es lo más recomendable para implementar sistemas de información (como comentábamos en el post anterior), ¿qué deberíamos hacer? Quizás, una alternativa podría ser una metodología basada en el uso de prototipos.


Si la metodología en cascada no es lo más recomendable para implementar sistemas de información (como comentábamos en el post anterior), ¿qué deberíamos hacer? Quizás, una alternativa podría ser una metodología basada en el uso de prototipos.

Sobre el uso de prototipos, el documento de referencia señala: “… el proceso comienza con la creación de un prototipo inicial con todos los requerimientos pero no todas las funcionalidades.  Con este prototipo los usuarios podrán probar el sistema y así observar errores o disfuncionalidades que sirven para revisar y mejorar el prototipo… un proceso iterativo que culminará con la obtención de la solución final que no requiera mejoras”

Las pruebas constantes que realizarán los usuarios, ayudarán a gestionar mejor los tiempos y a detectar mejor y más pronto los fallos.  El uso constante de prototipos durante la implantación de un sistema o aplicación informática, podría brindar los siguientes beneficios:

  • Incrementa la productividad del equipo que implanta la solución y de los usuarios clave que colaboran definiendo las pautas desde la perspectiva del negocio.
  • Aumenta la calidad del producto final.
  • Disminuye los costes de mantenimiento.
  • Mayor receptividad del usuario.

Referencia: ISBN 978-84-7356-814-2

Para el desarrollo de sistemas, ¿la metodología en cascada debería evitarse?

A muchos de nosotros nos puede resultar familiar llegar a la puesta en marcha de un nuevo sistema o aplicación informática para darnos cuenta que algo no funciona como se esperaba, ya sea porque no se comprendió lo que se solicitaba o porque al realizar el desarrollo técnico se encontró una “limitación” de la herramienta informática. Esta situación, en gran medida, es por la metodología de desarrollo que se ha optado.


A muchos de nosotros nos puede resultar familiar llegar a la puesta en marcha de un nuevo sistema o aplicación informática para darnos cuenta que algo no funciona como se esperaba, ya sea porque no se comprendió lo que se solicitaba o porque al realizar el desarrollo técnico se encontró una “limitación” de la herramienta informática. Esta situación, en gran medida, es por la metodología de desarrollo que se ha optado.

En la actualidad, muchos proyectos siguen la metodología de las fases Análisis, Diseño, Construcción, Implantación y Mantenimiento.  Una metodología, con fases rígidas, formales, siguiendo un orden riguroso, secuencial, empezando la siguiente fase cuando ha culminado la anterior. Una metodología clásica, sino nos equivocamos, de más de 30 años, tiempos en que todo tenían un ritmo más pausado, muy distintos a los tiempos actuales que exigen más rapidez y flexibilidad.

El documento de referencia señala muy bien cuando podría ser útil la metodología clásica (también denominada en cascada):

“… este tipo de metodologías sólo se usa para el desarrollo de sistemas muy grandes que requieren gran formalización  y los requerimientos son fácilmente reconocibles”

Y se señala las siguientes limitaciones de esta metodología:

  • Dificultad para eliminar errores
  • Falta de flexibilidad, el cual incrementa los costes y duración del proyecto.

Los fallos más comunes o triviales se detectan al comienzo, mientras que los más graves se detectan a la implantación, volviendo a ser necesario a analizar, diseñar y construir aquello que estaba mal implantado… ¡y comienza el caos!

Referencia: ISBN 978-84-7356-814-2