Procedimiento para la Gestión de Riesgos en el Proyecto Sistema de Emisión de Pasaportes Diplomáticos y de Servicios en el Ministerio de Relaciones Exteriores de la República Bolivariana de Venezuela

PROCEDURE FOR RISK MANAGEMENT IN THE PROJECT SYSTEM ISSUANCE OF DIPLOMATIC PASSPORTS AND SERVICES IN THE MINISTRY OF FOREIGN AFFAIRS OF THE REPUBLIC BOLIVARIANA OF VENEZUELA

Ing. Ané Caridad Aguilar Machado(1), Ing. Geidis Sánchez Michel (2)

(1) Universidad de las Ciencias Informáticas-Facultad Regional de Granma, Cuba, [email protected]
(2) Universidad de las Ciencias Informáticas, Cuba, [email protected]

RESUMEN

Para obtener el producto que mejor cumpla con los requisitos que desea un cliente, en el menor tiempo posible y dentro del alcance y los costes planificados, se hace necesario el desarrollo actividades que permitan gestionar un proyecto eficientemente, una de ellas es la Gestión de Riesgos.

El proyecto «Sistema de gestión para la emisión de pasaportes diplomáticos y de servicios en el Ministerio de Relaciones Exteriores de la República Bolivariana de Venezuela» perteneciente al Centro de Identificación y Seguridad Digital, situado en la Universidad de las Ciencias Informáticas, también realiza las actividades que sean necesarias para alcanzar la calidad requerida.

Durante el desarrollo de la investigación se realiza la propuesta de un procedimiento para la Gestión de Riesgos en el proyecto basándose para ello en la Guía de procesos de PMBOK con la metodología Desarrollo Guiado por Funcionalidades. En la propuesta se plantean pasos a tener en cuenta durante las etapas establecidas así como el uso de las técnicas que se escogieron para el análisis de los riesgos además de obtenerse las planillas Plan de Gestión de Riesgos y Registro de Riesgos. Se validó la propuesta mediante el método de evaluación por criterio de expertos.

Palabras Clave:
gestión, riesgo, procedimiento

ABSTRACT

One of the software producer’s biggest questions is how to obtain better products that meet the requirements demanded by costumers, are developed in a relatively short amount of time, and do not exceed planned costs. In order to answer that question is necessary to develop a certain number of activities to manage projects efficiently. One of these activities is the Risk Management.

The project «Procedure for risk management in the Project System Issuance of Diplomatic Passports and Services in the Ministry of Foreign Affairs of the Republic Bolivariana of Venezuela» is part of the digital security and identification center, located at the University of Informatics Sciences. The project is not exempt of performing a certain group of activities to reach a specific level of quality, but nowadays there is no project in the center with an incidents management defined procedure.

In this investigation it is explained a proposed procedure for Risk Management at the project, based on the PMBOK processes Guide with Feature Driven Development methodology. Also described are some steps and techniques defined in the procedure, as well as some artifacts: the Risk Management Plan document and the Risk Record. Finally is included how the procedure was validated by using the Experts Evaluation Method.

KeyWords:
management, risks, procedure

1. INTRODUCCIÓN

En el mundo de los negocios hoy en día las empresas exigen el máximo debido a los grandes cambios que se van gestando y a la extrema competencia entre compañías. El objetivo perseguido por cada empresa es lograr desarrollar las actividades de forma rápida y eficiente, es por esto que en la mayoría de los casos, las actividades que anteriormente se desarrollaban de forma manual, hoy se han complementado con el uso del software.

Entre las ventajas que un producto de este tipo ofrece vale la pena mencionar la organización de la información, el mejoramiento de la productividad, la automatización y mejoramiento de los procesos y procedimientos, la prevención de problemas, la administración del cambio y la posibilidad de gestionar información de cualquier índole.

Es a partir de aquí que el software ha alcanzado un desarrollo vertiginoso en los últimos años. Cada día mayor cantidad de productos de software abarrotan el mercado.

Sin embargo, hay que tener en cuenta que cualquier imprevisto puede afectar en pequeña o gran escala el desarrollo de cualquier producto.

