¿Necesitas ayuda?


Responsable SEMANTIC SYSTEMS, S.L. (NIF B-95234183)
Finalidades Atención al usuario
Destinatarios Prestadores de servicios auxiliares externos con acceso a datos, órganos jurisdiccionales, Administración Pública.
Derechos Revocación, acceso, rectificación, oposición, cancelación, limitación, portabilidad y oposición a decisiones automatizadas rgpd@semantic-systems.com
Info adicional Política de privacidad

ENVIAR

BORRAR


Gestión de riesgos en proyectos de implantación de software

Cualquier proyecto, tenga la característica que tenga, presenta problemas. Cuando hablamos de proyectos de implantación de software es casi imposible no pensar en ellos y en cómo ejecutar una correcta gestión de riesgos.

 

La cantidad de personas involucradas, el tamaño de los proyectos, la involucración de software e infraestructura y la siempre presente posibilidad de la dilatación de los plazos, nos hacen pensar en cómo se pueden gestionar para minimizarlos.

 

Cualquier cosa que lo retrase, impida que avance al ritmo esperado o que provoque que se salga del presupuesto estimado.

 

En definitiva, cualquier aspecto del proceso que suponga una desviación del plan previsto y que permita que el proceso fracase.

 

Análisis de riesgos

Además, si los riesgos están por todas partes y no se pueden evitar, ¿para qué preocuparse?

 

Estos son algunos de los casos más sonados de fracasos en la implementación de software.

 

En 1982, la empresa Allstate quiso automatizar las actividades administrativas. Las estimaciones del proyecto eran de 5 años y 8 millones de dólares.

 

La realidad fue bien diferente: 6 años y 15 millones de dólares más tarde, tuvieron que redefinir el plan con una nueva fecha de entrega y un presupuesto que alcanzó los 100 millones, casi 7 veces más que el presupuesto original.

 

Y no es un caso aislado. En 1988, la Westpac Banking Corporation decidió volver a definir sus sistemas de información. Los 3 años estimados se convirtieron en 6, y los 85 millones en 150, por no hablar de los empleos perdidos y el impacto económico que supuso para la compañía.

 

Los riesgos son una realidad y la gestión de riesgos una forma de acotarlos y evitar que terminen en desastre.

 

Riesgos más comunes en los proyectos

¿Son el presupuesto y el plazo de entrega los dos únicos riesgos a los que se debe enfrentar una empresa que desea una implantación de software?

 

Ni mucho menos, más bien son la consecuencia de los muchos riesgos que pueden presentarse. La variedad es amplia, aunque podemos utilizar la siguiente clasificación en el caso concreto de proyectos de implantación:

1/ Riesgos derivados del cliente

Partimos de la base de que este tipo de proyectos se encaran con la contratación de un partner tecnológico externo.

 

Como es lógico, el cliente puede ser un riesgo potencial importante, independientemente de que sea el principal interesado en que el proyecto llegue a buen puerto.

 

Los riesgos derivados del cliente son múltiples. El desconocimiento de lo que se ha comprado, las expectativas poco realistas o la falta de colaboración de los empleados pueden llevar al fracaso incluso con el partner más entusiasta. Una actitud positiva y talentosa de los empleados facilita el éxito del proyecto.

 

Incluso cuando la directiva está fuertemente involucrada, si la cultura empresarial es reticente al cambio, el proyecto puede fracasar.

2/ Riesgos derivados de la empresa suministradora de servicios

No siempre se acierta con la elección del proveedor de servicios.

 

Si el personal no tiene los conocimientos y experiencia suficientes, subcontrata partes del proyecto a terceros que no responden, y toda la gama de posibilidades que abarca la rotación de los consultores hace acto de presencia (nuevo personal, abandono del equipo, incorporaciones que no dominan la tecnología, falta de formación), el fracaso está asegurado.

3/ Riesgos derivados de la planificación

Por muy involucrados que estén ambos equipos (cliente y proveedor), si la planificación no es metódica y constante, el riesgo se vuelve muy real.

 

Uno de los ejemplos más típicos derivados de la falta de planificación es no establecer claramente quién debe realizar cada una de las fases del plan, algo que sucede con frecuencia en los casos de migración de un sistema a uno más actual. La falta de disponibilidad del equipo de cliente se convierte en un exceso de carga de trabajo en el equipo del proveedor y por tanto no es viable cumplir los hitos / fases planificados.

 

