Saltar al contenido

Implantación de sistemas de software libre

Implantación de sistemas de software libre

El Seguimiento del proyecto.

  • admin 

Imagina el plan de proyecto perfecto, un plan basado en necesidades y objetivos reales y precisos de tu cliente y usuarios, una estimación con técnicas formales basadas en estadísticas de productividad de tu equipo y empresa, y un equipo de trabajo sumamente capaz.  Todo parece perfecto, no hay razón alguna por la que este proyecto pudiera fallar, ¿o si?

Planear no es todo

Malas noticias, tu proyecto podría fallar a pesar de las ventajas de lo mencionado anteriormente.  Si tú, como líder de proyecto, no eres capaz de mantener una clara y precisa visión con respecto a la situación real del proyecto en todo y cada momento, y/o si no eres capaz de reaccionar oportunamente y de manera eficaz ante las desviaciones del proyecto, éste podría ser parte de las estadísticas de proyectos fallidos.

Para mantener esa visibilidad sobre lo que ocurre en el proyecto necesitas contar con información precisa de lo que está ocurriendo en todo momento.  Es mejor escuchar al padre de la calidad, Deming, cuando dice “En Dios confiamos, los demás traigan datos”.  Ten cuidado si piensas confiar en un simple “vamos bien”, como respuesta por parte de tus recursos cuando te reportan el estado del  proyecto.

Parámetros de control

Es conveniente ponernos de acuerdo en el significado del concepto “proyecto fracasado”.  Normalmente nos hace pensar en proyectos que terminan en situaciones como las siguientes:

  • No incluía todas las características que el cliente quería
  • No le resolvió al cliente sus necesidades
  • No alcanzó el dinero para pagarlo
  • No se terminó cuando se esperaba

Es decir, nos referimos a que alguno(s) de los parámetros básicos de planeación y control del proyecto no se cumplió, por ejemplo alcance, tiempo o costo.

Así que si piensas que ser líder de proyecto se limita a identificar el objetivo del proyecto, armar el equipo, girar instrucciones y confiar en que tu equipo las va a seguir al pie de la letra, permíteme decirte que estás equivocado.  Es muy importante hacer todo eso, pero tu plan puede empolvarse y descomponerse más pronto de lo que te imaginas si no tienes el cuidado necesario para que éste se cumpla.  Es aquí donde entra la actividad conocida como SEGUIMIENTO o MONITOREO del proyecto.

¿Y a qué se refiere este seguimiento o monitoreo del proyecto?  Va mucho más allá de simplemente asomarse a ver cómo van las tareas asignadas.

De acuerdo a ciertas definiciones formales, el seguimiento del proyecto consiste en:

Proveer una adecuada visibilidad a la administración sobre la situación del proyecto para identificar oportunamente cualquier desviación contra lo planeado con el objetivo de tomar decisiones oportunas para corregirlas.

Visibilidad

Tú, como líder o administrador del  proyecto eres responsable de conocer en todo momento qué pasa con el proyecto; a eso se refiere la visibilidad.  Para lograr esto debes de mantenerte muy atento a todo lo que sucede en el proyecto, debes realizar las preguntas adecuadas a los participantes y buscar y analizar los datos importantes del mismo.

Preguntas a resolver

Algunas preguntas fundamentales que debes poder contestar:

  • ¿Cuál es el avance en las tareas de los recursos contra lo planeado? (cuánto deberían de haber logrado hasta ahora y cuánto han logrado)
  • ¿Cuál es la desviación en tiempo de las tareas? (y del proyecto)
  • ¿Cuál es la desviación en costo de las tareas? (y del proyecto)
  • ¿Cuánto más se va a desviar el proyecto considerando el nivel de retraso que se está teniendo en las tareas? (te recomiendo que leas acerca de técnicas como valor devengado o “earned value”)
  • ¿Cuál es la desviación en rentabilidad del proyecto?
  • ¿Cuáles y cuántos han sido los cambios al alcance original del proyecto?
  • ¿Se están logrando los objetivos del proyecto?

No permitas que aumente la desviación

Cuándo identifiques las desviaciones hazlo con las unidades de medición correspondientes, tales como tiempo de retraso, dinero, funciones o características, pero también hazlo en porcentaje para cada uno de estos parámetros.  Identifica el porcentaje de desviación de lo real contra lo planeado para poder identificar si hay una oportunidad real de corregir el camino y alcanzar el objetivo del proyecto de manera exitosa.

Es importante saber que el proyecto ya se retraso 5 días, pero también debes de saber si eso implica un 5% de desviación o un 50% de desviación contra lo planeado.  Es importante saber si el proyecto tiene una desviación de $ 70,000 en costos, pero también es muy importante si eso representa un 2% del proyecto o un 80%.  La diferencia entre mantener tu trabajo o ser despedido del proyecto, podría recaer en este “simple” hecho .

Frecuencia del monitoreo

Entre más pronto identifiques las desviaciones del proyecto, más factible será corregirlas.  Es por eso que debes de buscar y analizar los datos con la suficiente frecuencia.  La recomendación es que por lo menos una vez a la semana realices las actividades de seguimiento para tu proyecto.

Aunque, si notas que las cosas se están poniendo feas en tu proyecto, aumenta la frecuencia con que realices el seguimiento.  Quizás tengas que estar revisando con detalle el estado del proyecto todos los días, o incluso varias veces al día, para evitar que las cosas se pongan peor.

Créeme, si las cosas se pueden poner mal, hay grandes probabilidades de que así sea.  Pero, además, siempre se pueden poner peor.  Así que es mejor hacer algo para evitar que esto suceda.

Técnicas de seguimiento

¿Y cómo deberías de realizar el seguimiento?  A continuación las técnicas básicas que normalmente utilizamos para este fin:

  1. Reuniones. Reuniones con el equipo de trabajo de manera grupal y/o individual para revisar el progreso de su trabajo.
  2. Revisiones. Revisiones de los productos elaborados de acuerdo al plan de trabajo para validar que los avances sean reales y los productos tengan la calidad suficiente como para considerarlos completados.
  3. Reportes. Reportes individuales de los integrantes del equipo de acuerdo a una frecuencia especificada (por ejemplo: semanal o diaria)
  4. Software de Administración. Reportes de los avances y el trabajo realizado por medio de alguna herramienta de planeación y administración de proyectos.

Evita la burocracia documental

La gente en los proyectos suele odiar la documentación y por lo tanto los reportes, pero si no tenemos información precisa será más difícil identificar oportunamente las desviaciones del proyecto y por lo tanto aumentará el riesgo de fracaso en el proyecto.  Conviene que el equipo se acostumbre a reportar la situación del proyecto y tú, como líder de proyecto, a revisarla y analizarla.  En este caso un documento puede hacer la diferencia entre un proyecto exitoso y uno que no lo es.

Lo desafortunado del asunto es que los reportes generados suelen representar burocracia que en lugar de beneficiar ocasiona pérdida de tiempo.  No es necesario contar con una plantilla o formato sumamente elaborado y complicado de llenar para obtener un reporte útil.  Lo importante está en identificar y reportar claramente la información valiosa con respecto a la situación del proyecto.

Si tienes los recursos económicos para invertir en una buena herramienta de software para controlar los proyectos y explotar la información, entonces te recomiendo que la adquieras.  La automatización puede ahorrarte una buena cantidad de esfuerzo y dinero en reportar la información del estado de tu proyecto.

¿Qué debería de incluir un reporte de estado del proyecto?

Para obtener un reporte valioso tenemos que recordar cuáles son los parámetros que hacen de un proyecto algo exitoso (si se cumplen) o que lo convierten en un fracaso (si no se cumplen).  Y usar esos parámetros como los elementos o secciones a reportar.

Recomiendo que por lo menos se incluyan estas secciones, puede ser un documento formal, una herramienta que automatice la explotación de los datos del proyecto o simplemente un correo electrónico, pero asegúrate que tenga por lo menos esta información:

  • Progreso.  ¿Ya terminamos lo que teníamos que terminar a la fecha? ¿cuánto no falta? ¿cuánto se ha retrasado? ¿en qué se ha retrasado? ¿por qué nos hemos retrasado?
  • Alcance. ¿Se identificó lo que se requiere hacer? ¿ha pedido cambios el cliente? ¿se han negociado los cambios? ¿el cliente va a pagar los cambios? ¿cuánto ha cambiado el alcance original?
  • Tiempos.  ¿Cuál es el retraso del proyecto en tiempo y porcentaje? ¿cuál ha sido el cumplimiento de los hitos (milestones) del proyecto? ¿cuál es el retraso del proyecto?
  • Costos. ¿Cuánto se ha gastado? ¿cuánto se debería de haber gastado? ¿cuánto se va a gastar? ¿nos va a alcanzar?
  • Rentabilidad. ¿estamos ganando lo que queríamos? ¿estamos perdiendo? ¿cuánto estamos ganando o perdiendo? ¿cuánto vamos a ganar o perder si seguimos así?
  • Riesgos. ¿Cuáles son los principales riesgos? ¿qué vamos a hacer para eliminarlos?
  • Problemas. ¿Cuáles son las situaciones problemáticas actuales? ¿Qué se está haciendo para resolverlas?
  • Calidad. ¿Se está obteniendo el producto que el cliente quiere y necesita? ¿cuántos defectos tenemos? ¿cuáles son los principales defectos? ¿se están cumpliendo los estándares? ¿el cliente está quedando satisfecho con los resultados?
  • Recursos Humanos. ¿Tenemos a la gente adecuada? ¿contamos con los suficientes recursos? ¿hay recursos problemáticos?
  • Recursos Materiales. ¿Tenemos lo necesario para trabajar?

Toma de decisiones

Si consigues mantenerte informado oportunamente de lo que ocurre con el proyecto ¡felicidades! llevas la mitad del camino recorrido para realizar un buen seguimiento.  Pero, no te confíes, no por tener esta información significa que saldrás airoso en el proyecto.  Para lograrlo, además requieres tomar buenas y oportunas decisiones.  Es con esas decisiones donde se decide el temple y la efectividad del líder.

El liderazgo y la toma de decisiones

El seguimiento es otra oportunidad para demostrar el verdadero liderazgo de la persona que administra el proyecto.  Y es que una vez obtenida la información precisa con respecto al estado del proyecto y habiendo identificado desviaciones contra lo planeado, lo que se requiere es TOMAR DECISIONES para corregir dichas desviaciones.

El líder de proyecto debe analizar la situación, identificar las causas por las cuales el proyecto se enfrenta a una desviación o situación problemática y plantear o buscar soluciones para resolverlo antes de que siga ocasionando más desviaciones, retrasos o problemas.