En la elaboración de productos de software se tienen en cuenta una serie de métodos y técnicas de gestión destinados a garantizar la calidad del proceso. Dichas técnicas se nutren tanto en metodologías documentadas como de la experiencia en su aplicación. Los proyectos se planifican con antelación, se lleva un seguimiento y control de las actividades, recursos humanos y materiales que intervienen durante su desarrollo, lo cual permite determinar los problemas que existen en un momento dado y darles solución de forma inmediata, aunque hay problemas que no son tan fácilmente detectados. De este modo la industria del software ha irrumpido con fuerza en el mercado mundial, existiendo cada día más competencia entre las empresas que se dedican a su desarrollo por lograr productos a corto plazo y que cuenten con la calidad requerida.

Cuba también ha optado por el desarrollo de software. Actualmente el desarrollo alcanzado en la producción de software educativo, por citar un ejemplo, ha permitido que se utilicen en las escuelas más de 100 productos diseñados para todo tipo de enseñanzas. Para lograr un correcto desarrollo se utilizan metodologías, técnicas y herramientas para gestionar proyectos, y modelos de calidad que permiten la obtención de resultados satisfactorios.

La Universidad de las Ciencias Informáticas (UCI), surgida como una idea de Fidel Castro durante la Batalla de Ideas, se ha dado a la tarea de convertirse en un centro de excelencia, y contribuir, no solo a la informatización del país, sino al desarrollo de la economía del mismo mediante el modelo de formación existente en el centro. Modelo en el cual se vinculan el estudio y el trabajo en la producción de software. Por tanto, en la UCI, además de impartirse la docencia como en todas las universidades, se tiene como misión producir software y brindar servicios informáticos. En realidad lo que se espera es que la informática se convierta en uno de los renglones económicos más productivos dentro del país, capaz de aportar recursos al mismo, tanto con el capital procedente de las exportaciones de software, como la solución a numerosos problemas de informatización que existen actualmente. Esta situación se deriva de las limitantes que existen a raíz del bloqueo, el desarrollo en este campo es aún incipiente aunque se está trabajando incansablemente por acelerarlo.

El Centro de Identificación y Seguridad Digital (CISED) se encuentra enmarcado en la UCI, surge como un nuevo nivel de organización de los polos productivos que existían con anterioridad, donde se agrupaban los proyectos que abordaban temáticas similares, en el mismo se gestionan una serie de proyectos en pos de obtener productos con calidad. Varias entrevistas realizadas a jefes de proyecto y responsables de calidad del Centro sobre cómo se lleva la Gestión de Riesgos (GR) en sus proyectos actualmente, arrojaron resultados poco alentadores respecto al tema.

Las entrevistas se realizaron a un total de 8 personas, un 70% de ellas coinciden en que los riesgos en sus respectivos proyectos se identificaron en sus inicios de forma empírica por parte de los miembros más experimentados. En algunos casos la lista de riesgos fue desarrollada por el jefe del proyecto, actualmente a esos riesgos identificados no se les da ningún tipo de seguimiento.

El 30% restante plantea que en sus proyectos sí se han identificado y actualmente se lleva un seguimiento, pero para esto no utilizan técnicas específicas sino que se desarrolla de forma experimental. En los inicios del proyecto «Sistema de gestión para la emisión de pasaportes diplomáticos y de servicios en el Ministerio de Relaciones Exteriores de la República Bolivariana de Venezuela»- perteneciente al CISED y aún incipiente en su desarrollo- se identificaron algunas contingencias de manera empírica y sin repercusión alguna en el actual accionar del personal vinculado al proyecto.

Actualmente no cuenta con un mecanismo para identificar las amenazas que puedan tronchar su crecimiento como producto, y a su vez manejarlas para evitar problemas mayores en un futuro. Como se pudo constatar no es posible el uso de un procedimiento que se haya usado anteriormente en uno de los proyectos del CISED, pues no hay ninguno establecido y que esté en funcionamiento. A raíz de esta situación que se ha venido presentando en el proyecto se ha llegado al siguiente problema científico: ¿Cómo gestionar los riesgos en el proyecto «Sistema de gestión para la emisión de pasaportes diplomáticos y de servicios en el Ministerio de Relaciones Exteriores de la República Bolivariana de Venezuela»?
Para el desarrollo de la investigación se ha trazado como
objetivo general: desarrollar un procedimiento para la Gestión de Riesgos en el proyecto «Sistema de gestión para la emisión de pasaportes diplomáticos y de servicios en el Ministerio de Relaciones Exteriores de la República Bolivariana de Venezuela».

