Analisis De Riesgos

1

Implementación y Mejora del Método de Gestión Riesgos del SEI en un proyecto universitario de desarrollo de software J. Esteves, Instituto de Empresa, J.A. Pastor, Universitat Internacional de Catalunya, N. Rodríguez, Universitat Politècnica de Catalunya, & R. Roy, Universitat Politècnica de Catalunya

Abstract-- Aunque los diversos enfoques de gestión del riesgo aparecieron hace más de una década, sigue siendo evidente la poca utilización de sus técnicas en los proyectos de desarrollo de software actuales. Uno de los métodos más conocido es el método del SEI, conocido como Continuous Risk Management (SEICRM). En este artículo mostraremos la aplicación de este método en un proyecto universitario de desarrollo de software de grandes dimensiones. Además, nuestro trabajo muestra que conviene completar el SEI-CRM con un conjunto apropiado de riesgos organizacionales. Con nuestra investigación aplicada, esperamos contribuir al conocimiento de la gestión de los riesgos en proyectos de desarrollo del software, mediante la ampliación del método SEI-CRM con aquellos factores organizacionales de riesgo que han resultado relevantes en nuestro proyecto y en nuestra investigación previa. Index Terms-- Métodos de gestión de riesgos, Continuous Risk Management (CRM), riesgos organizacionales, gestión de proyectos informáticos.

L

I. INTRODUCCIÓN

a investigación en la gestión de riesgos en el ámbito del software procura formalizar conocimiento orientado a la minimización o evitación de riesgos en proyectos de desarrollo de software, mediante la generación de principios y buenas prácticas de aplicación realista [10]. Hasta el momento se han propuesto y utilizado diferentes enfoques de gestión del riesgo desde que Boehm [2] atrajo a la comunidad de ingeniería del software hacia la gestión del riesgo. Sin embargo, es evidente que pocas organizaciones utilizan todavía de una forma explícita y sistemática métodos específicos para gestionar los riesgos en sus proyectos software [13,16]. Así, por ejemplo, durante el año 2001, KLCI realizó y publicó un estudio con 268 organizaciones de todo el mundo y el resultado fue que: el 3% no utilizaba ningún marco de gestión del riesgo, el 18% utilizaba algún marco caótico para identificar sus riesgos, el 37% de los participantes habían utilizado algún marco informal, el 28% utilizaban procedimientos repetitivos y sólo un 14% utilizaba un enfoque formal para identificar riesgos [13]. Según este estudio, las razones más comunes para utilizar un marco informal son: falta de procedimientos, necesidades del proyecto no adecuadas, organización inmadura y compromiso del equipo. Según Hoffman [5], aunque algunas organizaciones usen procesos formales de gestión del riesgo

para otras partes de su negocio, demuestran una gestión de riesgos pobre en el ámbito general de los sistemas de información. Kontio y Basili [16] creen que hay tres razones principales para la baja tasa de divulgación de tecnologías de gestión del riesgo: falta de conocimiento sobre posibles métodos y herramientas, limitaciones prácticas y teóricas de los marcos de gestión de riesgos que entorpecen la facilidad de uso de estos métodos, y tercero, todavía hay pocos informes con evaluaciones sistemáticas o científicas que proporcionen feedback empírico sobre su viabilidad y beneficios. El riesgo en un proyecto de desarrollo de software incluye componentes técnicos y de conocimiento del riesgo [6]. Diferentes estudios han mostrado que la mayoría de los proyectos fallan sobre todo en gestión, no tecnológicamente. Además, son los temas de naturaleza organizacional los factores de riesgos del proyecto más dominantes a la vez que son los que se tratan satisfactoriamente en menos de la tercera parte de los proyectos de desarrollo [3]. Schmidt et al. [11] han observado que jefes de proyecto exitosos puntúan bajo aquellos factores sobre los que no tienen control o influencia como: conflictos entre departamentos usuarios, cambio del propietario o responsable ejecutivo del proyecto, volatilidad del personal, número de unidades de la organización implicadas y proyectos que involucran a múltiples proveedores. Otro aspecto que influye en estos temas es la falta de reconocimiento sobre la importancia de los aspectos organizacionales que existe en gran parte de la comunidad profesional y académica vinculada a las tecnologías de la información y la comunicación, como muestran Doherty y King [3]. La finalidad de este artículo es, en primer lugar, describir la utilización del método conocido como SEI-CRM (Software Engineering Institute - Continuous Risk Management) en un proyecto universitario de desarrollo de software de grandes dimensiones llevado a cabo en la Universitat Politècnica de Catalunya (UPC). En segundo lugar, queremos explicar la extensión realizada para dicho proyecto de la taxonomía de riesgos del SEI-CRM con riesgos organizacionales basados en un modelo anterior de factores críticos de éxito (FCE) para implementaciones de sistemas ERP (Enterprise Resource Planning) propuesto por Esteves y Pastor [15]. De esta manera, se puede decir que la estrategia de identificación y gestión de riesgos propuesta en este artículo