Si hay que realizar nuevos desarrollos en un paquete estándar, alguien debe asumir esa tarea. Incluso tener que pasar datos de unas tablas a otras, algo en teoría muy simple, debe hacerlo alguien.

 

Una planificación muy optimista o impuesta por el cliente, o no evaluar la carga de trabajo que supone el proyecto, son algunos de los riesgos más comunes.

4/ Riesgos derivados del producto

Por último, existe una gran variedad de riesgos derivados del propio producto a implantar, porque hasta que no se comienza el trabajo con frecuencia no es posible hacerse una idea exacta ni de la complejidad ni de si las soluciones aportadas serán factibles.

 

Por último, señalar que todos estos riesgos pueden coexistir en el mismo proyecto y al mismo tiempo, lo que complica todavía más el panorama.

 

Es evidente que se necesita analizar y realizar un plan de gestión de riesgos en la implantación de software.

 


 

También le puede interesar leer el siguiente ebook tecnológico: Adelántate a los problemas con la monitorización de los sistemas informáticos

 

Qué es el análisis de riesgos

Cuando se toma conciencia de que lo que puede salir mal, se puede planificar en consecuencia y realizar una previsión que permita amortiguar el golpe.

 

Las sesiones de brainstorming entre cliente y proveedor, son una forma excelente de tomar contacto con los posibles riesgos que pueden aparecer.

 

Se aplica, como en otras disciplinas, el principio de pareto: el 20% de los problemas consumen el 80% del presupuesto.

 

Es imprescindible un seguimiento exhaustivo y constante del proyecto para evitar que los riesgos se conviertan en dificultades complejos de gestionar.

 

Estimación de las pérdidas

Existen dos formas de hacer un análisis de riesgos, cada una de ellas con sus pros y sus contras.

 

La primera es la de la estimación de las pérdidas, desarrollada por Patrick McConnell y que engloba a su vez varias fases.

 

La primera de ellas se llama Estimación de la Probabilidad de Pérdida y estima la probabilidad del riesgo al que hace referencia (por ejemplo, estimación demasiado realista, 48%).

 

La segunda es la Estimación de la Magnitud de la Pérdida y consiste en estimar el tiempo de retraso del proyecto si se presentara el riesgo o problemas derivados.

 

Asignación de coeficientes en la planificación

Este segundo método de análisis de riesgos ha sido enunciado por Jesús M. Marroquín.

 

Se trata de un método más simple, donde no es necesario descender al detalle de cada riesgo. En su lugar, establece estimaciones generales.

 

Se compone de tres fases. En la primera, se categorizan los riesgos, según el desglose que hemos enunciado en este artículo. En la segunda, se seleccionan las etapas más generales del proyecto de implantación y por último, se estiman las cargas para cada actividad.

 

Independientemente del método empleado, la idea final es tener una estimación de la probabilidad de desviación del proyecto para poder actuar en consecuencia.

 

Gestión de riesgos en proyectos

No queremos cerrar este artículo sin contemplar cómo se gestionan los riesgos encontrados y cómo se evita que afecten al proyecto en general o a cada una de sus fases.

 

No hay que olvidar que existe un componente subjetivo que afecta tanto al análisis como al control y que se hereda hasta llegar a la gestión de los riesgos.

 

Este elemento subjetivo hace difícil, pero no imposible, una serie de consideraciones generales sobre los métodos de tratamiento de riesgos:

  • Evitar el riesgo.
  • Trasladar el riesgo de una parte del sistema a otro.
  • Conseguir información acerca del riesgo.
  • Eliminar el origen del riesgo.
  • Asumirlo.
  • Comunicarlo.
  • Controlarlo.
  • Recordarlo.

 

Aunque no siempre es posible evitar los riesgos, porque no se pueden controlar todos y cada uno de los aspectos de un proyecto, especialmente cuando tiene gran envergadura, cuanto más se conozca sobre ellos, menos probabilidades hay de que su aparición tenga como consecuencia un retraso o un efecto económico indeseable.

 

¿Has realizado alguna gestión de riesgos en proyectos de implantación de software? ¿Qué lección has aprendido? Te esperamos en los comentarios