2. ANTECEDENTES DE LA GESTIÓN DE RIESGOS

Riesgo:

un riesgo de un proyecto es un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, como tiempo, coste, alcance o calidad (es decir, cuando el objetivo de tiempo de un proyecto es cumplir con el cronograma acordado; cuando el objetivo de coste del proyecto es cumplir con el coste acordado; y así sucesivamente). Un riesgo puede tener una o más causas y, si se produce, uno o más impactos. ^[1]

Gestión de Riesgos:

La gestión de la reducción del riesgo constituye un eje transversal e integrador en los diferentes procesos, tiene por objetivo garantizar que los procesos de desarrollo impulsados en la sociedad se den en las condiciones óptimas de seguridad posible para la infraestructura y población, y que la atención y las acciones desplegadas ante un desastre promuevan el mismo desarrollo. Así mismo, involucra etapas como la prevención, mitigación de desastres, la respuesta a la emergencia, la rehabilitación y la reconstrucción. ^[2]

MAGERIT:

metodología de análisis y GR elaborada por el «Consejo Superior de Informática» de España sobre el análisis y GR de los sistemas de información. Describe los pasos y las tareas básicas para realizar el análisis y la GR de un proyecto y proporciona una serie de aspectos prácticos. Describe los pasos para realizar el estado de riesgo y para gestionar su mitigación, entendiendo que no basta con tener los conceptos claros, sino que es conveniente pautar roles, actividades, hitos y documentación para que la realización del proyecto de análisis y GR esté bajo control en todo momento. Plantea que los proyectos de desarrollo de sistemas deben tener en cuenta los riesgos desde el primer momento, tanto los riesgos a que están expuestos, como los riesgos que las propias aplicaciones introducen en el sistema. ^[3]

Feature Driven Development (FDD):

esta metodología se usa actualmente para el desarrollo en el proyecto «Sistema de gestión para la emisión de pasaportes diplomáticos y de servicios en el Ministerio de Relaciones Exteriores de la República Bolivariana de Venezuela». Consta de 5 procesos para el desarrollo:

• Desarrollo de un modelo global.
• Construcción de una lista de funcionalidades.
• Planeación por funcionalidad.
• Diseño por funcionalidades.
• Construcción por funcionalidades.

No hace énfasis en los requerimientos sino en el diseño y la construcción. Enfatiza mucho más los aspectos de la calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto. Es un proceso que ayuda al equipo a producir resultados periódicos y tangibles. Esta metodología propone tener etapas de cierre cada dos semanas, lo cual implica que los desarrolladores tendrán nuevas actividades que realizar en dicho período de tiempo. Esto hace que la motivación del equipo se mantenga durante todo el proyecto debido a que se ven los resultados periódicamente. ^[4]

PMBOK:

en PMBOK la GR del proyecto incluye los procesos relacionados con la planificación de la GR, la identificación y el análisis de riesgos, las respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto; la mayoría de estos procesos se actualizan durante el proyecto. Para PMI uno de estos procesos ocurre al menos una vez en un proyecto y en una o varias fases si el mismo está dividido en fases. ^[1]

ISO/IEC 27005:2008:

Proporciona una guía para la GR en un sistema de seguridad de la información. Soporta los conceptos definidos en la ISO/IEC 2700116 y está diseñado para ayudar a la implementación de un sistema de seguridad de la información basado en la GR.
El proceso consiste en: ^[5]

• Establecimiento del contexto.
• Evaluación de riesgos.
• Tratamiento de los riesgos.
• Aceptación del riesgo.
• Comunicación del riesgo.
• Control del riesgo y revisión.

3. PROCEDIMIENTO

La propuesta del procedimiento para la Gestión de Riesgos en el proyecto «Sistema de Gestión para la Emisión de Pasaportes Diplomáticos y de Servicios en el Ministerio de Relaciones Exteriores de la República Bolivariana de Venezuela», sigue las políticas establecidas por la Guía de Procesos de PMBOK y se vincula con la metodología de desarrollo utilizada en el proyecto, FDD.

El objetivo del mismo es: obtener una estructura de actividades correctamente definidas, que permitan a los integrantes del proyecto reducir el impacto de las amenazas y potenciar el impacto de las oportunidades que surjan durante el desarrollo del producto.

3.1 Planificación de la Gestión de Riesgos