2

resulta innovadora si la comparamos con otros trabajos relacionados con anterioridad. De hecho, son dos los motivos principales por los que se adoptó el modelo unificado de FCE mencionado. Por una parte, la misma UPC había implantado un sistema ERP dos años antes de empezar el proyecto de desarrollo en cuestión. En su momento se consideró que la información relacionada con la predicción u ocurrencia de riesgos en proyectos anteriores de la UPC de nivel similar de complejidad (como por ejemplo sus causas, consecuencias, su tratamiento o el éxito de los planes de mitigación y contingencia) podía ayudar a los gestores a identificar y gestionar los riesgos del proyecto en curso. Además el aprendizaje de los resultados relacionados con la gestión del riesgo de proyectos anteriores puede contribuir al enriquecimiento del enfoque de planificación de los riesgos del nuevo proyecto. En segundo lugar, el modelo unificado de FCE incluye un conjunto conciso y bien definido de los factores críticos de éxito de naturaleza organizacional, que se pueden reinterpretar fácilmente como “factores críticos del riesgo”. Este artículo está estructurado de la siguiente manera. Primero se presenta una breve visión de los antecedentes del estudio. A continuación, se presentan las diferentes fases de la gestión del riesgo en el proyecto abordado y se comenta su implementación. Después explicamos algunos de los riesgos organizacionales utilizados en la extensión del SEI-CRM. Finalmente, presentamos las conclusiones y el trabajo futuro. II.

ANTECEDENTES DEL PROYECTO PRISMA

La Universitat Politècnica de Catalunya (UPC) es una institución pública de enseñanza superior cuyos objetivos prioritarios son el estudio, la docencia, la investigación y la transferencia de tecnología de calidad. Fue fundada en los años 70 y actualmente tiene más de 30.000 estudiantes, estando formada por 15 escuelas técnicas superiores y facultades, 7 centros adscritos y 3 institutos universitarios de investigación. Uno de sus principales objetivos es transferir los resultados de sus investigaciones a las empresas. En este sentido, es la primera universidad española en volumen de recursos obtenidos por transferencia de tecnología. En el 2001 la UPC decidió unificar la gestión de los estudios de toda la universidad en un único sistema. Después de evaluar las diferentes alternativas existentes en el mercado, tomó la decisión de desarrollar su propio sistema de información informático para administrar los estudios académicos, y seleccionó una unidad informática interna para llevarlo a cabo. El proyecto se llamó PRISMA y sus tres principales metas fueron: construir una única base de datos y un único sistema de información, tener acceso multicanal al SI (centro, Internet, móvil) y facilitar la adaptación a la convergencia europea de los estudios universitarios impulsada por la Declaración de Bolonia. III. FASES DE LA GESTIÓN DEL RIESGO EN PRISMA Esta sección trata de proporcionar una visión general del proceso de gestión de riesgos diseñado y utilizado en el

proyecto PRISMA, incluyendo la selección de un marco de gestión de riesgos, su descripción, el equipo encargado de llevar a cabo el proceso y la descripción del plan de gestión del riesgo que lo detallaba. A. Selección de un Método de Gestión de Riesgos Esta fase consistió en la identificación, evaluación y selección de los diferentes métodos existentes para organizar la implementación de las funciones básicas que deben llevarse a cabo para una gestión efectiva de los riesgos “antes de que estos lleguen a ser amenazas para el éxito”. La Tabla 1 muestra los métodos que fueron evaluados, ampliamente conocidos y fácilmente accesibles por sus nombres o por las organizaciones que los avalan: Euromethod, Safe, SEI-CRM, RiskIt y los métodos para la gestión de riesgos del IEEE y del PMI (Project Management Institute). Es importante tener presente que cada método establece categorías para las funciones del riesgo en diferentes fases. Para cada método analizamos qué funciones de la Tabla 1 trata, y cómo propone abordarlas. TABLA I LISTA DE LOS MÉTODOS DE GESTIÓN DEL RIESGO EVALUADOS EN EL PROYECTO PRISMA. Euromethod Safe SEI IEEE Riskit PMI Plan de Gestión Identificación Estimación Evaluación Planificación Tratamiento Seguimiento y control Comunicación