Aquí de lo que se trata es de actuar, ¡y rápido!  Recuerda que el tiempo es oro, y entre más tardes en resolver las causas de los problemas las desviaciones seguirán aumentando y por lo tanto el éxito del proyecto se irá alejando cada vez más de tu vista.

Si no actúas rápido el proyecto se retrasará más de lo que ya está, costará más de lo que ya está costando, y tu cliente pensará dos veces antes de volver a contratarte.

Analiza y elimina las causas de las desviaciones

Recuerda analizar con cuidado y buscar las causas reales por las cuales el proyecto se está desviando de su rumbo y entonces elimina dichas causas lo antes posible.

Como ejemplo, uno de los integrantes de tu equipo puede estar retrasándose porque:

  • no tiene la información suficiente para trabajar (¡proporciónasela!)
  • no entiende lo que se le está pidiendo (¡infórmaselo!)
  • no sabe lo que se espera de él (¡díselo!)
  • no se le han dado las instrucciones correctamente (¡instrúyelo!)
  • no se le ha transmitido adecuadamente el plan (¡transmíteselo!)
  • no se le asignan suficientes actividades  (¡asígnaselas!)
  • no comprende su lugar en el proyecto (¡explícale!)
  • no cuenta con los recursos y herramientas necesarias (¡consígueselas!)
  • no tiene las habilidades requeridas (¡capacítalo… o cámbialo!)
  • no tiene una buena actitud o no está suficientemente interesado (¡habla con él y si no lo corrige reemplázalo!)
  • no está suficientemente motivado  (¡motívalo!)
  • está sobreexplotado y cada vez rinde menos  (¡mándalo a descansar un tiempo!)
  • no está trabajando en suficiente colaboración con el equipo  (¡intégralo!)

Asumiendo responsabilidades

Uno, como líder del proyecto, es responsable de identificar correctamente las causas y tener la suficiente madurez para asumir la responsabilidad de sus propias acciones.  En muchas de las ocasiones los recursos, por más buenos que sean, no reciben por parte del líder de proyecto todo lo que necesitan para poder desempeñar adecuadamente su trabajo.

Puede sonar un poco agresivo, pero piénsalo dos veces antes de regañar (o castigar, penalizar, despedir, etc.) a un recurso por no hacer su trabajo adecuadamente, pues podría ser que quien no está haciendo su trabajo adecuadamente seas tú mismo; el líder de proyecto.

Recuerda que un carro de carreras sin alguien que lo maneje eficientemente nunca va a ganar una carrera, y tú eres quien maneja este carro, si no tomas buenas decisiones en la pista, por más bueno que sea el motor, las llantas y el resto de la maquinaria, nunca tendrás una carrera exitosa. Por más bueno que sea tu equipo, si no lo administras y lideras adecuadamente no podrás llevarlos a un proyecto exitoso.

Recuerda que ser líder (administrador, gerente o director) de proyectos no consiste en sentarse en un trono esperando a que sus súbditos cumplan con su trabajo y de vez en cuando le rindan homenaje.  Ser líder de proyecto significa que tienes que trabajar muy duro, y sobre todo muy inteligentemente para tomar decisiones adecuadas en los momentos más oportunos.

Ser un líder de proyecto requiere ciertas habilidades, pero también conocimiento formal.  Por lo tanto no dudes en invertir en tu preparación. Una buena capacitación será la que te garantice el éxito en tu carrera como administrador de proyectos.  Cada vez son más las empresas que deciden dejar de tomar tantos riesgos y contratar líderes de proyecto con preparación formal.  Así que búscate un buen curso, asesoría o libro y prepárate para tener una carrera exitosa como líder de proyecto.  Sitios como liderdeproyecto.com son una excelente fuente para encontrar opciones al respecto.

Gestión de Riesgos del Proyecto

  • admin 

1.- Principios básicos de la gestión de riesgos

El riesgo procede de las incertidumbres que están presentes en el proyecto, que
pueden ser: conocidos (si han sido identificados, evaluados, y cuantificados y
para los que hemos elaborado un plan de actuación) o desconocidos (si no han
sido identificados o son imposibles de predecir).

Los riesgos forman parte integral de las actividades de todo proyecto y están
influenciados por numerosos aspectos específicos, tales como: la necesidad de
sobrepasar unos niveles exigentes de productividad, alcanzar unos productos que
sobrepasen las características estándar, la novedad de un diseño a desarrollar,
condiciones externas excepcionales, incluir elementos de elevados coste, etc.

Las reglas aplicables para la gestión de riesgos en el proyecto proceden de las
lecciones aprendidas en los proyectos precedentes, de los que deriva una
experiencia relativa a los problemas presentados, los efectos originados por
tales problemas y las diferentes estrategias que se emplearon para eliminar los
efectos indeseados.

El objetivo de la gestión de riesgos es mantener todos ellos dentro de los
límites definidos y aceptados en el desarrollo del proyecto.

La gestión de riesgos es parte integral de la gestión de proyectos y debe
constituirse en parte central del entendimiento del proyecto por el Gerente de
Proyecto. La gestión de riesgos es una parte importante en la toma de
decisiones.

2.- Procesos relacionados con la gestión de riesgos

 

Se precisa aplicar seis procesos para la gestión de riesgos en el proyecto.
Estos procesos se presentan someramente en la figura 10.1, y son los siguientes:

9.A Planificación de Riesgos. Definición del tratamiento y procesado de los
riesgos que se va a realizar en el proyecto.

9.B Identificación de Riesgos. Identificación de los que podrían afectar al
proyecto y documentación de las características de los mismos.

9.C Evaluación de Riesgos. Se realiza un análisis cualitativo con objeto de
establecer el grado de prioridad de cada uno de ellos. Un posible retardo en la
terminación del proyecto añade gravedad al riesgo. Esta herramienta permite
realizar modificaciones en la planificación con objeto de reducir o eliminar
algunos de los riesgos encontrados.

9.D Cuantificación de Riesgos. Evaluación cuantificada de cada uno de los
riesgos y las posibles interacciones entre ellos, para determinar los posibles
sucesos postulables.

9.E Definición de Respuestas ante Riesgos. Definición de las respuestas posibles
a las oportunidades y a las amenazas identificadas.

9.F Vigilancia y Control de Respuestas ante Riesgos. Gestión de todos los
cambios en los riesgos a lo largo del ciclo de vida del proyecto.


Aunque estos procesos se presentan en esta guía como elementos discretos con interfases bien definidas, en la práctica pueden solaparse e interactuar con otros procesos tal como se índica en el módulo 1.

En determinados proyectos, especialmente en los de pequeño tamaño, algunos de
estos procesos están tan íntimamente ligados que pueden considerarse uno solo.
Se presentan en este manual como procesos independientes, debido a que las
técnicas y herramientas para cada uno de ellos son diferentes.

3.- Plan de gestión de riesgos

Es importante que los procesos de gestión del riesgo sean proporcionales tanto
al riesgo como a la importancia del proyecto para la organización.

El Plan de Gestión de Riesgos puede ser formal e informal, muy detallado o
simplemente esbozado, según las necesidades de cada proyecto. En todo caso, se
debe integrar dentro del Plan del Proyecto del que formará parte.

3.1.- Datos de partida

Los datos de partida para la preparación del Plan de gestión de riesgos son los
siguientes:

Plan del proyecto

En este documento están definidos los objetivos, participantes, tamaño, alcance
y complejidad del proyecto; recursos requeridos, duración prevista del proyecto,
restricciones, suposiciones e hipótesis de partida que condicionan los riesgos
del proyecto.

Experiencia y práctica en ges-tión de riesgos de la organización

Esto incluye las prácticas de decisión habituales de la organización y la
experiencia de proyectos anteriores. En algunos casos se puede disponer de
procedimientos de evaluación, cuantificación y procesado de riesgos.

Definición de funciones y responsabilidades

Reglas predefinidas que regulan las funciones, responsabilidades y niveles de
autoridad de toma de decisiones incluidas en el plan.

Niveles admisibles de tolerancias al Riesgo

Diferentes organizaciones e individuos tienen posturas diversas en lo relativo a
la aceptación de los riesgos del proyecto. Por ello se debe adoptar una política
de aceptación de riesgos definida.

Disponibilidad de datos y sistemas de procesado

Pueden extenderse los procesos de identificación, evaluación, cuantificación y
desarrollo de respuestas si se dispone de datos y sistemas de procesado.

Plantillas para el plan de gestión de riesgos

Es un formato normalizado que se adapta a cada proyecto y que se va mejorando en
base a la experiencia obtenida.

3.2.- Técnicas y herramientas

Las técnicas y herramientas a utilizar en este proceso son las siguientes:

Reuniones de planificación

Su propósito es adaptar el Plan de Gestión de Riesgos al proyecto considerado.
Deberán asistir el director de proyecto, los jefes de proyecto y aquellas
personas del equipo de proyecto que vayan a estar involucradas en el seguimiento
del riesgo y otras actividades de ejecución.

3.3.- Productos

El producto generado en este proceso es el Plan de Gestión de Riesgos, un
documento que incluye cómo se tienen que llevar a cabo los siguientes procesos:

a) Identificación de riesgos.

b) Evaluación de riesgos.

c) Cuantificación de riesgos.

d) Desarrollo de respuestas ante riesgos.

e) Vigilancia y control de riesgos.

El índice de este plan podría ser el siguiente:

Metodología

Los métodos, herramientas y datos a utilizar. Esta información puede cambiar a
lo largo del ciclo de vida del proyecto.

Funciones y responsabilidades

Define las funciones, responsabilidades y niveles de autoridad para la toma de
decisiones de los participantes en el proyecto.

Planificación en el tiempo

Programación de las revisiones a realizar en el plan y fechas de realización a
lo largo del ciclo de vida del proyecto.

Mediciones e interpretación de los resultados de la aplicación del plan

Los métodos de medición e interpretación de los resultados deben ser
proporcionales con el proyecto a ejecutar y establecidos con la antelación
suficiente.

Criterio para la consideración de los riesgos

La consideración de los síntomas que establecen la existencia cierta de un
riesgo y la necesidad de actuar, definiendo quién y en qué manera.

Formatos de informe de riesgo

Describe el formato y contenido del plan de respuestas ante los riesgos. Indica
cómo los resultados de la gestión de riesgos deben ser documentados, analizados
y comunicados al equipo de proyecto, así como partes interesadas propias y
ajenas.

Seguimiento de riesgos

Documentos en los que se recogen todas las circunstancias de los acontecimientos
de riesgo, recomendaciones futuras y lecciones aprendidas.

4.- Identificación de riesgos