Para esta etapa se hace necesaria una serie de elementos de entrada que son fundamentales en la elaboración del Plan de GR (PGR), artefacto de salida durante la planificación de la GR. Primeramente deben tenerse en cuenta los factores ambientales de la empresa, los cuales aparecen en algunos documentos donde debe expresarse de manera general: la cultura y estructura de la organización, las normas gubernamentales o industriales, la infraestructura, los recursos humanos existentes, entre otros. Ejemplo de ellos: los documentos de roles y responsabilidades del proyecto y Ambiente de desarrollo, ambos aparecen en el expediente del proyecto. Deben incluirse además, dentro de estos factores, las revisiones de leyes, normas y decretos de la República Bolivariana de Venezuela relacionadas con temas sobre la informática. Como ejemplo de lo anteriormente mencionado se encuentra el Decreto 3.3.90 donde se establece, entre otras cosas, el empleo prioritario del software libre en el desarrollo de sus sistemas, proyectos y servicios informáticos.

Entre los elementos que no pueden faltar para planificar la GR en el proyecto se encuentran los activos de los procesos de la organización, los cuales no son más que las políticas a tener en cuenta dentro del Centro, ejemplo de ello la política de seguridad que existe en el mismo. Parte de la propuesta es la definición de varios puntos a agregar en los activos, tales como: las categorías de riesgo con que se va a trabajar, así como roles que intervienen durante la GR del proyecto y correspondientes niveles de autoridad. Por último, debe contarse con el Proyecto técnico, el cual contiene el alcance del proyecto, y el PGP dentro del cual deben estar presentes el Presupuesto de Gastos y el Reporte del cronograma del proyecto.
En esta etapa se realizarán las reuniones de planificación y análisis donde cada miembro aporta sus experiencias y opiniones. En la primera de las reuniones de este tipo, el Jefe de proyecto da a conocer cómo se llevará a cabo la GR en el proyecto por parte de cada rol y en qué tipo de reuniones se va a tratar el tema.
El Jefe de proyecto también especificará cómo se va a trabajar según los activos de los procesos de la organización, se explica en esta reunión cómo llevar a cabo el proceso para la definición de las probabilidades de los riesgos, niveles de riesgo, impacto por objetivo, y cómo se va a estructurar la matriz de probabilidad e impacto adaptada a los objetivos primordiales del proyecto. En posteriores reuniones de este tipo se llevará a cabo una monitorización del proceso y se tomarán las medidas necesarias para seguir adelante con lo planteado primeramente, o si es necesario realizar cambios y trazarse nuevas estrategias.

Los roles involucrado en esta etapa están relacionados con la metodología de desarrollo utilizada en el proyecto, FDD debe estar presente el jefe de proyecto, el gerente del proyecto, el planificador, el analista principal, uno o dos programadores, un probador, un diseñador y cualquier otro miembro que decida el jefe del proyecto, o propongan los demás miembros, a partir de la experiencia y necesidades que existan dentro del equipo de desarrollo.

Todas las acciones realizadas en esta etapa quedarán reflejadas en el Plan de Gestión de Riegos. Este documento será conformado por el jefe de proyecto en la medida de su desarrollo, aunque los puntos que lo componen pueden ser asignados indistintamente a varios responsables dentro del proyecto. A continuación se listan los elementos que lo componen: metodología, roles y responsabilidades, preparación del presupuesto, periodicidad, categorías de riesgo, definición de probabilidad e impacto de los riesgos, matriz de probabilidad e impacto y seguimiento.

El PGR se actualiza, en la medida en que aparecen nuevas categorías de riesgos, se cambian los niveles de atención al riesgo por roles, las definiciones de probabilidad, o algún cambio de este tipo, esto puede darse en las reuniones quincenales con el equipo del proyecto, o en otra de las reuniones, en las actividades de seguimiento al riesgo, entre otros.

3.2 Identificación de los riesgos

Para esta etapa se revisan todos los elementos de entrada de la etapa anterior agregando el PGR. Estos documentos pueden ofrecer una visión general y a la vez bastante abarcadora del proyecto, la cual facilitará la identificación de riesgos en el mismo. Las técnicas propuestas a utilizar son: la tormenta de ideas, como técnica de recopilación de información, mediante esta cada integrante desde su puesto de trabajo aportará los riesgos que según el rol que desempeñe crea pueden alterar el curso del proyecto; la técnica de análisis de asunciones, la cual se utiliza con el objetivo de tener en cuenta las leyes de la República Bolivariana de Venezuela que de algún modo incidan en el desarrollo de la aplicación; por último, las revisiones de documentación.