El equipo de gestión del riesgo y el jefe del proyecto de PRISMA decidieron adoptar el método SEI-CRM por dos motivos. Primero, el SEI-CRM es uno de los métodos de gestión del riesgo más completo, con más documentación detallada y cuya aplicación está más extendida en la industria. Segundo, en paralelo, el proyecto PRISMA trabajaba para conseguir el nivel 2 de madurez del SW-CMM nivel 2 del SEI, lo que apoyaba la opción de incorporar el SEI-CRM como parte de sus actividades. B. El método Continuous Risk Management del SEI El método Continuous Risk Management (SEI-CRM), desarrollado por el Software Engineering Institute (SEI), es un método en el ámbito de la ingeniería del software cuyos conceptos, procesos y herramientas permiten gestionar de manera continua los riesgos de un proyecto, proporcionando un entorno disciplinado para la toma preactiva de decisiones a lo largo de todas las fases del proyecto: análisis de los problemas en potencia (riesgos), determinación de los riesgos importantes para elaborar estrategias y planes para gestionarlos. Estos riesgos son controlados hasta que se resuelven o se convierten en problemas menores, y son tratados como tales. En la Tabla 1 podemos ver las funciones típicas de gestión del riesgo que tiene el SEI-CRM pero además este método también incluye el concepto de gestionar

3

estas actividades como un ciclo básico, es decir, identificar, analizar, planificar, seguir, controlar y comunicar los riesgos a lo largo de todo el ciclo de vida del proyecto. C. Definición del Plan de Gestión de Riesgos de PRISMA Nuestra primera tarea fue crear el plan de gestión del riesgo del proyecto PRISMA. Aunque el SEI-CRM no incluye específicamente una fase o actividad para el desarrollo de este plan, nosotros decidimos extender el SEI-CRM con la fase de definición del plan de gestión del riesgo del modelo del PMI, cuyo objetivo es el de garantizar que los riesgos del proyecto sean identificados, analizados, documentados, mitigados y controlados correctamente durante todo el ciclo de vida del proyecto. Este documento incluye los procesos, métodos, responsabilidades y recursos utilizado para administrar los riesgos de PRISMA y sigue las recomendaciones del SEI SWCMM y del PMI. D. Definición del equipo de Gestión de Riesgos La Figura 1 muestra las responsabilidades para gestionar los riesgos de todo el personal del proyecto, incluyendo el jefe del proyecto, los responsables de las diferentes áreas, los miembros del equipo PRISMA y el equipo completo de gestión del riesgo. Jefe del proyecto

Responsables de área

Todo el equipo PRISMA

Controlar

Transferir riesgo

• Revisar • Repriorizar • Integración de los equipos

Riesgos importantes

Asignar responsabilidad

Analizar • Revisar • Priorizar • Evaluar • Clasificar

Plan • •

aprobar planes Recomendar planes

Riesgos

Equipo de Ayuda a la Gestión del Riesgo

Indicadores

Seguimiento

Identificar Estado

Área de Calidad

Fig. 1. Diferentes roles en el proceso de gestión del riesgo.

A continuación se enumeran los roles principales y las responsabilidades para cada rol: - Todo el equipo PRISMA: identificar nuevos riesgos, estimar su probabilidad e impacto, clasificar, recomendar acciones, seguimiento de los riesgos y de sus planes de acción, y ayudar a priorizar los riesgos. - Responsables de área: integrar información de todos los riesgos de los miembros de su área, asegurar precisión de las estimaciones de la probabilidad, del impacto y la clasificación., reconsiderar la prioridad de todos los riesgos para determinar los riesgos más importantes, revisar recomendaciones para las acciones de mitigación, asignar y cambiar responsabilidades de los riesgos y sus planes de mitigación, implementar decisiones de control sobre los riesgos, construir planes de acción, recoger e informar sobre medidas del riesgo, e informar periódicamente al jefe del proyecto de la situación de los riesgos.

-

-

-

Jefe del proyecto: autorizar recursos para la mitigación, integrar información de todos los responsables de área sobre los riesgos, revisar la prioridad de todos los riesgos para determinar cuáles son los riesgos importantes, tomar decisiones de control sobre estos riesgos, asignar y cambiar responsabilidades de los riesgos y sus planes de mitigación dentro del proyecto, revisando las métricas periódicamente y conjuntamente con el área de calidad para evaluar la efectividad de la gestión del riesgo. Equipo interno de gestión del riesgo (Área de Calidad): coordinar actividades para identificar y analizar riesgos, mantener la lista de los riesgos del proyecto, notificar nuevos riesgos e informar periódicamente sobre el estado de los riesgos al jefe del proyecto. Estimar periódicamente las métricas de los riesgos para evaluar conjuntamente con el jefe del proyecto. Equipo de soporte a la gestión del riesgo (asesores externos): detectar elementos de riesgo y estimar su impacto potencial negativo, revisar y evaluar procesos críticos y áreas dentro del proyecto, revisar e importar resultados relevantes de proyectos internos similares o externos, construir políticas y planes de contingencia, y evaluar y ayudar al jefe del proyecto en actividades de criticidad elevada. IV. IMPLEMENTACIÓN DEL SEI-CRM EN PRISMA