Esta identificación es una actividad continua a lo largo del ciclo de vida del
proyecto, y comprende tanto los riesgos de origen interno como externo. Los
riesgos internos son normalmente influenciables y controlables por el equipo de
proyecto, mientras que no suele ser así con los riesgos externos, tales como
decisiones gubernamentales, modificaciones en el cambio de divisas, inflación,
etc.

Se debe ampliar suficientemente el grupo de participantes y no limitarse
solamente al equipo de proyecto. Incluso puede ser recomendable la participación
de consultores externos. Para la revisión final es conveniente usar los
servicios de una persona ajena al proyecto y que no esté influenciada por él.

Aunque estrictamente los riesgos a controlar son aquellos que podrían provocar
daños o pérdidas, dentro del contexto de la gestión de riesgos deben
considerarse también aquellos que proporcionarían oportunidades con resultados
positivos para el proyecto.

La identificación de riesgos puede efectuarse mediante la identificación de las
causas y sus efectos (qué podría suceder y qué consecuencias tendría) o efectos
debidos a ciertas causas (qué consecuencias se tratarían de evitar o promover y
cómo podrían originarse tales consecuencias).

Los riesgos pueden ser caracterizados por sus consecuencias en todos los
aspectos del proyecto. Estas consecuencias pueden ser clasificadas en varias
categorías: pérdida de vidas humanas o daños al personal, pérdida de
funcionalidad del proyecto, agresión al medio ambiente, degradación de los
objetivos del proyecto, incremento de coste, retraso de planificación e
insatisfacción del Cliente.

4.1.- Datos de partida

Los datos de partida para la identificación de riesgos son los siguientes:

Plan de Gestión de Riesgos

Información del Proyecto

La naturaleza del proyecto proporciona la mayor fuente de riesgos. Así, los
proyectos que utilizan una tecnología probada y bien conocida involucran menos
riesgos que aquéllos otros que requieren innovación o invención. Estos riesgos
se describen comúnmente en términos de efectos sobre el coste y plazo.

Los productos obtenidos en los diversos procesos de gestión deben ser revisados
para identificar posibles fuentes de riesgo (por ejemplo: la estructura
desagregada del proyecto puede identificar aproximaciones no tradicionales para
ciertas tareas, que no eran aparentes en documentos de más alto nivel; las
estimaciones de coste y duración pueden identificar valoraciones aventuradas con
la información disponible para su cuantificación; el plan de recursos puede
incluir personas de conocimientos difícilmente reemplazables o comprometidas con
otros proyectos; el plan de gestión de adquisiciones puede proporcionar
oportunidades en función de las circunstancias del mercado, etc.).

Categorías de riesgo

Son las posibles fuentes de riesgo -adecuadamente clasificadas- que pueden
afectar al proyecto positiva o negativamente. Los criterios de clasificación
deben estar adecuadamente definidos y, a ser posible, reflejar las prácticas
habituales en la industria o en otras disciplinas. Una posible clasificación de
las diferentes categorías de riesgo aparece a continuación:

a) Riesgos técnicos, de calidad o de ejecución. Tecnología compleja, sin probar,
objetivos no realistas. Cambios de tecnología o de normas industriales.

b) Riesgos de gestión. Malas estimaciones de tiempo y/o recursos, calidad
inadecuada del plan del proyecto, estimaciones poco realistas, problemas con los
fabricantes, montadores y subcontratistas, comunicaciones inadecuadas,
incapacidad para tomar decisiones.

c) Riesgos externos. Cambios en los requerimientos legales o regulares, cambios
en los mercados, problemas laborales o sociales, mal tiempo, fuerza mayor como
inundaciones, terremotos, etc.

Información histórica

Antecedentes relativos a actividades que fueron precisas en proyectos previos
similares, que se obtienen de los archivos del proyecto, las bases de datos de
gestión o los conocimientos de los miembros del equipo del proyecto.

4.2.- Técnicas y herramientas

Las técnicas y herramientas empleadas en la definición de riesgos son las
siguientes:

4.2.1.- Revisión de la Documentación.

Ejecución de una revisión del plan del proyecto y las hipótesis y supuestos
adoptados en los procesos de planificación del proyecto.

4.2.2.- Técnicas de aportación de documentación de riesgos

Citaremos las siguientes:

a) Tormenta de ideas (Brainstorming). Reunión multidisciplinar de expertos en el
que se definen posibles riesgos, se hace una crítica de las aportaciones de unos
y otros y se obtiene una lista clasificada de riesgos a considerar en el
proyecto.

b) Técnica Delphi. Parecida a la anterior, pero preparada de forma más privada,
tiende a evitar las influencia predominante de alguna de las personas
asistentes.

c) Entrevistas. Realización de conversaciones orientadas a la identificación de
riesgos correspondientes a los estudios de factibilidad, petición de ofertas y
negociación del contrato.

d) Lista de Comprobación. Utilización de listas normalizadas organizadas por
fuentes de riesgos, incluyendo fuentes debidas al contexto de desarrollo del
proyecto, las tecnologías a emplear, el tamaño del proyecto, etc.

Identificación de Riesgos del proyecto Página: 1 de N

Proyecto: Código:

Cliente:

Director de proyecto Fecha:

Agente Tipo Riesgo NA, SI, NO, DESC Acción

Ambiental Tiempo atmosférico Posibles condiciones meteorológicas adversas

Servicio público Necesidad de mantener servicio durante obras

Restos arqueológicos

Partes interesadas Expropiaciones Expropiaciones con muchos propietarios

Grupos de presión Posibles grupos de presión externos harán oposición al
proyecto

Clientes Política de la dirección El cliente no tiene una organización orientada
a proyectos.

Experiencia en Dirección Proyecto El personal no tiene experiencia en Dirección
de proyecto.

Compromiso El cliente puede no estar muy comprometido en el proyecto

Etc.

Etc. Etc.

e) Análisis de hipótesis y supuestos. Todos los proyectos se desarrollan
adoptando determinadas hipótesis, escenarios y suposiciones. La técnica,
consistente en una revisión a fondo de estos supuestos, permite identificar
riesgos potenciales debido a inconsistencias, inexactitudes o insuficiencias o
simplemente posible incumplimiento. El producto final de esta revisión es:

Un listado de las hipótesis, escenarios y suposiciones adoptadas en el proyecto.
Estas suposiciones pueden ser explicitas o implícitas y residir en diferentes
documentos. Una lista de posibles suposiciones alternativas a las del listado
anterior.

f) Fuerzas, debilidades oportunidades y amenazas (Análisis FODA o DAFO). Una
revisión de todas estas circunstancias, con objeto de mejorar la perspectiva de
los riesgos.

g) Diagramación. Utilización de algún tipo de diagrama que muestre como
interactúan varios elementos de un sistema y sus consecuencias. Son ejemplos de
este tipo de herramientas los diagramas causa-efecto, también denominados
Ishikawa o diagramas de espina de pez; los diagramas de proceso de sistemas y
los especiales, mostrando influencias causales entre distintos acontecimientos
en el que se incluye una ordenación de los acontecimientos en el tiempo y otras
posibles relaciones entre ellos.

4.3.- Productos

Los productos a obtener de la definición de riesgos son:

Fuentes de Riesgo

Deben incluir todas las fuentes posibles, sin considerar su frecuencia de
presentación, la probabilidad de ocurrencia o magnitud del efecto original.
Estas fuentes de riesgo incluyen –comúnmente- los cambios en requisitos, errores
u omisiones en el diseño, malos entendidos, insuficiente definición o
entendimiento de las responsabilidades, malas estimaciones de recursos, personal
con cualificación inadecuada, etc.

La descripción de las fuentes de riesgo deben incluir:

a) La probabilidad de que se presente un Suceso de Riesgo procedente de esa
fuente.

b) El rango de sucesos posibles.

c) Su posible ocurrencia en el tiempo.

d) La frecuencia esperada de presentación de Sucesos de Riesgo procedentes de
tal fuente.

Identificación de Sucesos de Riesgo

Deben ser ocurrencias discretas, tales como desastres naturales, pérdida de
personal clave en el proyecto, etc.

Síntomas de Riesgo