Las técnicas van a comenzar a implementarse acto seguido de la conclusión del PGR, incluso se pueden ir identificando los riesgos antes de la reunión de planificación. En caso que no existan expertos disponibles para el tratamiento de riesgos, como es probable que ocurra en el proyecto debido a la falta de personal capacitado y libre, se puede realizar la tormenta de ideas de igual modo, todo está en el apoyo del equipo y que se puedan identificar la mayor cantidad de riesgos posibles. En lo que respecta a las revisiones de documentación, en caso de ser documentos de otros proyectos, deben ser autorizadas por sus correspondientes responsables.

Serán partícipes todos los miembros del proyecto durante la tormenta de ideas siempre y cuando tengan como moderador principal al jefe del proyecto. Las revisiones de documentación y análisis de asunciones se llevarán a cabo por el jefe del proyecto, el analista principal, el arquitecto y el planificador los cuales son los que más al corriente están de los aspectos fundamentales del proyecto, incluyendo cronograma, presupuesto, alcance, entre otros aspectos manejados directamente por algunos de estos individuos.

El documento de salida para esta etapa es el Registro de Riesgos (RR) como uno de los componentes del PGP. Este registro contiene una lista de los riesgos identificados, cada uno de los riesgos deben aparecer en el registro con las posibles causas que lo han originado, además de un listado de las posibles respuestas a las contingencias identificadas. Por último, deben relacionarse en el documento, en caso de existir, la actualización de categorías de riesgo a añadir.

3.3 Análisis cualitativo de riesgos

Para esta tercera etapa serán los factores ambientales, los activos de los procesos de la organización, el Proyecto técnico, el PGR y el RR, las entradas principales que servirán para el posterior análisis de los riesgos identificados y estado actual del proyecto respecto a los mismos. Las técnicas a usar son: la evaluación de probabilidad e impacto de los riesgos con la correspondiente matriz de probabilidad e impacto. De cada riesgo se evaluará la probabilidad y el impacto en los objetivos del proyecto a través de las entrevistas y reuniones planificadas. Los objetivos a evaluar en el proyecto son:

• Planificación: los riesgos que atentan contra este objetivo están afectando la programación del logro de las metas trazadas así como los medios para la obtención de dichas metas.
• Costo: en este caso los riesgos que afectan el presupuesto y todo lo que signifique gastos durante la elaboración del producto.
• Alcance: los riesgos que afectan el alcance atentan en contra o a favor de la visión del producto, la meta a la que se ha propuesto llegar el proyecto.
• Rendimiento: afectan la utilidad del producto resultante. El producto no tiene la calidad requerida, no logra el objetivo para el que fue diseñado, o en el caso de ser una oportunidad, el producto es rentable y útil.
• Mantenibilidad: estos riesgos afectan la corrección rápida de errores del producto, debido a la dificultad o no, que existe para llevar a cabo su modificación.

Estas técnicas serán aplicadas con el jefe de proyecto como principal responsable apoyado por el planificador, analista y arquitecto. Para la misma será necesaria la participación de un experto al cual se debe invitar, debe ser alguien que esté preparado en el tema de la GR, también colaboran en esta etapa tantos integrantes del proyecto como el jefe de proyecto estime pertinente, tanto en correspondencia con la familiaridad que se tenga con el riesgo como de la categoría a la que pertenezca este.

Para concluir con esta etapa los riesgos serán priorizados para el posterior análisis y esto se mostrará en la matriz de probabilidad e impacto.

Finalmente, quedará el RR actualizado.

Esto significa que al registro que quedó como resultado de la etapa de IR se le agregan nuevos elementos.

3.4 Análisis cuantitativo de riesgo

Esta etapa presenta los mismos elementos de entrada que la etapa de análisis cualitativo de riesgos sumándose el PGP con los respectivos documentos que lo componen.

La técnica a emplear para el análisis de los riesgos priorizados es la del árbol de decisiones, para este se tomará cada riesgo con los posibles escenarios que implica, se evalúa cada camino hasta ver todos los posibles, para esto es necesario conocer el valor monetario que puede implicar cada camino a seguir, en caso que no implique valor alguno se pone 0.