A. Fase de Identificación de Riesgos La fase de identificación de riesgos consiste en descubrir factores de riesgo antes de que estos lleguen a ser problemas y deriven en daños o pérdidas. En la figura 2 se puede ver el proceso de identificación de riesgos que se siguió en PRISMA, que se dividió en dos fases: identificación de la lista inicial de los riesgos del proyecto y proceso de identificación y evaluación continua de los riesgos. 1) Identificación de la lista inicial de riesgos del proyecto Para esta actividad, el equipo de gestión del riesgo construyó un cuestionario de identificación de riesgos basado en la taxonomía de riesgos del SEI. Esta taxonomía proporciona un marco para identificar riesgos técnicos y del proceso utilizado para el desarrollo del software [12] y consiste en 194 preguntas clasificadas en tres grandes clases: ingeniería del producto, entorno del desarrollo y restricciones del programa.

4 Cuestionario SEI

Contexto proyecto PRISMA Otras listas de riesgos

1.- Identificar la lista de Riesgos de PRISMA

Lista provisional de los riesgos de PRISMA

Comparar lista de riesgos de PRISMA con otras listas

2.- Proceso continuo de identificación de riesgos

Lista inicial de riesgos de PRISMA

Fig. 2. Proceso de identificación de riesgos utilizado en PRISMA.

Algunos autores (p.e. [9]) han mencionado que la taxonomía del SEI parece diseñada para facilitar la identificación de los riesgos en proyectos grandes, formales y muy técnicos de organizaciones grandes. La realidad de la taxonomía es que ésta refleja sus orígenes, es decir, que los tipos de riesgos encontrados son aquellos riesgos típicos que existen en organizaciones grandes, generalmente militares, con proyectos de desarrollo de software también grandes. Es por ello que extendimos esta taxonomía definiendo otra categoría de factores de riesgo, los factores organizacionales de riesgo, importados y adaptados de los factores organizacionales y estratégicos identificados por Esteves y Pastor [15] para la implementación de sistemas integrados ERP (ver Tabla 2). TABLA 2 FACTORES ORGANIZACIONALES, ESTRATÉGICOS Y TÁCTICOS (ESTEVES Y PASTOR [15]). Estratégico Táctico Apoyo continuado de la alta dirección Equipo y consultores dedicados Comunicación interna y externa Gestión efectiva del cambio Plan formalizado del proyecto organizacional Buena gestión del ámbito del proyecto Programa de formación adecuado Composición adecuada del equipo del Previsión de problemas inesperados Uso adecuado de consultores proyecto Rediseño adecuado de los procesos de Responsables debidamente autorizados negocio Papel adecuado del líder del proyecto Papel adecuado del jefe del proyecto Implicación y participación de los usuarios Confianza entre actores

A modo de resumen, según el modelo de Esteves y Pastor [15], que unifica otros modelos anteriores de carácter parcial, la naturaleza de los problemas en una implementación de un sistema ERP incluye las siguientes perspectivas: estratégica, táctica, organizacional y tecnológica. La perspectiva organizacional está relacionada con aspectos como la estructura y cultura organizacional y los procesos de negocio. La perspectiva estratégica trata sobre con las competencias clave para lograr los objetivos de la organización a largo plazo, mientras que la perspectiva táctica afecta a las actividades de negocio con objetivos a corto plazo. Para el proyecto PRISMA no se consideraron los factores vinculados con la perspectiva tecnológica, ya que ésta se centra en los aspectos relacionados propiamente con la tecnología subyacente a los productos ERP. Se elaboró un cuestionario que sirvió de base al equipo de