Son también designados como signos de alarma, a guisa de indicaciones respecto a
que un Riesgo se ha producido o se está produciendo (por ejemplo: fallo en el
cumplimiento de hitos intermedios en la planificación que, si se corrigen,
conducirán a un retraso en la fecha de terminación del proyecto.

Datos de Partida para otros Procesos

La identificación de riesgos puede ocasionar modificaciones en otras áreas. Por
ejemplo, posible identificación de refinamientos, identificaciones de
entregables no considerados o clarificación o modificación del contenido de las
descripciones de algunos entregables, modificación del sistema de desagregación
del proyecto, etc.

5.- Definición Cualitativa de Riesgos

Es este un proceso en el que se procede a realizar una evaluación de los Riesgos
identificados en el proceso anterior de forma cualitativa. Se intenta con ello
hacer una lista por orden de la importancia de su efecto potencial para el
proyecto. Esta lista debe incluir todos los riesgos a considerar en el plan.

Durante la preparación de esta información se deberá tener en cuenta la calidad
de la información disponible.

Este estudio deberá repetirse a lo largo del ciclo de vida del proyecto para
analizar la evolución del riesgo con el transcurso del tiempo.

5.1.- Datos de partida

Los datos de partida usados para la evaluación del riesgo son las siguientes:

Plan de gestión de Riesgos

Identificación de Sucesos de Riesgo

Muchos de los posibles riesgos asociados al proyecto son desconocidos, porque el
diseño del proyecto no esta aún maduro y es posible que se requieran cambios.
Es, por tanto, fácil que aparezcan nuevos riesgos.

Tipo de proyecto

Los proyectos repetitivos o de tipo común suelen presentar menos riesgos que
aquellos complejos y de tecnología muy avanzada.

Precisión y seguridad en los datos

La precisión en los datos permite una mayor seguridad en la evaluación de los
riesgos. Debe documentarse la fuente usada para la evaluación del riesgo.

5.2.- Técnicas y herramientas

Las técnicas y herramientas empleadas en la definición de riesgos son las
siguientes:

5.2.1.- Probabilidad e impacto del riesgo

Estas variables pueden definirse cualitativamente como: catastrófica, muy alta,
moderada, baja, muy baja. La Probabilidad define las posibilidades de aparición
del riesgo. El Impacto define la importancia para el proyecto de la presentación
del riesgo. Estas dos dimensiones del riesgo son aplicables a todos ellos. La
consideración de ambas variables permite separar los riesgos que requieren un
tratamiento especial de aquellos que pueden ser procesados por el equipo del
proyecto.

5.2.2.- Matriz probabilidad / impacto para definir el riesgo.

Se puede construir una matriz para asignar el nivel teniendo en cuenta ambas
variables: probabilidad e impacto. Riesgos de alta probabilidad e impacto deben
ser analizados incluso cuantitativamente y tratados con una política agresiva.

El riesgo es definido situándolo en la matriz fijando su posición, haciendo uso
de las escalas de probabilidad 0,1/0,3/0,5/0,7/0,9, desde raro hasta casi
cierto, y las de impacto que se muestran en la tabla adjunta.

Impacto de riesgos sobre los objetivos del proyecto

Evaluando el impacto de riesgo sobre los objetivos del proyecto (escala no
lineal)

Objetivo del proyecto Muy bajo 0,05 Bajo

0,1 Moderado

0,2 Alto

0,4 Muy alto

0,8

Coste

Aumento de coste no significativo

Aumento de coste menor del 5%

Aumento de coste entre 5-10%

Aumento de coste entre 10 y 20 %

Aumento de coste mayor del 20%

Duración

Deslizamiento insignificante

Deslizamiento menor del 5%

Deslizamiento entre 5-10%

Deslizamiento entre 10-20%

Deslizamiento mayor 20%

Funcionalidad

Decrecimiento funcionalidad casi no perceptible

Áreas menores de funcionalidad afectadas

Áreas mayores de funcionalidad afectadas

Reducción de funcionalidad no aceptable para cliente

Producto final no es utilizable

Calidad

Degradación calidad casi no perceptible

Solamente afectadas aplicaciones exigentes

Reducción de calidad necesaria aprobación del cliente

Reducción de calidad inaceptable para el cliente

Producto final no es utilizable

La multiplicación de la probabilidad y el impacto es el sistema más común de
combinar ambas variables: Nivel de riesgo = probabilidad  impacto.

A continuación se muestra la matriz combinatoria de las probabilidades e
impactos obtenida por estos procedimientos. Las distintas casillas se colorean
indicando los distintos niveles de riesgo asignables.

Medición de riesgos combinando Probabilidad e Impacto

Probabilidad Medida de riesgo = P  I

0.9 0.05 0.09

0.7 0.07 0.14

0.5 0.05 0.10

0.3 0.06 0.12

0.1 0.08

0.05 0.1 0.2 0.4 0.8

Impacto (escala utilizada)

5.2.3.- Tendencia de aparición del riesgo

A lo largo de la duración del proyecto puede aumentar o disminuir la
probabilidad y/o impacto del riesgo, haciendo mayor o menor su consideración por
el equipo del proyecto.

5.2.4.- Ensayo de suposiciones

Las suposiciones del proyecto se comprueban de acuerdo con los criterios
siguientes:

a) Su estabilidad. No ha hecho falta modificarlas a lo largo del proyecto.

b) Impacto sobre el proyecto si la suposición no se cumple.

c) Suposiciones alternativas pueden ser evaluadas incluyendo su impacto en los
riesgos del proyecto.

5.2.5.- Rango de precisión de los datos

Se evaluará el grado de precisión de los datos usados para la gestión de Riesgos
destacando los siguientes aspectos:

a) Grado de conocimiento del riesgo.

b) Disponibilidad de datos sobre el riesgo.

c) Calidad de los datos.

d) Fiabilidad de los datos.

e) La calidad de las estimaciones son función de la calidad de los datos.

5.3.- Productos

Los productos a obtener de la definición de riesgos son:

Rango de riesgo global para el proyecto

El análisis del nivel de riesgo global del proyecto, en comparación con otros,
permite reajustar los recursos humanos para reforzar los proyectos con más
riesgo o, incluso, crear un grupo de seguimiento de los riesgos que caen en la
zona roja en base a una consideración coste-beneficio. Incluso podría ser
necesaria una recomendación de cancelación del proyecto si los riesgos del
proyecto no son asumibles.

Listado de riesgos por niveles

Los riesgos reconocidos pueden ser incluidos en un listado con indicación de sus
características. De esta manera se pueden diferenciar los que requieren una
acción inmediata de aquellos que pueden esperar.

Los riesgos que afectan al coste, duración, funcionalidad o calidad del
proyecto, pueden ser tenidos en cuenta separadamente.

Listado de riesgos para análisis adicionales y gestión

Los riesgos clasificados como altos y moderados son los candidatos para su
cuantificación y estudio de respuestas especificas.

6.- Cuantificación de riesgos

Con este proceso se calcula la medida de la probabilidad de que se manifiesten
los riesgos, estudiando su impacto sobre los objetivos del proyecto.

La cuantificación de los riesgos permite al gerente del proyecto tomar aquellas
decisiones que le permitan enfrentarse eficazmente con la incertidumbre.

Las técnicas de cuantificación hacen uso de disciplinas como la simulación de
Montecarlo y los análisis de toma de decisiones, para conseguir los objetivos
siguientes:

a) Determinar la probabilidad de no alcanzar uno de los objetivos del proyecto.

b) Cuantificar la exposición al riesgo, para determinar el volumen de
contingencias en costes y tiempo a incluir en el proyecto, para hacer frente al
riesgo.

c) Identificar los riesgos que requieren una mayor atención por medio del
conocimiento de cuales son sus aportaciones numéricas al riesgo global del
proyecto.

d) Mejorar el plan del proyecto usando estimaciones más realistas para la
preparación de la planificación, estimación del coste y análisis del alcance.

La cuantificación de riesgos se hace normalmente a continuación de su
evaluación, pudiendo realizarse separada o simultáneamente. Se suele tener en
cuenta, para esta decisión, el tiempo disponible y los recursos previstos para
el trabajo.

Por último, deben tenerse en cuenta las interacciones entre riesgos, para
determinar el rango de posibles efectos sobre el proyecto.

Principalmente, debe determinarse cuáles de estos riesgos requieren respuestas,
lo que resulta compleja debido a diversos factores, entre los que destacan:
dificultad de anticipar las interacciones (por ejemplo: un retraso en el
programa puede obligarte a considerar una nueva estrategia para recuperar tal
retraso); algunos sucesos de riesgo pueden causar varios efectos (por ejemplo:
un retraso en el suministro de un componente clave puede provocar desviaciones
en los costes, retrasos en el programa, penalizaciones, etc.); ciertas
oportunidades para un participante pueden inducir amenazas en otro (por ejemplo:
una reducción en ciertos costes pueden inducir pérdidas de beneficio a otro
participante); y el uso de herramientas matemáticas puede crear una falsa
impresión de precisión y fiabilidad.

6.1.- Datos de partida

Los datos de partida para la cuantificación de riesgos son los siguientes:

Plan de Riesgos

Listado de riesgos clasificados y evaluados cualitativamente

Obtenidos del proceso anterior.

Información histórica

Antecedentes relativos a actividades que fueron precisas en proyectos previos
similares, obtenibles de los archivos de proyecto, las bases de datos de gestión
o los conocimientos de los miembros del equipo del proyecto.

Juicio de expertos

La información puede proceder del equipo del proyecto, otros especialistas en
riesgos asignados temporalmente al proyecto o expertos ajenos a la organización.

Otras informaciones de las actividades de planificación

Son informaciones útiles procedentes del sistema de desagregación del proyecto,
estimaciones de duración de actividades pertenecientes al camino crítico o con
escasa holgura, presupuesto del proyecto con indicación del volumen de recursos,
sus costes postulados y los objetivos técnicos del proyecto.

6.2.- Técnicas y herramientas

Las técnicas y herramientas empleadas en la cuantificación de riesgos son las
siguientes:

Entrevistas

El mantenimiento de entrevistas efectuadas con los participantes en el proyecto
y otros posibles expertos en riesgos puede ser el primer paso para cuantificar
los riesgos del proyecto. Las necesidades de información incluyen la definición
de los intervalos de los valores de probabilidad a tener en cuenta para algunos
de los riesgos (optimista, pesimista, más probable), y la distribución de
probabilidad esperada para los mismos.

La distribuciones más comunes para los parámetros estadísticos aplicables a los
riesgos son: uniforme, normal, beta, triangular, lógico normal, etc.

Es importante documentar la información utilizada para poder evaluar mejor el
proceso de desarrollo de respuestas ante riesgos.

Análisis de sensibilidad

El análisis de sensibilidad permite analizar uno a uno los distintos riesgos que
comprometen los objetivos del proyecto y conocer su influencia, manteniendo los
restantes riesgos constantes, para así diferenciar unos de otros en sus efectos.
Una vez completado este análisis será posible clasificar los riesgos por un
impacto en el proyecto.

Análisis de decisión

Se representan las interacciones clave entre decisiones y riesgos asociados,
incluyendo para cada decisión sus efectos favorables o desfavorables, teniendo
en cuenta también sus probabilidades de ocurrencia (por ejemplo: determinar los
riesgos inducidos por una planificación agresiva frente a otra conservadora,
asociando probabilidades y determinando el valor monetario esperado en cada rama
del árbol de decisiones). La resolución del árbol de decisiones nos conducirá a
la adopción de aquellas acciones que permiten obtener los mejores resultados en
la gestión del proyecto.

Simulación

Implica el cálculo de diversas alternativas de ejecución del proyecto, en
función de varias hipótesis y su tratamiento estadístico (por ejemplo, mediante
un análisis de Monte Carlo). Se obtienen diferentes escenarios de coste y
duración del proyecto, que pueden ser utilizados en la cuantificación del riesgo
que suponen diversas estrategias de desarrollo, alternativas de programación,
secuenciamiento de actividades o actividades individuales.

6.3.- Productos

Los productos a obtener de la cuantificación de riesgos son:

Lista de riesgos clasificada por orden de importancia

Recoge un listado clasificado de riesgos que constituyen oportunidades y
amenazas para la consecución de los objetivos del proyecto. Se incluye también
la medida de sus impactos sobre el proyecto.

Análisis probabilístico del proyecto

Presenta un escenario de una planificación y presupuesto probabilísticos
listando las posibles duraciones y costes del proyecto con sus correspondientes
niveles de confianza.

Probabilidad de exceder el presupuesto y duración del proyecto

Cuando se completa el estudio de cuantificación del riesgo, se puede definir la
probabilidad de que se afecte la duración y el coste del proyecto, o el
mantenimiento del plan del proyecto actual, y si esto es aceptable.

Por otro lado, se puede preparar un documento: Oportunidades a Ignorar/Amenazas
Aceptables. Es este un documento en el que se deja constancia de tanto de las
fuentes de riesgo como de los sucesos de riesgo que conscientemente se han
decidido aceptar o ignorar, y quién tomó tal decisión.

Consideración de contingencias

La cuantificación permite determinar la cantidad de reserva o contingencia
necesaria para reducir el riesgo de que se produzcan sobrecostes o retrasos
dentro de unos niveles aceptables para organización.