Luego de valorar cada riesgo tras haber aplicado la técnica quedará el RR actualizado.

Para observar si se han obtenido resultados este análisis debe efectuarse nuevamente luego de la planificación de las respuestas a contingencias y durante el seguimiento y control de riesgos.

El jefe de proyecto es el encargado del desarrollo del análisis cuantitativo conjuntamente con el analista principal y el planificador debido a que estos cuentan con un vasto conocimiento sobre el proyecto, para esta tarea es necesario estar muy familiarizado con el riesgo para poder emitir criterios que brinden resultados certeros. El económico por su parte también juega un papel fundamental en esta etapa por su actuación en el manejo del presupuesto del proyecto.

Como artefacto resultante para esta etapa queda el RR actualizado con los siguientes elementos: Análisis probabilístico del proyecto, objetivos críticos, lista priorizada de riesgos cuantificados y tendencias en los resultados del análisis cuantitativo de riesgos.

3.5 Planificación de respuestas a riesgos

Luego de concluir con el análisis cuantitativo de los riesgos queda planificar, trazarse estrategias para evitar los riesgos, o al menos amortiguarlos, y en caso de que sean ventajosos pues entonces mejorar las oportunidades.

Los elementos de entrada para esta etapa son el PGR y el RR actualizado. Las estrategias que cada uno de los involucrados deben aplicar para tratar el riesgo están en dependencia del riesgo en sí. Lo primero que se hace es determinar si se está frente a una amenaza, entonces se deberán evitar, transferir o mitigar; en el caso de que no se pueda hacer nada se acepta el riesgo con las consecuencias que implique. Para el caso que sea una oportunidad se adopta la posición de aceptarlos ya que reportarían beneficios para el proyecto, a partir de entonces se debe mejorar, compartir o explotar. Es muy importante tener en cuenta que si se toma la oportunidad esta no acarree consigo un riesgo negativo que haya que mitigar luego. Todo se somete a valoración.

En cuanto a los riesgos negativos, si es posible desde el primer momento eliminarlo, es preferible hacerlo antes de esperar a mitigarlo. En el caso que no se pueda eliminar y se pueda transferir, pues se transfiere, en dependencia del tipo de riesgo que se trate según las categorías que existen y las posibilidades de transferencia. Es necesario que, aunque se tomen medidas de reducción de la probabilidad de ocurrencia del riesgo, también se tomen las medidas pertinentes para la reducción del impacto en caso de llegar a ocurrir, nunca hay que confiarse de que se ha mitigado completamente.

El jefe de proyecto asignará cada riesgo a la persona del proyecto encargada de dar respuesta al mismo, para esto tendrá en cuenta la categoría del riesgo, el nivel de afectación en los objetivos del proyecto en caso de ocurrir, el área en que se encuentre trabajando dentro del proyecto, entre otros elementos que considere convenientes. Debe ser una persona responsable y la respuesta debe ser realista en el contexto del proyecto.

Parte de los artefactos resultantes será el RR actualizado. A los elementos que ya contenía se le adicionan:

• Actualización del análisis probabilístico del proyecto.
• Para cada estrategia de respuesta se listan una serie de acciones que se van a llevar a cabo.
• Cuando cada responsable de riesgo ha ofrecido su solución al riesgo, se plantea una estructura del análisis, desarrollado por el planificador, con las actividades del cronograma necesarias para llevar a cabo dichas propuestas. De igual modo, luego del análisis, plantea en el RR las reservas de tiempo y presupuesto con las que se cuenta para casos de contingencias.
• Se debe crear un pequeño plan con medidas técnicas, humanas y organizativas para el caso de que fallen las medidas anteriores, además se especifican las condiciones tras las cuales se debe poner en marcha el plan.
• Cuando el responsable de un riesgo plantea una respuesta, y alguien del equipo de desarrollo propone otra solución, se puede consultar con otros miembros del equipo hasta llegar a la que estimen que es la solución óptima. Para estos casos la nueva solución no se desecha, sino que se hace un listado aparte con un plan de reserva en caso que falle la respuesta propuesta.
• Riesgo residual: se espera que surja luego de implementar una respuesta planificada. Estos riesgos se van a ubicar en una nueva tabla denominada de riesgos residuales donde aparece el nombre del riesgo residual, el riesgo que le dio origen y el responsable.
• Riesgo secundario: cada responsable de riesgo, es también responsable de los nuevos riesgos que puedan surgir tras la implementación de la solución propuesta. Estos riesgos se van a ubicar en una nueva tabla denominada de riesgos secundarios donde aparece el nombre del riesgo secundario, el riesgo que le dio origen y el responsable.