gestión del riesgo para realizar entrevistas a los responsables de área con la finalidad de obtener riesgos. También se estudió la información disponible acerca de riesgos de otros proyectos similares dentro de la misma organización, para analizar y determinar la lista provisional de riesgos del proyecto. Finalmente, como resultado de la comparación de la lista provisional con otras listas de riesgos publicadas, se elaboró la lista inicial de riesgos del proyecto. 2) Proceso Continuado de Gestión del Riesgo Todos los miembros del proyecto PRISMA han sido responsables de identificar nuevos riesgos durante todo el ciclo de vida del proyecto. Véase la sección de la fase de control de riesgos más abajo para información más detallada sobre el proceso continuo de la gestión de riesgos. B. Fase de Análisis de Riesgos El análisis de riesgos consiste en convertir los atributos del riesgo en información que sirva como base para tomar decisiones. Esto implica establecer valores para el impacto (la perdida o efecto negativo en un proyecto en caso de que ocurra el riesgo); y la probabilidad (la probabilidad de que el riesgo ocurra). El análisis de riesgos en PRISMA se organizó en tres pasos: evaluar los atributos del riesgo: probabilidad e impacto usando una escala de cinco valores, asegurar la exactitud de los atributos del riesgo y clasificar y priorizar los riesgos. C. Fase de Planificación del Riesgo Tomando como entrada la lista priorizada de riesgos, la fase de planificación del riesgo consistió en decidir qué hacer y cuándo, para cada uno de los riesgos de la lista. La estrategia del riesgo para un riesgo específico puede ser diferente según el conocimiento actual de los riesgos del proyecto: transferir, mitigar, evitar o aceptar el riesgo. En esta fase solo consideramos planificación de recursos y actividades de mitigación para los riesgos con importancia alta o media y el proceso se organizó según los siguientes pasos: asignar responsabilidad del riesgo a cualquier actor del proyecto; crear de un plan de acción para cada riesgo; si la acción es la mitigación, entonces también crear el plan de mitigación correspondiente; y revisar todos los planes de acción y mitigación. D. Fase de Seguimiento del Riesgo El seguimiento es el proceso de recogida de datos, de su análisis y posterior divulgación para los riesgos que están en observación o mitigación. Para ello, se han elaborado documentos, informes o se han realizado presentaciones a las personas responsables de tomar decisiones con la información de los indicadores clave. Esta fase consistió en los siguientes pasos: control de los indicadores del riesgo y los planes de mitigación, identificación de nuevos riesgos, y asignación de prioridades a lista de riesgos, incluyendo los nuevos. E. Fase de Control del Riesgo La finalidad de esta fase es corregir las desviaciones de los planes de mitigación. Además de controlar los riesgos de la

5

lista actual del proyecto, el equipo debe estar atengo a nuevos riesgos que puedan aparecer en su entorno a medida que el proyecto avanza. Este proceso estaba compuesto de los siguientes pasos: identificación de los nuevos riesgos del proyecto (ejecutar propuestas de riesgos y confirmar riesgos), asignación de la responsabilidad del nuevo riesgo, y revisión periódica de los riesgos del proyecto. F. Fase de Comunicación La finalidad de la fase de comunicación es proporcionar información y feedback sobre las actividades de gestión del riesgo del proyecto, los riesgos actuales y los riesgos que puedan surgir. La comunicación es esencial para el éxito de todas las otras funciones y es crítica para gestionar los riesgos. Para una gestión eficaz de los riesgos, una organización debe tener una comunicación abierta y ejercida de una manera continua. Ésta puede ser tanto formal como informal. Para esta fase, nosotros llevamos a cabo las siguientes actividades: presentaciones y talleres de gestión del riesgo a los miembros del equipo PRISMA, publicación de la lista de riesgos, informes periódicos del estado de los riesgos del proyecto a los directores técnicos, al jefe del proyecto y a la comisión de seguimiento. Además todos los documentos se han mantenido accesibles online en una herramienta informática colaborativa implementada por el mismo equipo en Lotus Notes. V. RIESGOS ORGANIZACIONALES DEL PROYECTO PRISMA La Tabla 3 muestra los factores de riesgos identificados en el proyecto PRISMA que fueron inicialmente trasladados y adaptados desde el modelo de Esteves y Pastor [15]. En la mayoría de casos, los nombres de los factores de riesgo no se corresponden exactamente con los factores de éxito originales de Esteves y Pastor [5], debido a que tales factores fueron definidos como categorías de un nivel más alto que nuestros factores de riesgo y a que los factores de éxito utilizados han sido reinterpretados en su nombre y descripción como factores de riesgo. TABLA 3 ALGUNOS FACTORES DE RIESGO IDENTIFICADOS EN EL PROYECTO PRISMA SE Esteves y Pastor Factores de riesgo identificados Nivel [5]

I

Falta de un plan de gestión del cambio organizacional Falta de implicación y participación de los usuarios Falta de comunicación interna y externa Inadecuada planificación y evaluación del programa de formación

Alto

Estratégico

Medio Medio Medio

Estratégico X

Táctico Táctico

A continuación vamos a tratar brevemente cada uno de estos riesgos organizacionales y las acciones que se han llevado a cabo para abordar la gestión de cada uno de ellos. A. Falta de un plan de gestión del cambio organizacional Este riesgo organizacional fue clasificado como un riesgo de importancia alta. Mucha de la literatura sobre gestión del riesgo considera que los riesgos asociados con el cambio cultural son los más difícil de gestionar [1]. Normalmente, la cultura es una de las fuerzas más poderosas de oposición al