7.- Desarrollo de respuestas ante riesgos

Comprende la determinación de los pasos requeridos para tratar de materializar
las oportunidades y así responder a las amenazas mediante eliminación (por
ejemplo, algunos riesgos pueden ser eliminados suprimiendo su causa raíz),
mitigación (por ejemplo, el valor monetario esperado puede ser mejorado
reduciendo la probabilidad de ocurrencia del suceso mediante utilización de
técnicas más seguras o cubriendo parte del mismo mediante un seguro) o
aceptación (por ejemplo, aceptar las consecuencias previsibles en su totalidad,
reduciendo el margen económico esperado y desarrollando planes de contingencia a
ejecutar si el riesgo llegara a materializarse).

El plan de respuestas a los riesgos debe ser realista en el contexto del
proyecto, apropiado a la severidad del riesgo esperado, con un coste efectivo y
oportuno en el tiempo para conseguir sus fines, pudiendo presentar varias
alternativas para tener en cuenta circunstancias especiales.

7.1.- Datos de partida

Los datos de partida para el desarrollo de respuestas ante riesgos son los
siguientes:

Plan de Riesgos

Lista de riesgos clasificadas por orden de importancia

Recoge un listado clasificado de riesgos que constituyen oportunidades y
amenazas para la consecución de los objetivos del proyecto. Se incluye también
la medida de sus impactos sobre el proyecto.

Listado de respuestas potenciales

Durante los estudios cuantitativos de riesgos las respuestas necesarias para
combatirlos son identificadas y clasificadas.

Niveles de riesgos que se consideran aceptables

Estos riesgos, que se consideran aceptables en la organización, no requieren un
tratamiento específico.

Responsables de las actuaciones

Se preparará una lista con los nombres de las personas encargadas de actuar
-cuando sea necesario- al producirse la aparición de un riesgo. Estas personas
serán -en lo posible- las que participaron en el estudio de las respuestas.

Respuesta a riesgos comunes

Algunos riesgos pueden ser iniciados por una causa común. Esta situación puede
revelar la oportunidad de mitigar más de un riesgo con una respuesta genérica.

7.2.- Técnicas y herramientas

Las técnicas y herramientas empleadas en el desarrollo de respuestas ante
riesgos son las siguientes:

Supresión del riesgo

Esta técnica consiste en realizar aquellos cambios en el plan del proyecto para
eliminar el riesgo o sus consecuencias negativas sobre los objetivos del
proyecto. No es posible eliminar todos los riesgos, pero algunos pueden ser
evitados.

Algunos riesgos que aparecen pronto en el desarrollo del proyecto pueden ser
evitados en base a una mejor definición de objetivos, la obtención de
información adicional, mejorando las comunicaciones, adquiriendo el apoyo de
expertos, reduciendo el alcance para evitar realizar actividades de alto riesgo,
añadiendo recursos adicionales o modificando la planificación. También se pueden
usar soluciones probadas en lugar de innovaciones, usar un contratista conocido
en lugar de un nuevo, etc.

Transferencia de riesgos

Esta técnica consiste en trasladar el riesgo a otra organización, que toma la
responsabilidad de su gestión. La transferencia no anula el riesgo, sino
simplemente transfiere a otro la responsabilidad de su gestión.

Esta actuación es efectiva para resolver situaciones de riesgo financiero. La
transferencia del riesgo suele tener como consecuencia el pago de una cantidad
que compensa al nuevo responsable del riesgo asumido.

Las formas de llevar a cabo esta transferencia son contratos de seguros,
primas-penalidades de cumplimiento, etc. Otra forma muy usada es la
transferencia de riesgos a través de los contratos. Un contrato “precio fijo”
con un suministrador transfiere a este una parte importante de los riesgos,
siempre que el suministro permanezca estable.

Mitigación del riesgo

La mitigación trata de reducir la probabilidad y/o el impacto de un riesgo por
debajo de un nivel que sea aceptable.

La adopción de acciones -en una fase temprana- para prevenir el riesgo suele ser
más efectiva que tratar de reparar las consecuencias después de haberse
producido. El coste de la mitigación de un riesgo debe ser proporcional respecto
a la probabilidad e impacto postulado para el mismo.

Las formas de mitigación del riesgo pueden ser las siguientes:

a) Adoptar un proceso más simple.

b) Llevar a cabo ensayos adicionales.

c) Elegir un suministrador más estable.

d) Añadir recursos o tiempo adicional.

e) Construir un prototipo en una escala intermedia.

Aceptación del riesgo

Esta técnica indica que el equipo del proyecto ha decidido no cambiar el plan
del proyecto para hacer frente a la amenaza del riesgo, o no ha sido capaz de
encontrar una estrategia alternativa. Una aceptación activa del riesgo puede
implicar la adopción de un plan de contingencia para ejecutar en el caso de que
el riesgo se produzca. Una aceptación pasiva no requiere acciones especiales:
cuando ocurra, el riesgo será procesado por el equipo del proyecto.

Un plan de contingencia es útil para aquellos riesgos que puedan aparecer a lo
largo del desarrollo del proyecto. Para su activación se deberán tener en cuenta
la presencia de los síntomas que nos indiquen la aparición del riesgo con
suficiente antelación. La insistencia en continuar con la planificación original
del proyecto que está fallando claramente, lleva el plan de contingencia al
fracaso.

En ocasiones puede disponerse de un segundo plan de reserva a aplicar, en el
caso de que el plan de emergencia haya fallado al ocurrir el riesgo.

7.3.- Productos

Los productos a obtener del desarrollo de respuestas ante riesgos son:

Plan de Respuestas ante Riesgos

Documenta los procedimientos de gestión de riesgos adoptados en el proyecto,
incluyendo la identificación, evaluación y cuantificación de riesgos, las
respuestas específicas previstas, la definición de responsables de gestión de
las diversas áreas de riesgo, las responsabilidades de actualización, la
implantación de planes de contingencia y el modo de distribución de las reservas
(contingencias).

Riesgos residuales

Son aquellos, generalmente pequeños, que aparecen después de que se hayan tomado
las acciones de supresión, transferencia y mitigación previstas. También se
incluyen aquí riesgos menores que han sido aceptados e identificados,
generalmente con cargo a la contingencia.

Riesgos secundarios

Son los riesgos que aparecen como consecuencia de la aplicación de medidas de
respuesta a la aparición de riesgos. Estos riesgos secundarios deben ser
identificados y su respuesta debe ser analizada de la misma manera que los
riesgos primarios.

Acuerdos contractuales

Se pueden incluir en los contratos las conspiraciones oportunas sobre la
responsabilidad de las partes en caso de riesgos específicos, así como la
consideración de los seguros a contratar para aquellas circunstancias que puedan
paliar las consecuencias de los acontecimientos de riesgos.

Datos de Partida para Otros Procesos

Las alternativas seleccionadas o sugeridas, los planes de contingencia, las
adquisiciones de recursos externos y otros productos del análisis de riesgos
deben ser considerados en los diversos procesos afectados. Generalmente todas
las actuaciones previstas para establecer las respuestas ante riesgos
representan mayores gastos, que deben ser autorizados en base al dinero ahorrado
en el caso de que se produzcan los riesgos postulados.

8.- Vigilancia y control de respuestas ante el Riesgo

Este proceso va registrando los riesgos identificados, separando riesgos
residuales y emergentes, asegurando la ejecución de planes de riesgo y evaluando
su efectividad. Comprende el seguimiento del Plan de Gestión de Riesgos a lo
largo del ciclo de vida del proyecto, dato que resulta imposible sin la
identificación de todos los riesgos y probabilidades mediante análisis; por
ello, resulta imprescindible una actualización y control continúo. Este proceso
está integrado en el sistema general de control del proyecto.

Una buena vigilancia y control de los procesos de riesgo suministra información
que asiste a la toma de decisiones con antelación a la aparición del riesgo. Por
tanto es necesaria una buena comunicación con las partes interesadas en el
proyecto, para comprobar periódicamente los niveles de riesgo del mismo.

Una buena vigilancia y control de riesgos toma en consideración los puntos
siguientes:

a) La vigilancia de los riesgos ha sido adoptada, tal y como se había
planificado.

b) Las respuestas ante riesgos han sido tan efectivas como se pensaba o deben
sustituirse por otras en el futuro.

c) La exposición al riesgo ha cambiado desde el último análisis efectuado.

d) Se han manifestado síntomas de la aparición de riesgos.

e) Se están siguiendo las políticas de riesgos y los procedimientos adecuados.

f) Han ocurrido riesgos que no habían sido considerados inicialmente.

El control de riesgos puede adoptar diferentes estrategias, desarrollar un plan
de contingencias, tomar acciones correctoras o replanificar el proyecto entero.
El director del plan de control de riesgos deberá mantenerse en contacto con el
director del proyecto para informarle de los incidentes que se vayan produciendo
en la administración del plan y proponer aquellos cambios que sean pertinentes.

8.1.- Datos de partida

Los datos de partida para el control de respuestas ante el riesgo son los
siguientes:

Plan de Gestión de Riesgos

Plan de Respuesta ante Riesgos

Comunicaciones del Proyecto

Las informaciones que se recogen en los informes periódicos de la situación del
proyecto son importantes para facilitar el desarrollo del proceso de vigilancia
y control de riesgos.

Identificación de Riesgos Adicionales y su Análisis

Durante el ciclo de vida del proyecto pueden identificarse sucesos de riesgo no
considerados previamente. El ciclo completo de identificación, evaluación,
cuantificación y desarrollo de respuestas debe ser aplicado a estos nuevos
riesgos. Estas consideraciones son, asimismo, aplicables a sucesos de Riesgos
Reales, que son aquellos sucesos de riesgo para los que se deben implantar las
acciones reales, necesarias a corto plazo a fin de mitigar sus efectos.

Auditorías de proyecto

Durante las auditorías de proyecto se puede dedicar una parte de las mismas a
evaluar el cumplimiento de los procesos aquí descritos y a verificar su
efectividad. Estas auditorías, durante del proyecto, son útiles para controlar
mejor el riesgo.

8.2.- Técnicas y herramientas

Las técnicas y herramientas empleadas en el control de respuestas ante el riesgo
son las siguientes:

Listas de comprobación

Las listas de comprobación usadas para la identificación y cuantificación de los
riesgos pueden ser usadas también para la vigilancia y control de la aparición
de riesgos. Debe vigilarse su aplicabilidad al proyecto.

Revisiones periódicas de los riesgos del proyecto