Otro de los artefactos generados para esta etapa es el PGP el cual se actualiza con las nuevas actividades de respuesta que han surgido. Para realizar esta actualización se tiene que haber pasado primero por el proceso que se lleve en el proyecto para controlar los cambios.

3.6 Seguimiento y control de riesgos

Un problema que muy a menudo se observa es el hecho de tener definidos los riesgos desde el inicio del proyecto y no tratarlos más hasta que sorpresivamente suceden y causan efectos negativos en el desarrollo del mismo. Para que esto no ocurra existe una etapa de seguimiento y control de riesgos.

Esta etapa tiene como entradas el PGR, el RR, el Registro de revisiones y cambios del proyecto, el cual debe estar actualizado y el informe de rendimiento del proyecto. Dos de las técnicas a utilizar son la reevaluación de los riesgos y las auditorías, estas examinan y documentan la efectividad del tratamiento dado a los riesgos tanto como la efectividad del PGR. Por último, la técnica de reunirse para conocer el estado del proyecto servirá como un marco propicio para abordar como uno más entre los puntos del orden del día el estado de la GR en el proyecto.

La reevaluación de los riesgos se realiza con el objetivo principal de identificar nuevos riesgos y chequear el proceso que se está siguiendo con los que ya han sido evaluados.

Se planifican periódicamente y durante este proceso se vuelve a comenzar desde la etapa de IR una nueva iteración.

En el caso de las auditorías se hace por parte del jefe de proyecto, como está establecido, una revisión de la documentación que debe estar al día. Se analiza el RR para ver si concuerda con las actividades que se han llevado a cabo en el proyecto entre otros aspectos que se quieran verificar. En este punto servirá de ayuda el Redmine para la verificación del cumplimiento de las acciones planificadas para el tratamiento de los riesgos.

En las reuniones sobre el estado de riesgos cada responsable debe explicar si la respuesta sugerida al riesgo fue de ayuda o no, si surgieron nuevos riesgos, en caso que este no se pueda responsabilizar de los riesgos secundarios hay que llegar a un acuerdo de quién lo va a hacer, en la medida en que esto ocurre se toman los acuerdos pertinentes y se actualiza el RR.

La reevaluación de los riesgos deben ser programadas por el jefe de proyecto y planeadas por el planificador de modo que no afecten el flujo de trabajo en el proyecto y en dependencia de cómo se vayan cumpliendo los objetivos trazados. El seguimiento de cada riesgo es tarea de su respectivo responsable.
De igual modo las auditorías y las reuniones del estado del proyecto se organizan por el planificador y se especifican las fechas en el cronograma y en el PGR.

4. VINCULACIÓN DE LA PROPUESTA DE SOLUCIÓN CON LA INFRAESTRUCTURA DE DESARROLLO DEL PROYECTO

Actualmente en el proyecto se utilizan varias herramientas, tanto para la gestión como para el desarrollo del mismo. Como parte de la propuesta de procedimiento se pretende mostrar cómo se vinculan estas herramientas con la GR del proyecto.

Redmine:

esta herramienta posibilita la asignación y control de tareas, realiza el envío de notificaciones al correo a los integrantes del proyecto para avisar sobre el cumplimiento de las mismas, además de mostrar los porcientos de cumplimento de estas para cada uno de los integrantes. Otra de las ventajas ofrecidas por la herramienta es que permite pasar la asistencia diariamente en el proyecto y realizar gráficas sobre el estado de la planificación. Por todas las oportunidades que ofrece, Redmine se considera una herramienta idónea para apoyar la GR del proyecto, la misma posibilita mediante sus características llevar a cabo un control y seguimiento de las tareas, permite a la alta gerencia del proyecto identificar aquellos factores que son los que mayormente inciden en atrasos en el cronograma, detectar las áreas más afectadas y, de esta forma, centrar los esfuerzos en los elementos que más inciden en las limitaciones detectadas. Durante el proceso de auditorías se puede comprobar si verdaderamente se les dio cumplimiento a las acciones trazadas en el RR para la mitigación de riesgos.