cambio y la implementación del cambio cultural es un proceso a largo plazo que necesita ser gestionado con cuidado. Para este riesgo, se desarrollaron las siguientes acciones de mitigación: desarrollar un Plan de Gestión del Cambio; comunicación efectiva entre el equipo de dirección del proyecto (jefe ejecutivo del proyecto, director institucional del proyecto o sponsor, y comisión de seguimiento) y los actores clave que pueden cambiar o desempeñar un rol clave en el proceso de cambio. B. Falta de participación e implicación de los usuarios La participación del usuario se refiere a la conducta y actividades que los usuarios realizan durante el proceso de implementación del sistema, mientras que la implicación del usuario se refiere al estado psicológico de la persona y se define como la importancia y la relevancia personal de un sistema hacia un usuario [4]. La participación e implicación del usuario proporcionan una mejor obtención de los requerimientos del usuario, logrando mejor calidad del sistema, del uso y de la aceptación. Con respecto a la mitigación de este riesgo, desarrollamos una serie de actividades para mejorar la implicación del usuario especialmente en tareas críticas como la formación y la implementación del sistema. C. Falta de comunicación interna y externa Según Esteves y Pastor [15], la comunicación debe ser de dos tipos: “hacia dentro” en el seno del equipo del proyecto y “hacia fuera” con el resto de la organización que acoge al proyecto. Esto significa que no solo se debe compartir información sobre las metas y resultados en cada etapa de la implementación dentro del equipo del proyecto sino también con el resto de la organización. Para ello es necesario crear un plan de comunicación que organice todas las tareas que se van a llevar a cabo. Además, el esfuerzo de la comunicación se debe hacer de manera regular durante toda la fase de implementación. Para este riesgo, se propuso la creación de un plan de comunicación, plan que determinaba las necesidades de información y comunicación de los actores: quién necesitaba qué información, cuándo la necesitaban, cómo se le proporcionaría y quién lo haría. Por ejemplo, para comunicación interna propusimos realizar reuniones más frecuentes y regulares de todo el equipo del proyecto y otras entre los directores de departamentos. D. Inadecuada planificación y evaluación del programa de formación La finalidad de la formación es desarrollar las habilidades y conocimientos de los individuos de manera que éstos puedan realizar sus roles de forma eficiente y efectiva. Consideramos no solo la evaluación y monitorización de la formación del equipo del proyecto sino también la de los usuarios del sistema. Con respecto a los usuarios, uno de los beneficios más importantes de evaluar la formación es que sirve para adaptar a los usuarios al sistema nuevo, ayudando así al proceso del cambio organizacional.

6

Para este riesgo, se definieron las siguientes acciones de mitigación: crear un plan de formación que documentara los objetivos del programa de formación, las necesidades de formación, la formación que se impartiría y procedimientos para llevar a cabo las actividades de formación; proporcionar un conjunto de métricas para controlar la formación en PRISMA, utilizando un marco para controlar y evaluar formación en proyectos de implementación de ERP; crear un cuestionario para evaluar la formación; recoger los datos de las encuestas que los usuarios o los miembros del equipo del proyecto han respondido cada vez que han realizado un curso; analizar estos datos para determinar el estado del plan de formación y proponer mejoras de formación. VI. CONCLUSIONES Y TRABAJO FUTURO En este estudio han surgido dos resultados que consideramos relevantes. El primero, la viabilidad de la aplicación adaptada del método SEI-CRM a un caso real. En términos generales, las personas que participaron en el proceso de gestión del riesgo están de acuerdo en que el SEICRM representa un enfoque válido y positivo para abordar de forma sistemática la gestión de riesgos en proyectos de desarrollo de software, aunque insuficiente en su descripción oficial para proyectos complejos de desarrollo de software de gestión, como ha sido el caso del proyecto PRISMA. Sin embargo, basándonos en nuestra experiencia en este y otros proyectos, pensamos que uno de los principales problemas de este método es que presupone un buen nivel de madurez en la planificación y la gestión del proyecto de desarrollo de software, algo que no siempre resulta fácil de encontrar en muchos proyectos informáticos. Otro aspecto que afecta a la aplicación de este método son los conceptos erróneos que rodean la aplicación de técnicas de gestión de riesgos. Padayachee [18] menciona que las equivocaciones surgen “por ver la gestión del riesgo como implícita en la planificación o en la fase de especificación o ver los riesgos como desafíos, anulando la necesidad para la gestión del riesgo”. Esta actitud puede afectar la implicación y participación de las personas encargadas de evaluar los riesgos en todo el proceso. Además, observamos que aunque los gestores aceptaron fácilmente su participación en la fase de identificación de los riesgos, fue necesario adaptar el cuestionario de identificación de riesgos surgido de la taxonomía del SEI, al contexto específico del proyecto. Un buen jefe de proyecto no permitirá que sus directores técnicos estén perdiendo el tiempo contestando preguntas que no se adaptan al proyecto, disminuyendo así el nivel de confianza en el proceso de identificación de los riesgos y en el equipo de Gestión del Riesgo. Ahora también pensamos que realizar entrevistas con los directores técnicos puede ayudar a mejorar la recogida de datos de los riesgos, ya que mediante entrevistas se puede obtener información más detallada. Este aspecto confirma el análisis de Kontio et al. [17], que menciona que la información obtenida mediante entrevistas es más detallada y