Se deben planificar revisiones periódicas de riesgos. Las reuniones deberán se
reparadas cuidadosamente en base a una agenda previamente establecida. La
clasificación de los riesgos puede variar a lo largo del ciclo de vida del
proyecto. Los cambios a realizar deben ser evaluados y cuantificados.

Análisis del avance del proyecto utilizando los valores producidos

Esta técnica, explicada detalladamente en el módulo 4, permite conocer en forma
estimada las desviaciones en tiempo y coste del proyecto. Esta información
destaca las desviaciones importantes que se vayan produciendo a lo largo del
desarrollo del mismo.

Estas desviaciones, al deteriorar la marcha del proyecto hacen recomendable una
actualización de los procesos de identificación, verificación y cuantificación
de riesgos.

Respuestas adicionales

En los casos en los que aparece un riesgo que no había sido considerado con
anterioridad, o si su impacto es mayor de lo esperado, se deberá realizar un
nuevo estudio del plan de respuesta al riesgo.

Análisis de riesgo independiente

Puede representar una ventaja encargar los estudios de riesgo a un grupo
independiente interno o externo, con objeto de conseguir un tratamiento más
independiente y menos sesgado, por la implicación más directa en el proyecto del
equipo.

8.3.- Productos

Los productos a obtener del control de respuestas ante el riesgo son:

Medidas de Emergencia (Workarounds)

Son repuestas sin planificar a sucesos de riesgo repentinos. Estas respuestas
deben ser documentadas e integradas en los planes de gestión de riesgos y de
respuestas ante riesgos.

Acciones Correctoras

Consisten principalmente en la implantación de medidas de emergencia (Workarounds)
o la aplicación de los planes de contingencia planificados.

Solicitudes de cambio en el proyecto

Como consecuencia de la implementación de los planes de emergencia (y
workarounds) se producen solicitudes de cambio en el proyecto, que se deberán
procesar de la misma manera que los ocasionados por otras causas y por los
mismos procedimientos.

Actualizaciones del Plan de Gestión de Riesgos

A lo largo del ciclo de vida del proyecto ciertos riesgos se materializan, otros
dejan de existir y nuevos riesgos pueden aparecer. También las probabilidades y
valoraciones efectuadas pueden sufrir alteraciones. Por ello debe mantenerse
actualizado el Plan de Gestión de Riesgos.

Informes de riesgo normalizaos

El uso de formatos normalizados elimina muchas de las discrepancias que pueden
aparecer en los estudios del riesgo en proyectos distintos dentro de la misma
organización.

Los riesgos que son similares en proyectos distintos deben ser procesados en
base a un tratamiento común.

El uso de formatos y procedimientos comunes ayudan a extraer toda la información
procedente de las lecciones aprendidas en un proyecto para su uso en los futuros
proyectos, consiguiéndose así una mejora continuada a lo largo del tiempo.

Los informes de riesgo del proyecto pueden entonces ser distribuidos dentro de
la organización, que se beneficiará más de su contenido si ya se conocen los
formatos y como se utilizan.

9.- Estudio de una metodología de evaluación de riesgos

Los riesgos forman parte de cualquier proyecto y son específicos en cada área de
actividad. Con carácter general pueden ser debidos a su alto coste, a plazos
restringidos, al uso de tecnologías no probadas, a cuestiones medioambientales,
a grandes exigencias de comportamiento de los productos, a cuestiones
relacionadas con la seguridad, a la externalización de ciertas actividades, al
elevado número de participantes, etc.

Las consecuencias de los riesgos pueden ser muy variadas, desde la obtención de
productos que no cumplen las expectativas, incrementos de costes, retrasos en la
ejecución, fracaso del proyecto, daños a las personas y propiedades, impactos
ambientales negativos superiores a lo esperado, etc.

El objetivo de la gestión de riesgos es mantener todos ellos dentro de unos
límites aceptables y definidos, lo que constituye la política de riesgos
adoptada para el proyecto. La gestión debe cubrir todas las áreas de vida del
proyecto:

 Desarrollo

Técnicas

Calidad

 Planificación

Financiación

Alcance

Aspectos legales

Impacto socioeconómico

Fechas de necesidad

 Costes

Cumplimiento del contrato

Control de costes

 Operación

Soporte logístico

Fiabilidad

Disponibilidad

Seguridad

La gestión de riesgos es una tarea continua e interactiva que incluye los
siguientes procesos:

a) Identificación sistemática y evaluación de todos los sucesos de riesgo y sus
consecuencias, como paso previo a la toma de la decisión más apropiada,
aceptación del riesgo, seguimiento de la evolución del riesgo o toma de
acciones.

b) La definición, implementación, control y verificación sistemática de las
acciones apropiadas para la eliminación del riesgo, la reducción del riesgo a un
nivel aceptable o la mitigación de sus consecuencias.

c) Las consecuencias del riesgo deben ser categorizadas en función de la
probabilidad de ocurrencia y de su severidad, de acuerdo con la política de
riesgos adoptada para el proyecto.

9.1.- Calificación del riesgo de un proyecto

Todo proyecto puede ser calificado en relación con el riesgo a partir de sus
características principales, incluso en la fase de preparación de ofertas. Como
consecuencia de esa calificación, serán identificados los puntos críticos a
vigilar y determinado el nivel de seguimiento para el proyecto.

Las características principales para calificar un proyecto incluyen, pero no se
limitan a las siguientes:

 Magnitud (expresada mediante un parámetro adecuado: horas, duración, número de
participantes, inversión del proyecto, etc.).

 Grado de definición (precisión del alcance y de los “entregables”, complejidad
de los requisitos, disponibilidad de la documentación, etc.).

 Patrocinio (grado de interés de los usuarios y de la dirección).

 Repercusiones en la organización del usuario (efecto en las operaciones del
usuario, cambios de estructura, procedimientos, etc.).

 Personal asignable al proyecto (experiencia previa del personal, porcentaje de
dedicación).

 Metodología de gestión empleada.

 Complejidad del producto a desarrollar.

Esta calificación puede efectuarse mediante la aplicación de una lista de
comprobación tal y como aparece a continuación (ver esta y próxima página). Se
rellenan los impresos (páginas 1 y 2) y se obtiene una calificación cualitativa
del proyecto.

FACTORES DE RIESGO CRITERIOS NIVEL RIESGO

B M A

MAGNITUD DEL PROYECTO Horas-Hombre

Duración

Número de miembros del Equipo de Trabajo

Emplazamientos

Interfaces con Sistemas existentes

Organizaciones afectadas

DEFINICIÓN DEL PROYECTO Alcance del Proyecto

Entregables del Proyecto

Beneficios del Nuevo Sistema

Complejidad de los Requisitos del Usuario

Conocimientos de los Usuarios

Conocimiento del Equipo de Trabajo

Disponibilidad de la Documentación de partida

Dependencia de otros Proyectos

Otros Proyectos que dependen de este

Análisis Coste/Beneficio

PATROCINIO Patrocinio del Proyecto

Grado de compromiso de la Dirección de los Usuarios

Grado de compromiso de la Organización de los Usuarios

Relación con el Plan Estratégico de los Usuarios

Grado de compromiso de la Dirección del Cliente.

REPERCUSIONES EN LA ORGANIZACIÓN Sistema nuevo o conversión de uno existente

Repercusión en las Operaciones

Cambios de procedimiento impuestos por el nuevo sistema

Cambios en la Estructura Organizativa

Cambios en la Política

ASIGNACIÓN DE PERSONAL AL PROYECTO Experiencia del Gerente de Proyecto

Dedicación del Gerente de Proyecto

Equipo del Proyecto

Experiencia como Equipo de Trabajo

Experiencia del Equipo de Trabajo en este tipo de Proyectos

Ubicación del Equipo de Trabajo

Participación del Usuario en el Equipo de Trabajo del Proyecto.

GESTIÓN DEL PROYECTO Metodología utilizada

Procedimientos de Gestión de Cambios

Procedimientos de Gestión de la Calidad

Enfoque de Gestión del Proyecto

HARDWARE/

SOFTWARE DEL PROYECTO Hardware o Software nuevo

Disponibilidad del Hardware para Pruebas

ENFOQUE DE DESARROLLO DEL PROYECTO Herramientas y Técnicas Nuevas

Procesos Nuevos

Base de Datos Nuevas

SOFTWARE COMERCIAL A UTILIZAR Conocimiento de las Aplicaciones

Referencias del Suministrador de las Aplicaciones

Conformidad funcional con los requisitos del Proyecto

Implicación en la selección de las Aplicaciones

RESUMEN GRAL.

CALIFICACIÓN

Gerente de Proyecto Observaciones:

Siglas

Firma

Fecha

9.2.- Identificación de riesgos

La identificación es la respuesta a la pregunta: ¿Qué podría ir mal en el
proyecto? La respuesta se materializa en una lista de escenarios indeseables,
cuyas consecuencias tendrían que ser evaluadas. Los sucesos de riesgo pueden ser
identificados en cualquier momento de la ejecución del proyecto y por cualquiera
de los participantes en el mismo.

Puede utilizarse un formato que redacta la persona que detecta el riesgo y lo
somete a la consideración del director del proyecto. El formato se utiliza para
definir el suceso de riesgo, su probabilidad de aparición, determinar su impacto
global sobre el proyecto, categorizarlo, identificar los riesgos consecuentes,
definir la estrategia de prevención y sus posibles consecuencias.

La información de los formatos pasa a una base de datos y se listan en un
registro de control de sucesos de riesgo. Los formatos Pro forma de suceso de
riesgo y Registro de control de sucesos de riesgo aparecen a continuación:

Figura 10.2

Figura 10.3

9.3.- Cuantificación de riesgos

La cuantificación de riesgos es la respuesta a las preguntas. ¿Cuál es la
severidad de las consecuencias del riesgo? ¿Cuál es la probabilidad del
escenario supuesto? ¿Cuál es la magnitud del riesgo? ¿Puede ser evaluado el
riesgo y controlada su evolución?

Las consecuencias de un riesgo son diversas y especificas de cada campo de
aplicación, por ejemplo:

 Pérdida de vidas humanas.

 Daños al personal.

 Pérdida de misión.

 Polución del medio ambiente.

 Degradación de los objetivos del proyecto.

 Productos fuera de especificación.

 Incrementos de coste.

 Retraso de plazos.

 Insatisfacción del cliente.

.

La escala de severidad adoptada para estos sucesos es de mayor a menor es:

Catastrófica / crítica / importante / significativa / pequeña

La cuantificación del riesgo es efectuada por el responsable de la prevención
del mismo, es incluida en el documento de identificación de riesgos y queda bajo
el control del proyecto.

9.4.- Desarrollo de respuesta ante riesgos