Subversion:

es un entorno centralizado que permite almacenar ficheros. La herramienta posibilita que dentro del proyecto los integrantes del mismo puedan trabajar siempre sobre la última versión de lo que hasta el momento se ha hecho, de esta forma se evita el trabajo sobre versiones desactualizadas de los ficheros que puedan crear inconsistencias en el producto final, además, facilita el trabajo en equipo. Mediante esta herramienta se puede detectar la fecha exacta en que un integrante del proyecto actualizó determinado fichero.

Permite un mayor control de las actividades durante el proceso de GR y contribuye a las auditorías y revisiones, dentro de estos ficheros se incluyen todos los documentos pertenecientes al expediente del proyecto y por supuesto el PGR y el RR.

5. VALIDACIÓN DE LA PROPUESTA

Para validar la propuesta de solución se utilizó la técnica de panel de experto, donde se arrojaron los siguientes resultados.

• Todos los expertos están de acuerdo en que el procedimiento es de fácil entendimiento para los integrantes del proyecto. Confiriendo para ello las evaluaciones de 4 y 5 puntos significando esto un 67% y un 33% respectivamente.
• En lo que respecta a la correcta definición de los procesos, los resultados fueron similares al anterior, un 67% de los expertos evaluó este aspecto con una puntuación de 4 y el 33% restante de 5 puntos.
• En cuanto al punto que aborda el nivel de influencia del procedimiento en la reducción de los impactos negativos del proyecto, los resultados varían un poco respecto a los obtenidos con anterioridad. Todos los expertos concuerdan en que el procedimiento permitirá reducir el impacto de los riesgos negativos en el proyecto, sin embargo, la forma en que lo hace no es considerada por todos de la misma forma. Se determinó que en un 11% de las opiniones corresponden a una valoración de 3 puntos, esto no significa que el resultado sea caótico pues un 56% emitió una evaluación de 4 puntos y el restante 33% de 5 puntos, por lo que se puede observar que la mayoría emitió una valoración de bien o excelente.
• Las técnicas usadas fueron consideradas suficientes. En cuanto a este punto el mayor número de expertos, el 67%, consideran que la propuesta tiene un valor de 5 puntos.
• El incremento de las oportunidades en el proyecto, fue valorado en su mayoría, el 78%, con una evaluación de bien y el 22% restante considera el procedimiento excelente en este aspecto.
• El 67% de los expertos consideran la propuesta excelentemente compatible con FDD lo cual se considera muy ventajoso para el momento en que se ponga en marcha en el proyecto.

6. CONCLUSIONES

Durante el desarrollo de la investigación se analizó la GR como una de las etapas fundamentales dentro de la Gestión de proyectos. Se realizó un estudio del estado del arte, tras abordar diferentes enfoques se arribó a la conclusión de utilizar la Guía de procesos del PMBOK unida a FDD para el desarrollo de un procedimiento que permita lograr un correcto tratamiento a los riegos en el proyecto.

Se conformó una propuesta de procedimiento para gestionar riesgos en el proyecto teniendo en cuenta los roles que actúan, el flujo de procesos por cada etapa y los artefactos resultantes.

Mediante el uso del método de evaluación por el criterio de expertos se pudo realizar la valoración de la propuesta, obteniendo la mayor cantidad de aspectos evaluados entre 4 y 5, por lo que se puede decir que la misma cuenta con un buen grado de aceptación.

7. REFERENCIAS BIBLIOGRÁFICAS

[1] Institute, Project Management., A Guide to the Project Man-agement Body of Knowledge (PMBOK Guide) . EE.UU : s.n., 2008.

[2] Cardona, O.D. y LAVELL, A. M., «Conceptos y definiciones de relevancia en la Gestión del Riesgo.» SNET. [En línea] Marzo de 2002. [Citado el: 12 de Septiembre de 2010.] http://www.snet.gob.sv/Documentos/conceptos.htm.

[3] , «MAGERIT – versión 2. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información.» Consejo Superior de Administración Electrónica. [En línea] http://www.csae.map.es/csi/pg5m20.htm.

[4] Calabria, L., MetodologíaFDD. Montevideo, Uruguay. : s.n., 2003.

[5] , ISO/IEC, 27005. Switzerland : s.n., 2008.