permite mejorar calidad de los resultados de la gestión de riesgos, quizás debido a la naturaleza confidencial de las entrevistas y a la posibilidad de concentrarse y profundizar de forma abierta en temas más concretos. Respecto a la fase de análisis de riesgos, esta también fue bien aceptada por los responsables. No pasó lo mismo para la fase de planificación ya que mientras que las fases de identificación y análisis comenzaron a la vez que el desarrollo del proyecto de software, las fase de planificación empezó cuando los responsables estaban concentrados resolviendo problemas de planificación y costes y reduciendo su esfuerzo en las actividades para asegurar el control de la calidad como la gestión del riesgo. Por ello, no hay un plan de mitigación para cada riesgo que debía ser mitigado y no todos los planes de acción están documentados. La situación de las fases de seguimiento y control fue similar, de manera que propusimos que el equipo de gestión del riesgo tenia que comunicar, motivar y ayudar a los directores técnicos en la planificación de los riesgos que debían ser mitigados, su documentación, su seguimiento y control. El segundo resultado principal de la experiencia está relacionado con la extensión de la taxonomía del SEI con los riesgos organizacionales, y el nivel de importancia de estos riesgos organizacionales asignado por el jefe del proyecto y los directores técnicos. La personas encargadas de evaluar los riesgos identificaron la mayoría de los riesgos organizacionales como de importancia alta o media. Además, la mayor parte de estos riesgos no estaban bajo el control del jefe del proyecto o de los directores técnicos. Este hallazgo se ve apoyado por otros estudios de gestión del riesgo (p.e. [7]) que muestran que muchas de las listas de riesgos se centran solo en factores de riesgo sobre los que el jefe del proyecto tiene un relativo grado de control. Los evaluadores de los riesgos tampoco consideraron algunos aspectos organizacionales como riesgos porque ellos no los podrían controlar efectivamente o analizaron estos aspectos desde el punto de vista de su rol. Por ejemplo, los directores técnicos no consideraron la ‘falta de autorización a los responsables’ como un riesgo potencial porque ellos analizaron este asunto en relación con su rol y no con el de sus subordinados. En términos generales, hemos detectado que los aspectos organizacionales relacionados con los roles de las personas o habilidades son los más difíciles de identificar ya que algunas personas son reacias a admitir explícitamente que ellos u otros pueden no estar actuando según lo esperado. Pensamos que la razón más importante es evitar conflictos entre evaluadores. Además, creemos que la gestión de los riesgos de un proyecto en términos de perspectivas organizacionales requiere un conocimiento completo de experiencias anteriores adquiridas en proyectos previos. El hecho de que los asesores externos del equipo de Gestión del Riesgo de PRISMA estaban realizando un estudio de caso en profundidad de los factores críticos de éxito en una la implementación previa de un ERP en la misma universidad,

7

permitió que ellos mismos pudieran también contribuir con algunos riesgos del proyecto que resultaban de una transferencia de temas. Basándose en tal estudio, fue también posible evitar y mitigar de manera adecuada en el proyecto PRISMA algunos de los problemas que ocurrieron en la implementación del ERP. A su vez, esta experiencia ayudó también a transferir al proyecto PRISMA algunas soluciones valiosas que se desplegaron en la implementación del ERP (por ejemplo la planificación y control del programa de formación). Basándonos en esta y otros experiencias similares, creemos que otras organizaciones pueden beneficiarse con la creación de una base de datos de riesgos para sus diferentes proyectos ya que ayudaría a identificar y gestionar los riesgos de los proyectos. Nuestra experiencia sugiere que los riesgos técnicos tienen una solución que en la mayoría de los casos depende en su mayor parte del coste y la disponibilidad de la tecnología mientras que los riesgos organizacionales van más allá de las fronteras del proyecto. En este proyecto, hemos visto que los directores eran capaces de adaptar el método SEI-CRM a sus necesidades. Al igual que la implementación de otras metodologías, técnicas o herramientas de ingeniería del software y sistemas de información, la adopción de un marco de gestión de riesgos se debe tratar con precaución. VII. REFERENCIAS Periodicals: [1]