El desarrollo de respuestas ante riesgo es la contestación a las preguntas:
¿Cuál es la decisión adoptada para cada suceso de riesgo? ¿Como pueden ser
eliminados los riesgos o reducidos a un nivel aceptable?

El director de proyectos debe analizar las propuestas de los responsables de
riesgos y adoptar las decisiones pertinentes, en función de la política de
riesgos que se haya establecido para el proyecto e implantar los planes de
contingencia que crean convenientes. Cuando lo crea necesario someterá las
respuestas ante riesgos a su superior jerárquico.

La respuesta adoptada quedará definida en el documento “Identificación de
riesgos” y será controlada hasta la desaparición del riesgo: ver el formato de
documento y listado.

9.5.- Control de respuesta ante riesgos

El control de respuesta ante riesgos es la contestación a las preguntas: ¿Puede
la reducción de riesgo ser evaluada y verificada? ¿Es el riesgo residual
aceptable?

Las medidas predictivas y correctivas empleadas para la mitigación de los
riesgos del proyecto deben ser documentadas. Adicionalmente, se debe informar
periódicamente de la evolución de los riesgos. Esta información puede constituir
un capítulo del informe periódico del proyecto (ver módulo 9).

El contenido de este capitulo podría ser el siguiente:

Informe de la situación de riesgos del proyecto (ver formato adjunto).

En este documento se indica la situación de los riesgos identificados a la fecha
del informe, los cambios registrados en el período y el detalle de los sucesos
de riesgo importantes con posibles efectos presentes o próximos.

Lista de sucesos de riesgo y su evolución prevista

Gráfico de la evolución de la severidad de sucesos de riesgo (no se adjunta).

A continuación se adjuntan modelos de formatos para presentar la información
anterior.

Figura 10.4

Clasificación de los Requerimientos

  • admin 

Clasificación de los RequerimientosThis is a featured page

REQUERIMIENTOS ESPECÍFICOS.Los requerimientos deben exponerse en la forma más precisa posible, pero sin que la descripción de un requisito individual resulte demasiado extensa. Si fuera necesario, puede darse una descripcion resumida y hacer referencia a un apéndice con la descripción detallada.

Es importante no incluir en los requerimientos aspectos de desarrollo o diseño. Los requerimientos son lo mínimo que se impone al sistema, y no hay que describir soluciones particulares que no sea obligatorio utilizar (excepto como aclaración o sugerencia).

Es ventajoso enunciar los requerimientos en forma de una lista numerada, para facilitar su seguimiento y la validación de sistema. Cada requerimiento debe ir acompañado de una indicación del grado de cumplimiento necesario, es decir, si es obligatorio, recomendable o simplemente opcional.

  • Funcionales. Lo que el software debe de hacer. Se encuentran muy ligados al modelo conceptual propuesto. Se concretarán las operaciones de tratamiento de información que realiza el sistema, tales como almacenamiento de información, generación de informes, cálculos, estadísticas, operaciones, etc.

¿Qué hará el sistema?
¿Cuándo lo hará?
¿Existen varios modos de operación?
¿Cómo y cuándo puede cambiarse o mejorarse el sistema?
¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?

  • Ambiente físico.

¿Dónde está el equipamiento que necesita el sistema para funcionar?
¿Existe una localización o varias?
¿Existen restricciones ambientales, tales como temperatura, humedad o interferencia magnética?

  • Usuarios y factores humanos.

¿Quién usará el sistema?
¿Habrá varios tipos de usuario?
¿Cuál es el nivel de habilidad de cada tipo de usuario?
¿Qué clase de entrenamiento requerirá cada tipo de usuario?
¿Qué tan fácil le será a un usuario comprender y utilizar el sistema?

  • Desempeño. Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperación, etc.
  • Interfaz. Elemento de interacción con la gente, hardware u otro software. Se incluyen por lo tanto, bases de datos, protocolos, formatos de ficheros, sistemas operativos, datos, etc.

¿La entrada proviene de uno o más sistemas?
¿La salida va a uno o más sistemas?

  • Restricciones de diseño. Estándares establecidos para el desarrollo.
  • Operación. Son los referentes al uso del sistema en general e incluyen los requisitos de la interfase de usuario (menús de pantalla, manejo de mouse, teclado, etc.). el inicio y fin, copias de seguridad, requisitos de instalación y configuración.
  • Recursos. Son los referentes a elementos de hardware, software, instalaciones, etc., necesarios para el funcionamiento del sistema. Es muy importante estimar los recursos con cierto coeficiente de seguridad en previsión de necesidades de última hora no provistas inicialmente.
  • Verificación. Son los que debe cumplir el sistema para que sea posible verificar y certificar que funciona correctamente el sistema (funciones de autotest, emulación, simulación, etc.).
  • Prueba de aceptación. Son los que deben cumplir las pruebas de aceptación a que se someterá el sistema.
  • Documentación. Son los referentes a la documentación que debe formar parte del producto a entregar.
  • Seguridad. Son los referentes a la protección del sistema contra cualquier manipulación o utilización indebida (confidencialidad, integridad, virus, etc.).
  • Transportabilidad. Son los referentes a la posible utilización del sistema en diversos entornos o sistemas operativos de una forma sencilla y barata.
  • Calidad. Son los referentes a aspectos de calidad que no se incluyan en otros apartados
  • Fiabilidad. Son los referentes al límite aceptable de fallos o caídas durante la operación del sistema.
  • Mantenibilidad. Son los que debe cumplir el sistema para que se pueda realizar adecuadamente su mantenimiento durante la fase de explotación.
  • Capacidad. Son los referentes a los volúmenes de información a procesar, tiempo de respuesta, tamaños de ficheros o discos, etc. Estos requerimientos deben expresarse mediante valores numéricos e incluso, cuando sea necesario, se darán valores para el peor, el mejor y el caso más habitual.
  • No funcionales. Describen atributos del sistema o atributos del ambiente del sistema y generalmente no son establecidas por el usuario.
  • Implícitos. Son los que se asumen que el software debe de tener.
  • Extras. Agregados que generan valor al producto de software.

rafa:

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

A menudo, los requerimientos de sistemas software se clasifican en funcionales y no funcionales, o como requerimientos del dominio:

1. Requerimientos funcionales. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.

2. Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema.

3. Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no funcionales.

En realidad, la distinción entre diferentes tipos de requerimientos no es tan clara como sugieren estas definiciones. Por ejemplo. un requerimiento del usuario sobre seguridad podría parecer un requerimiento no funcional. Sin embargo, cuando se desarrolla en detalle, puede generar otros requerimientos que son claramente funcionales, como la necesidad de incluir en el sistema recursos para la autentificación del usuario.

REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera.

Los requerimientos funcionales para un sistema software se pueden expresar de diferentes formas. A continuación se presentan algunos ejemplos de estos requerimientos funcionales para un sistema de biblioteca universitario, denominado LIBSYS y utilizado por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.

l. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.

2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos.

3. A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta.

Estos requerimientos funcionales del usuario definen los recursos específicos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales (contraste los requerimientos l y 3).

El sistema LIBSYS es una interfaz única para diferentes bases de datos de artículos. Esto permite a los usuarios descargar copias de artículos publicados en revistas, periódicos y publicaciones científicas. Una descripción más detallada de los requerimientos para el sistema en el cual se basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre ingeniería de requerimientos (Kontonya y Sommerville, 1998).

La impresión en la especificación de requerimientos es la causa de muchos de los problemas de la ingeniería del software. Para un desarrollador de sistema es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se deben establecer nuevos requerimientos y hacer cambios en el sistema. Por supuesto, esto retrasa la entrega de éste e incrementa los costes. Considere el segundo ejemplo de los requerimientos para el sistema de biblioteca que se refiere a los «visores adecuados» que debe proporcionar el sistema. El sistema de biblioteca puede mostrar documentos en diferentes formatos; la intención de este requerimiento es que los visores para todos estos formatos estén disponibles. Sin embargo, el requerimiento está ambiguamente redactado; no clarifica que se deben proporcionar los visores de cada formato.

Un desarrollador bajo la presión del tiempo sencillamente podría proporcionar un visor de texto y atinar que se ha cumplido el requerimiento. En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. La consistencia significa que los requerimientos no deben tener definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es prácticamente imposible alcanzar los requerimientos de consistencia y completitud.

Una razón de esto es que es fácil cometer errores y omisiones cuando se redactan especificaciones para sistemas grandes y complejos. Otra razón es que los stakeholders del sistema tienen necesidades diferentes, y a menudo contradictorias. Estas contradicciones pueden no ser obvias cuando los requerimientos se especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la especificación. Es posible que los problemas surjan solamente después de un análisis más profundo o, a veces, después de que se termine el desarrollo y el sistema se entregue al cliente.

REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.

Los requerimientos no funcionales rara vez se asocian con características particulares del sistema. Más bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, pueden especificar el rendimiento del sistema, la protección, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son más críticos que los requerimientos funcionales particulares.

Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una función del sistema que realmente no cumple sus necesidades. Sin embargo. el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable.

Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarán correctamente. Los requerimientos no funcionales no sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso, una especificación que el diseño debe producir con una herramienta CASE particular y una descripción del proceso a seguir.

Definición de objetivos de un proyecto.

  • admin 

EL primer paso para lograr arrancar un proyecto con garantías es definir con extrema concrección  los objetivos y el alcance de un proyecto.

¿Por qué son importantes los objetivos?

Lo son principalmente por 5 razones:

  1. Ayudan a acotar el alcance real del proyecto y son la base de la toma de decisiones durante la ejecución del proyecto.
  2. Su validación con el cliente (ya sea interno o interno) incrementa la capacidad de satisfacción de sus expectativas.
  3. Permite involucrar a todas las partes interesadas y miembros del proyecto en base a unas metas claras por lo que estos objetivos deben ser comunicados
  4. Es una base fundamental para la planificación del proyecto, ya que permite definir con acierto las tareas a realizar, en cuánto tiempo y por parte de quién. Además, una vez que los objetivos están priorizados es posible ordenar y distribuir los esfuerzos a realizar en base a dichas prioridades.
  5. Sin objetivos previos claros es imposible monitorizar la evolución del proyecto ni medir su éxito final.

¿Cómo deben ser estos objetivos?

A la hora de definir un objetivo, éste debe quedar enunciado de forma clara. Una técnica frecuentemente utilizada para poder evaluar si los objetivos están correctamente definidos es verificar si son “SMART”, acrónimo de las siguientes características:

  • Específicos (Specific): Claros sobre qué, por quién, dónde, cuándo y cómo va a conseguirse;
  • Medibles (Measurable): que sea posible cuantificarlos;
  • Realizables (Achievable): debe ser posible logralos con los medios y capacidades disponibles;
  • Realistas (Realistic): que sea posible alcanzarlos en el tiempo y forma previsto;
  • Limitado en tiempo (Time bound): debe fijarse el periodo de tiempo en el que se debe completar cada uno de ellos.

