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 (SEI-
CRM). 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.
I. INTRODUCCIÓN
L 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

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
2
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

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 SW-
CMM 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.
Controlar
Jefe del
proyecto Riesgos
• Revisar
• Repriorizar
importantes • Integración de
los equipos
Responsables Analizar
de área • Revisar
• Priorizar
• Evaluar
• Clasificar
Todo el
Riesgos
equipo
PRISMA 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.
3
- 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,
Transferir
riesgo
y evaluar y ayudar al jefe del proyecto en actividades
Asignar
responsabilidad de criticidad elevada.
Equipo de
Ayuda a la
Plan
• aprobar planes
Gestión del
Riesgo
IV. IMPLEMENTACIÓN DEL SEI-CRM EN PRISMA
• Recomendar
planes
Indicadores
A. Fase de Identificación de Riesgos
Seguimiento 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 1.- Identificar la lista de

SEI Riesgos de PRISMA
Contexto
proyecto
Lista provisional de los
riesgos de PRISMA
PRISMA
2.- Proceso continuo
Comparar lista de riesgos
de identificación
Otras listas de riesgos
de riesgos de PRISMA con otras listas
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
Gestión efectiva del cambio Comunicación interna y externa
organizacional Plan formalizado del proyecto
Buena gestión del ámbito del proyecto Programa de formación adecuado
Composición adecuada del equipo del Previsión de problemas inesperados
proyecto Uso adecuado de consultores
Rediseño adecuado de los procesos de Responsables debidamente
negocio autorizados
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

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 qué información, cuándo la necesitaban, cómo se le
Falta de un plan de gestión del cambio
Alto Estratégico
organizacional
Falta de implicación y participación de
los usuarios
Medio Estratégico
Falta de comunicación interna y externa Medio X Táctico
Inadecuada planificación y evaluación
Medio Táctico
del programa de formación
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
5
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
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.

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 SEI-
CRM 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
6
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,

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). Taxonomy-
Based 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
7
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 jose.esteves@ie.edu
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 jap@unica.edu
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 nuria.rodriguez-camara@upc.edu.
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 ramon.roy@gencat.net.