Adler, P., Shenhar, A. (1990). Adapting your technological base: the organizational challenge, Sloan management review, pp. 25-37. [2] Boehm, B. (1988). A Spiral Model of Software Development and Enhancement, IEEE Computer, 21, pp. 61-72. [3] Doherty N., King, M. (2001). An investigation of the factors affecting the successful treatment of organizational issues in systems development projects, European journal of information systems, 10, pp. 147-160. [4] Hartwick J., Barki J. (1994). Explaining the Role of User Participation in Information System Use, Management Science, 40(4), pp. 440-465. [5] Hoffman T. (1998). Risk management still a wild frontier, Computerworld, 32(7), p. 10. [6] Jiang, J., Klein, G., Discenza, R. (2001). Information Systems Success as impacted by risks and development strategies, IEEE transactions on Engineering Management, 48(1), pp. 46-55. [7] Keil M., Cule E., Lyytinen K., Schmidt R. (1998). A Framework for identifying software project risks, Communications of the ACM, 41(11), pp. 76-83. [8] Mitchell T. (1997). Matching Motivational Intervention to Organizational Contexts, Research in Organizational Behavior, 19, pp. 57-149. [9] Moynihan T. (1997). How Experienced Project Managers Assess Risk, IEEE software, pp. 35-41. [10] Roppponen, J., Lyytinen, K. (2000). Components of Software Development Risk: Hot to address Them?, IEEE transactions on software engineering, 26(2), pp. 98-111. [11] 17. Schmidt, R., Lyytinen K., Keil M., Cule P. (2001). Identifying software project risks, an international Delphi study, journal of management information systems, 17(4), pp. 5-36.

Technical Reports: [12] Carr M., Konda S., Monarch I., Ulrich F., Walker C. (1993). TaxonomyBased Risk Identification, Technical Report CMU/SEI-93-TR-6, Software Engineering Institute, Carnegie Mellon University. [13] KLCI (2001). Software Risk management Practices – 2001, KLCI research group report, available at ttp://www.klci.com (2001). [14] Walsh K., Schneider H. (2002). The role of motivation and risk behavior in software development success, Information research, 7(3), Available at http://InformationR.net/ir/7-3/paper129.html

Papers from Conference Proceedings (Published): [15] Esteves J., Pastor J. (2000). Towards the Unification of Critical Success Factors for ERP implementations, 10th Annual BIT conference, Manchester, UK. [16] Kontio, J. (1997). Empirical Evaluation of a risk management Method, SEI conference on risk management, USA. [17] Kontio, J. Getto, G., Landes, D. (1998). Experiences in improving risk management processes using the concepts of the Riskit method, SIGSOFT’98 sixth international symposium on he foundations of software engineering. [18] Padayachee K. (2002). An Interpretive Study of Software risk management Perspectives, South African Institute for Computer Scientists and Information Technologists (SAICIST) conference.

VIII. BIOGRAFIA José Esteves es Profesor de Sistemas de Información en el Instituto de Empresa. Es Doctor (Ph.D.) en Software, especialidad en Sistemas de Información por la Universidad Politécnica de Catalunya (UPC), Barcelona, Master en sistemas de información, Diploma en Business Administration (DBA), y ingeniero en sistemas y informática. Es autor de varios estudios sobre sistemas ERP publicados en revistas y congresos internacionales. Sus intereses se centran en el campo de implantación y uso de sistemas ERP, impacto de los sistemas de información en las empresas y satisfacción de los usuarios, beneficios de los sistemas de información para las empresas, gestión de conocimiento y su uso a nivel organizacional. Puede ser contactado en [email protected] Joan Pastor es doctor ingeniero y licenciado en informática por la Universidad Politécnica de Catalunya (UPC), donde ha ejercido como profesor e investigador durante quince años y como director de dos postgrados. Actualmente es profesor y director de la ESTIC de la Universitat Internacional de Catalunya, y profesor de doctorado de la UPC. Ha publicado artículos en conferencias internacionales de sistemas de información, ingeniería del software y base de datos. Su investigación reciente se centra en la evaluación, adquisición e implantación de sistemas y tecnologías de información, incluyendo los sistemas ERP. También trabaja en gestión de proyectos informáticos y de sus riesgos, modelización de procesos de negocio, en innovación curricular para las ingenierías informáticas, así como en la adaptación de métodos de investigación a problemas de informática empresarial. Puede ser contactado en [email protected] Nuria Rodríguez es responsable del Area de Calidad del proyecto PRISMA y coordinadora interna del equipo de gestión de riesgos de PRISMA. Licenciada en Matemáticas por la Universidad de Barcelona y Postgrado en Gestión de la Calidad del Software (FPC). En el 2004 ha participado en las conferencias SEPG 2004 (Londres) y JISBD. Puede ser contactada en [email protected]. Ramon Roy es licenciado en informática por la UPC, Master en Banca y Finanzas por la Universidad Pompeu Fabra,. Tiene gran experiencia en la dirección de proyectos informáticos en grandes organizaciones. Colaboró en la organización de los Juegos Olímpicos y Paralímpicos de Barcelona 92 y con el

8

departamento de Informática del grupo Winterthur. En el ámbito universitario, Ramon Roy ha participado en la definición de la infraestructura tecnológica y de sistemas de gestión de la Universidad Rovira i Virgili y ha sido el director del proyecto PRISMA. Actualmente es el Director del Área TIC del Departamento de Educación de la Generalitat de Catalunya. Puede ser contactado en [email protected].