Un ejemplo de un objetivo enunciado correctamente puede ser:

“Reducir el tiempo de reparto en un tercio antes del 31 de diciembre mediante la implantación de un sistema automático de cálculo de rutas a través de la ciudad basado en la densidad de tráfico.”

Éste es un objetivo claro sobre lo que se quiere conseguir y cómo, medible con el número de días de reparto, realizable y realista (asumimos que sí, aunque esto evidentemente depende de los recursos disponibles) y acotado en el tiempo pues tiene una fecha clara de fin del proyecto.

Ahora, os animamos a reflexionar sobre un proyecto en el que estéis inmersos en este momento. ¿Los objetivos perseguidos han definidos claramente antes de iniciar el proyecto y consensuados con el cliente? ¿Han sido comunicados a todos los participantes en el mismo y otras partes afectadas? ¿Cumplen con las características así? Si no es así, tranquilos, no es un drama, pero tal vez es el momento de hacerlo antes de que sea demasiado tarde. Su revisión es posible que suponga una necesaria replanificación del proyecto pero es un esfuerzo que valdrá la pena y minimizará el riesgo de fracaso del proyecto.

Esperamos que este artículo os haya servido de ayuda y antes de iniciar el próximo proyecto verifiquéis que habéis definido correctamente los objetivos del proyecto. Os recordamos que debe hacerse antes del inicio del proyecto y previamente a la planificación del mismo.

ESTRUCTURA DE DESGLOSE DE TRABAJO (EDT o WBS)

  • admin 

ESTRUCTURA DE DESGLOSE DE TRABAJO (EDT o WBS)

I INTRODUCCIÓN
Una buena Gestión de proyectos utiliza diversas técnicas de planificación para definir con el debido detalle el  objetivo y alcance del mismo.

La estructura de Descomposición de Trabajo EDT(conocida también como WBS por sus siglas en inglés de Work Breakdown Structure) es una técnica que proporcina las bases para la definición del trabajo basándose en la descomposición del mismo.
WBS o EDT se usa para definir el trabajo en términos de entregables y para la descomposición adicional de estos entregables en componentes. Es la base para establecer :
  • Todos los esfuerzos/costos a incurrir para soportar los procesos y crear los entregables
  • Las responsabilidades asignadas para ejecutar y coordinar el trabajo

Entre vistamos a algunos expertos en gestión de proyectos para elaborar este blog que permitirá conocer más acerca del EDT o WBS.

II DEFINICIÓN DE LA EDT

  • » El EDT o estructura de desagregación del trabajo, acá lo conocemos mas por sus siglas en ingles como el WBS (work breakdown structure) y es el listado de todas las actividades que comprenden el alcance del proyecto, necesarias para realizar su planificación y efectuar su ordenada ejecución y control.
    Estas actividades están desagregadas en actividades mas pequeñas o tareas a un suficiente nivel de detalle para permitir un seguimiento adecuado y a su vez cada una de las actividades está concatenada a otra en función a sus actividades pre requisitos o actividades predecesoras, las que se visualizan en el diagrama de Gantt o cronograma
    «

Ing. Darío Arrus Queirolo – Gerente de Desarrollo tecnológico. Alicorp

  • « Estructura de desglose del trabajo. Es una diagramación que muestra por niveles como se descompone los entregables del proyecto.
    Es básico realizar directamente con la persona que tenga el conocimiento y la experiencia el EDT
    Los EDT se van enriqueciendo conforme va el tiempo a un determinado momento»

Ing. Adolfo Macha Olivera – Gerente de Producción Manufactura. Alicorp

  • » La Estructura desglosada del trabajo es una técnica de planeación, mediante la cual podemos definir y cuantificar el trabajo a realizar durante todo el proyecto ha efecto de organizarlo adecuadamente.

Los EDT está en función de parte que actividades se abre un árbol infinito».

Ing. Carlos Hernández Blas – Gerente de Proyecto. Alicorp

III UBICACIÓN DE LA EDT

  • «Se utiliza en el grupo de procesos de planificación del proyecto en el proceso de gestión del alcance para establecer entregables y los paquetes de trabajo y establecer todo y solo el trabajo necesario».

Ing. Jesus Zumaeta – Especialista en proyecto. SUNAT

  • Considero que deben estar descritas en la etapa de planificación del proyecto, teniendo como objetivos, primero, el tener en claro el conjunto de actividades necesarias a realizar para cumplir con el objetivo del proyecto y luego minimizar el riesgo o impacto de obviar alguna de ellas (camino o ruta critica).

Ing. Carlos Cervantes -Especialista en proyectos- Min. de Energía y Minas

  • «La EDT es útil en distintas fases del proyecto. Por ejemplo nos permite definir el trabajo de lo general a lo particular en la etapa de Planeacion del proyecto y en cambio nos permite cuantificar avances y recursos de lo particular a lo general en la etapa de ejecución, seguimiento y control del proyecto».

Economista Rosa Cavero – Especialista financiera- MIn. de Energía y Minas

IV PROPÓSITO

  • » En base a la EDT, puedo definir mis recursos que voy a utilizar para cada actividad en cada nivel y sacar con ella el presupuesto del proyecto».

Ing. Ernesto Guevara Paredes

  • » Con una EDT bien definida puedo darme cuentas de los puntos sensibles en ciertas partes del proyecto ya que me permite visualizarlos detalladamente, por otro lado me ayuda a no perder la mirada en el objetivo esencial del proyecto debiendo controlar cada una de las actividades que la componen. Sin duda es una técnica sistémica, metodológica y efectiva que es posible implementar en cualquier campo «.

Ing. David Rojas Dueñas

  • «Es un proceso por el cual se asegura que todos conozcan el objetivo o producto final del proyecto y su participación en el logro de objetivos, mediante el conocimiento que cada uno asimila de su participación en el planeamiento desarrollo, seguimiento o control del proyecto y así estar seguros que se esta siguiendo el camino correcto a la meta del proyecto. Esto significa que la EDT es más útil cuando se implementa en torno a los productos o los resultados previstos en el proyecto en lugar de los trabajos necesarios para producir los productos. Desde los resultados previstos son los extremos del proyecto, forman un conjunto relativamente estable de las categorías en los que los costes de las acciones previstas necesarias para lograr esos objetivos se pueden recoger cuando se ha diseñado correctamente la EDT será fácil asignar cada actividad del proyecto un responsable y procedimiento».

Economista Rafael Hidalgo.

V APLICACIÓN

  • » Los pasos a seguir son identificar los entregables o las fases, luego se descompone hasta llegar a un nivel que se pueda controlar, en costo, recursos humanos y alcance «.

Ing. Rafael paredes

  • » Primero debo identificar todos los entregables y fases, organizarlos y detallarlos hasta nivel de paquetes de trabajo. Sirve para definir la línea base del alcance junto con el diccionario EDT «.

Lic. Administración Marco Carrasco. GRUPO ROMERO

  • » Eso depende de la fase. Por ejemplo en la fase de planeación tendremos que organizar las ideas alrededor de lo que se pretende lograr, del producto final del proyecto, involucra desde definir el nombre del proyecto de acuerdo con la meta que se pretende alcanzar y la organización que se tendrá.
    Ya en el desarrollo, seguimiento y control, involucrara a las grandes áreas de trabajo y que sus responsables estén imbuidos en el producto final del proyecto y en sus competencias para obtenerlo, en lo que se espera de ellos, se evitara cruce de competencias, duplicidad de esfuerzos y se asumirá que cada área se constituye un gran paquete de trabajo que esta conformado con sub. Tareas que aportan para el producto final.Es conveniente realizar reuniones de trabajo con herramientas tales como el brainstorming o tormenta de ideas, donde finalmente cada área arribara a un paquete de actividades integrantes de cada uno de los paquetes de trabajo. Pero también cada actividad a su vez, pueden ser subdividida hasta lograr el desglose que efectivamente necesita el proyecto, que estará determinado por la complejidad y tamaño del proyecto y además debe considerarse que cada actividad debe ser factible de medir en sus logros «

Economista Sandro Risco Salcedo. GRUPO ROMERO

VI RELACIÓN DEL EDT CON OTRAS HERRAMIENTAS

  • » La EDT es una buena herramienta para el desarrollo de un proyecto, puede complementarse con otras herramientas mas potentes como BSC, asimismo se puede complementar con otras de igual importancia, tales como:

Diagrama del árbol
Diagrama de gantt
Diagrama de pert
Valor ganado

Ing. Roberto Shimabukuro. Intendencia nacional de Sist. de información-SUNAT

  • » Tiene relación con otras herramientas como el MS Proyect, ya que el desglose de actividades que se hará de la meta u objetivo central del proyecto, requerirá determinar sub. actividades, tiempos, plazos responsables, unidades de medidas, costos, etc., en donde el MS es muy útil.

Yo tuve una experiencia de EDT cuando se iba dar inicio a un proyecto de inversión del estado, el director del proyecto, sus gerentes, sub. gerentes y los jefes de unidad nos concentramos un fin de semana ( 2 noches y 3 días) fuera de la entidad, para que ayudados con un experto en EDT definiéramos las actividades del proyecto desde su ultimo nivel, hasta su ultimo nivel en las áreas de los funcionarios asistentes, de tal manera que conociendo exactamente el producto final del proyecto, el o los productos de cada gerencia, sub. gerencia y unidades se estableciera un adecuado EDT y estaríamos todos de acuerdo en nuestro rol, para lograr la meta que se pretendía alcanzar con la creación del proyecto, Fue una herramienta muy útil, establecimos diversas actividades todas ellas medibles, excluyentes sus plazos de ejecución, los productos tangibles por cada actividad, los cuellos de botella, etc. Con mayor precisión de la que uno suponía y luego la pusimos en un gran árbol donde las ramas y las hojas se formaron con cada una de las actividades que cada uno de los asistentes escribía. Fueron sesiones de trabajo muy interesantes y productivas, previas al inicio de ejecución del proyecto «.

Economista Julia Mata- Gerencia De Planeamiento de Proyectos-SUNAT

  • » Otras estructuras comúnmente usadas en algunas áreas de aplicación y que están relacionadas al EDT son:
  1. LA ESTRUCTURA DE DESCOMPOSICIÓN DE LA ORGANIZACIÓN
  2. LA ESTRUCTURA DE DESCOMPOSICIÓN DE LOS RECURSOS
  3. DIAGRAMAS DE PERT
  4. DIAGRAMAS DE GANTT