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

How Do Scrum and CCPM Compare?

  • admin 

Fuente: http://www.reformingprojectmanagement.com/2003/11/14/273/

How Do Scrum and CCPM Compare?

A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM). 

Scrum is one of several Agile/Lean Software Development techniques. The opposite of Scrum/Agile/Lean is the waterfall development lifecycle where analysis, design, development, system testing, and user acceptance testing are done in sequential phases. Scrum/Agile/Lean works in short iterations – between 1 and 12 weeks each.

THE CORE CONFLICT FOR SOFTWARE DEVELOPMENT PROJECTS (AND MOST OTHERS I IMAGINE) LOOKS LIKE THIS.

[This is a fine example of Goldratt’s Evaporating Cloud]

    D - Allow change throughout project
  B - Build functionality required by customer
A - Have a successful software project
  C - Deliver on time and to budget
    D'- Agree scope up-front and don't allow change throughout project

[Read the above chart this way: I want (A) a successful software project. To be successful I need (B) to build the functionality required by my customer. And I need (C) to deliver on time and on budget. For me to build the functionality required by my customer I need (D) to allow for change throughout the project. However, for me to deliver on time and budget I need (D’) to agree to the scope up-front and not allow changes throughout the project. (D) and (D’) are in conflict and cannot coexist.]

In a traditional/waterfall environment «change control» is the mechanism used to do both D and D’ poorly.

The agile approaches attack three assumptions:

Assumption CE1
We can prevent change if we spend enough time to ensure we get everything agreed and signed off up front. Agile/lean says that CE1 is just plain wrong (in all but the simplest environments). Therefore, E doesn’t even give you C. Even if we get the requirements right up front, they will change, so if we don’t change them as we go then while C (finish on time and budget) is satisfied, we won’t satisfy B (customer gets what they need) so that A (the project) isn’t successful.
Assumption CE2
It is many times more expensive (i.e. Boehm’s cost of change curve) to change the further we get into the project. Agile/lean says that CE2 is wrong too. For instance XP (eXtreme Programming), a cousin of Scrum, suggests that the cost of change curve quickly becomes flat when using test-driven development and refactoring in a iterative/incremental approach.
Assumption CE3
The project only delivers value when it is finished. Agile/Lean says that you don’t have to deliver everything at once to get value. Instead you can get value quite quickly by delivering small high-priority increments of the product. At the very least you gain value by discovering what’s not working much, earlier.

[Clarke examines three cause and effect assumptions behind the evaporating cloud as it was described. He sets out to invalidate each one.]

THE KEY POINTS OF SCRUM ARE:
A product owner manages a product backlog.
This is a list of high-level requirements/features – e.g. user can register, user can login, user can add items to a shopping cart, user can search for books, etc – that has been prioritized by the product owner. It will also include «technical things» – e.g. install server, upgrade source management system – added to it if requested by the developers and agreed by the owner.
Every 30 days a new «sprint» starts.
Each sprint is a 30-day iteration where the development team picks a set of features from the product backlog that they estimate they can «deliver» within the next 30 calendar days. They then work on that sprint for the next 30 days.
During this time no changes can be made to the sprint unless suggested by the developers.
«Delivered» means that the feature could potentially, although not necessarily, be shipped or implemented.
It’s fully coded and tested, the help is prepared, it’s not going to break when the users get hold of it.
Each scrum team is self-managing with guidance from the «Scrum master».
Initially the team will struggle with self-management but, apparently, they learn quickly. Each day a 15 minute meeting is held where each person answers 3 questions – what did I do yesterday?, what will I do today? And what obstacles are holding me up? It is the Scrum master’s job to clear the obstacles.
The theory behind scrum says that complex processes, such as software development, change too much and are too difficult to manage.
They need to be managed empirically, with constant inspection and adaptation.

[Those of you who use the Last Planner System™ will recognize similarities with Scrum. The backlog of tasks grows, as does a weekly work plan, as the project goes along. Project performers take tasks from the backlog making promises to complete them. The Scrum approach is done or not done. No credit for effort. And very much like lean, people understand their projects as complex and evolving.]

HOW DOES SCRUM DIFFER FROM CRITICAL CHAIN?
  • CC aims to get the project finished as quickly and reliably as possible. Scrum aims to get working functionality delivered as quickly as possible.
  • CC buffers with time. Scrum buffers with functionality.
  • CC says «Don’t put the safety in the task; put it in the project». Scrum says «Don’t try and figure it all out up front because you can’t. Things will change too much as you go. Instead, build working software quickly, inspect and adapt».

Despite these differences I believe that CC and Scrum are not only complimentary but synergy should be gained by using both together. That said, I don’t know of anyone doing this. Scrum is mostly used in IT along with changed engineering practices, but it has been used in non-IT projects.

¿Scrum vs ITIL o Scrum + ITIL?

  • admin 

fuente: http://www.re-inventa.com/scrum-vs-itil/

¿Está ITIL reñido con Scrum o, por el contrario, son compatibles? Principalmente es una duda que le surge a personas del ámbito de desarrollo de software que están dando sus primeros pasos en el agilismo y que han oído hablar sobre ITIL y sus bondades, aunque todavía no lo conocen con suficiente profundidad.

Pues bien, la respuesta es simple pero compleja al mismo tiempo. ITIL y Scrum, aunque pueden guardar cierta relación, son cosas muy distintas. Están completamente enfrentados a nivel de objetivos y de filosofía subyacente pero, a pesar de ello, pueden compatibilizarse sin que necesariamente haya menoscabo de ninguno de los dos enfoques. En mi opinión, el objetivo tiene que ser obtener lo mejor de ambos mundos y, por experiencia personal, puedo asegurar que se trata de algo completamente factible.

En esta línea, ya escribí una entrada sobre lo que yo denomino Agile ITIL, en la que explico mi experiencia aplicando Scrumban + ITIL en el área de sistemas de BikoEn este post, en cambio, mi objetivo es aclarar en mayor medida cuáles son las diferencias y algunos de los nexos de unión entre Scrum e ITIL.

.

¿Qué es Scrum?

Scrum es una metodología ágil de gestión de proyectos (project management) orientada a ámbitos poco ordenados:

  • Metodología:  Scrum admite cierta flexibilidad en su implementación pero exige que se apliquen todos sus roles, procesos y artefactos. Podemos llevar a cabo un daily scrum que dure 5 o 15 minutos, llevar el product backlog en un Excel, en Jira o en ScrumWise, tener 3 o 20 columnas de estado en nuestro panel… pero si no llevamos a cabo el scrum diario, no tenemos product backlog, no tenemos panel, no existe la figura de product owner o no hacemos retrospectivas… lo que hacemos podría considerarse ‘agile’, dependiendo del caso, pero no sería Scrum. Sólo con que prescindamos de uno de estos elementos, no estaremos haciendo propiamente Scrum (en la forma en que Jeff Sutherland y Ken Schwaber lo definieron, otra cosa es el concepto de ‘campo de scrum’ de Nonaka y Takeuchi en The New Product Development Game).
  • Ágil: es acorde a los principios del manifiesto ágil, por lo que el énfasis de la gestión se traslada a las personas y las interacciones, al producto funcionando, a la colaboración con el cliente y a la respuesta ante el cambio. En consecuencia, como toda metodología ágil, Scrum es especialmente adecuado cuando lo que prima es el conocimiento tácito.
  • Gestión de proyectos: los proyectos son un esfuerzo temporal para crear un producto, un servicio o un resultado único. Tienen un principio y un final bien definidos.
  • Ámbitos poco ordenados: son aquellos entornos cambiantes, en los que además hay muchas variables que influyen en los resultados y, por ello, se hace difícil la predicción apriorista. El desarrollo de software es un ámbito poco ordenado porque, entre otras cosas, como bien sabemos, por detallado que sea el análisis de requisitos inicial, siempre surgen nuevos requerimientos a medida que avanzamos en el proyecto.

¿Qué es ITIL?

ITIL es un marco predictivo de buenas prácticas en gestión de servicios de TI, que suele aplicarse en ámbitos ordenados:

  • Marco (framework): ITIL reúne herramientas y principios de gestión generalmente aceptados como buenas prácticas. Al tratarse de un marco, no es rígido en su implantación, en el sentido de que permite implementar únicamente los procesos o grupos de procesos que nos interesen: gestión de la configuración, gestión de cambios, gestión de incidencias, etc.
  • Predictivo: a diferencia de las metodologías ágiles, ITIL pone énfasis en los procesos y las herramientas, en la documentación, en las relaciones contractuales y los SLAs y en el seguimiento de procedimientos y planes predefinidos. En consecuencia, los mejores resultados con ITIL se obtendrán cuando el conocimiento explícito tenga preponderancia sobre el tácito para la ejecución del trabajo o de una tarea concreta.
  • Buenas prácticas: las buenas prácticas son mejores prácticas cuyo uso se ha extendido y sobre las que existe un consenso generalizado de que su aplicación contribuye al éxito del servicio. En consecuencia, el cuerpo de buenas prácticas identificadas por ITIL evoluciona con el paso del tiempo, mientras que los roles, procesos y artefactos de Scrum son los que son.
  • Gestión de servicios: los servicios son operaciones, una función de la organización que se efectúa permanentemente. Por lo tanto, en comparación con los proyectos tienen un marco temporal muy distinto. En consecuencia, los principios de gestión generalmente aceptados para ambos también son diferentes.
  • Ámbitos ordenados: son aquellos en que las variables que influyen en el resultado de una acción están bien identificadas, por ello los modelos que dan mejores resultados son los predictivos.

Analogías entre Scrum e ITIL

Aunque llegados a este punto resulta sencillo identificar las diferencias entre Scrum e ITIL, anexo la siguiente tabla que resulta más gráfica:

Scrum e ITIL: Tabla comparativa

Además de los puntos ya mencionados en las definiciones, en la tabla he añadido elproceso de mejora continua. Aunque el proceso de mejora de ambas metodologías se basa en la filosofía del ciclo de Deming (PDCA)Scrum, con sus retrospectivas, hace mayor énfasis en el expertise y la percepción de los miembros del equipo (orientación a personas); mientras que ITIL se fundamenta en métricas objetivas relacionadas con el nivel de desempeño de los procesos (orientación a procesos). Obviamente, cada una tiene sus pros y sus contras.

Otro aspecto diferencial es la amplitud de miras. Mientras que el ámbito de Scrum es genuinamente el proyecto, obviando los aspectos a nivel organizacional y confiando en la auto-organización del equipo, ITIL tiene una perspectiva más holística: destaca la relevancia de alinear los proyectos y servicios con las necesidades y los objetivos de negocio, el desarrollo de los profesionales del equipo para que puedan responder a las necesidades organizativas, la gestión del conocimiento, etc. Para tal propósito, ITIL explicita diversos procesos y funciones específicos.

Como puede verse, las diferencias son múltiples y reseñables. Sin embargo, a pesar de ello, existen más nexos de unión entre ambos enfoques de lo que pueda parecer a primera vista. Saber combinar e hibridar las prácticas y herramientas de ambos enfoques de la manera adecuada, es la clave para obtener lo mejor de los dos mundos y un rendimiento extraordinario.

Nexos de unión (I): ITIL + Scrum

Vamos a poner como ejemplo que nuestro núcleo duro es la gestión de operaciones. Nuestro equipo se dedica a gestionar varios servicios de tecnologías de la información para una organización determinada: administrar y mantener una intranet, un servicio de correo electrónico, un ERP, etc. En este caso, ITIL debería tener un gran peso en la gestión de nuestro día a día.

Sin embargo, llega el momento de implantar un nuevo servicio. Esto se trata de un proyecto en toda regla.

ITIL nos indica aspectos que debemos tener en cuenta en el diseño de dicho servicio: gestión del nivel de servicio, gestión de la disponibilidad del servicio, gestión de la capacidad del servicio, gestión de la seguridad del servicio…

Sin embargo, ITIL no entra en el detalle de cómo debe gestionarse el proyecto de implementación en sí mismo. No habla sobre si el equipo debe ser multidisciplinar o no, ni de los roles que debe haber dentro del equipo, ni cómo deben gestionarse el alcance, el cronograma, la calidad, la comunicación con los interesados o el riesgo.

En este punto es donde fácilmente pueden entrar en juego diversas metodologías y marcos de gestión de proyectos, es más, es más que recomendable incorporarlos. Entre las distintas metodologías, obviamente podemos optar por ScrumAdemás, por tratarse de una metodología iterativa, personalmente, la recomiendo con especial profusión. En este punto, Scrum e ITIL tienen una elevada afinidad porque comparten el enfoque PDCA, como ya hemos comentado.

Tomando en cuenta esta perspectiva, parece muy adecuado realizar pruebas piloto (podríamos considerarlas el símil de los prototipos) a usuarios clave durante la fase de transición del servicio y, obviamente, implantar el servicio siguiendo una filosofía incremental; poniendo en vivo primero aquellos aspectos más prioritarios del servicio y desarrollando posteriormente aquellos más accesorios, a medida que se obtiene feedback y fruto de ello se introducen otros cambios. Es más, esta forma de implementar un servicio, que se percibe tan afín a Scrum, sigue al 100% el ciclo de vida de los servicios planteado por ITIL.

Por otra parte, mencionar que dos mecanismos de coordinación de Scrum que son muy valiosos y que pueden incorporarse fácilmente en una organización que ya esté realizando  ITIL son el scrum diario o reunión de seguimiento y las reuniones de retrospectiva.

Nexos de unión (II): Scrum + ITIL

Ahora vamos al caso contrario. Una organización orientada a proyectos, como suele ser la clásica consultora de comunicación online especializada en portales corporativos.

En este entorno, lo que debe predominar es Scrum. No hay dos proyectos iguales y, quienes conozcan bien este ámbito, sabrán que los requerimientos cambian frecuentemente a lo largo del proyecto y que la pericia del equipo de desarrolladores, consultores, etc. juega un papel fundamental en el éxito del proyecto (muy por encima de trazar un buen plan al inicio del proyecto).

Este es un buen ejemplo de cómo podemos enriquecer Scrum con prácticas procedentes de otros enfoques y marcos, ya sean o no ágiles. Por ejemplo: podemos crear un híbrido con Kanban (Scrumban) para gestionar todas esas pequeñas peticiones que nos llegan durante el transcurso de una iteración, podemos incorporar prácticas comoTDD (que viene de XP) para enriquecer nuestro sistema de gestión de la calidad… ytambién podemos incorporar procesos y funciones de ITIL. Por ejemplo:

  • Los procesos de diseño del servicio, aunque sea ejecutándolos a alto nivel, sin entrar en demasiado detalle, pueden ser muy prácticos de cara a valorar aspectos que lamentable y frecuentemente suelen quedar descuidados en equipos excesivamente orientados a desarrollo, como es el dimensionamiento de las infraestructuras, la disponibilidad de personal capaz de resolver incidencias del producto en producción en ciertos periodos estacionales, la formación a usuarios, etc.
  • Que el cambio sea bienvenido en las metodologías ágiles, no significa que puedan llevarse a cabo de forma alegre. Aparte de la consecuente gestión del alcance, si nuestro producto ya está en producción, implantando los procesos y las políticas de transición del servicio de ITIL rellenaremos un vacío de Scrum y nos curaremos en salud de más de un posible susto.
  • No conozco a ninguna compañía orientada a proyectos que no realice operaciones, aunque a veces pasen desapercibidas. En ocasiones, en una empresa como la ejemplificada, los últimos flecos de un proyecto o la resolución de bugs en el periodo de garantía se gestionan mediante un equipo de postventa. Igualmente, tengamos un equipo concreto o no para estos temas, implementar lafunción de service desk e incorporar los procesos de gestión de incidencias y de gestión de problemas puede reportar mejoras de productividad sustanciales, además de mayor visibilidad en este proceso. Obviamente en este punto podemos aplicar también Kanban para beneficiarnos de sus bondades.
  • Otras funciones de ITIL como la gestión técnica o la gestión de aplicacionestambién son fundamentales para el desempeño de un equipo en el largo plazo. Scrum no hace referencia a estos aspectos, sin embargo, en ITIL encontramos un marco de referencia.

Aunque las posibilidades son múltiples y sé que se me quedan muchas en el tintero, por no hablar de profundizar en mayor medida y con mayor detalle en las ya expuestas, espero haber cumplido con mi objetivo y haber resuelto las principales dudas que tenían en mente aquellos que alguna vez me han preguntado por el tema.

Obviamente estoy abierto a responder a todas las dudas que me dejéis en la forma de comentarios, así como a entablar un constructivo debate con aquellos que no compartan mi visión sobre la compatibilidad entre Scrum e ITIL. 😉

Gestión de Proyectos por Cadena Crítica (CCPM)

  • admin 

Fuente: http://en.wikipedia.org/wiki/Critical_chain_project_management

Critical chain project management (CCPM) is a method of planning and managing projects that puts the main emphasis on the resources required to execute project tasks. It was developed by Eliyahu M. Goldratt.

This is in contrast to the more traditional critical path and PERT methods, which emphasize task order and rigid scheduling. A Critical Chain project network will tend to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly switch between tasks and task chains to keep the whole project on schedule.

Origins

Critical chain project management is based on methods and algorithms derived from Theory of Constraints. The idea of CCPM was introduced in 1997 in Eliyahu M. Goldratt’s book, Critical Chain. Application of CCPM has been credited with achieving projects 10% to 50% faster and/or cheaper than the traditional methods (i.e. CPM, PERT, Gantt, etc.) developed from 1910 to 1950s.

From numerous studies by Standish Group and others as of 1998 for traditional project management methods, only 44% of projects typically finish on time, projects usually complete at 222% of the duration originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope (technical content delivered), and 30% are cancelled before completion.[citation needed]

These traditional statistics are mostly avoided through CCPM. Typically, CCPM case studies report 95% on-time and on-budget completion when CCPM is applied correctly. Mabin and Balderstone,[1] in their meta-analysis of seventy-eight published case studies, found that implementing Critical Chain resulted in mean reduction in lead-times of 69%, mean reduction of cycle-times of 66%, mean improvement in due date performance of 60%, mean reduction in inventory levels of 50% and mean increases in revenue / throughput of 68%.

Details

With traditional project management methods, 30% of the lost time and resources are typically consumed by wasteful techniques such as bad multi-tasking, student syndrome, In-box delays, and lack of prioritization.

In project management, the critical chain is the sequence of both precedence– and resource-dependent terminal elements that prevents a project from being completed in a shorter time, given finite resources. If resources are always available in unlimited quantities, then a project’s critical chain is identical to its critical path.

Critical chain is used as an alternative to critical path analysis. The main features that distinguish the critical chain from the critical path are:

  1. The use of (often implicit) resource dependencies. Implicit means that they are not included in the project network but have to be identified by looking at the resource requirements.
  2. Lack of search for an optimum solution. This means that a «good enough» solution is enough because:
    1. As far as is known, there is no analytical method of finding an absolute optimum (i.e. having the overall shortest critical chain).
    2. The inherent uncertainty in estimates is much greater than the difference between the optimum and near-optimum («good enough» solutions).
  3. The identification and insertion of buffers:
    • project buffer
    • feeding buffers
    • resource buffers. (Most of the time it is observed that companies are reluctant to give more resources)
  4. Monitoring project progress and health by monitoring the consumption rate of the buffers rather than individual task performance to schedule.

CCPM planning aggregates the large amounts of safety time added to tasks within a project into the buffers in order to protect due-date performance, and to avoid wasting this safety time throughbad multitaskingstudent syndromeParkinson’s Law and poorly synchronized integration.

Critical chain project management uses buffer management instead of earned value management to assess the performance of a project. Some project managers feel that the earned value management technique is misleading, because it does not distinguish progress on the project constraint (i.e. on the critical chain) from progress on non-constraints (i.e. on other paths). Event chain methodology can be used to determine a size of project, feeding, and resource buffers.

Planning

A project plan is created in much the same fashion as with critical path. The plan is worked backward from a completion date with each task starting as late as possible.

A duration is assigned to each task. Some software implementations add a second duration: one a «best guess,» or 50% probability duration, and a second «safe» duration, which should have higher probability of completion (perhaps 90% or 95%, depending on the amount of risk that the organization can accept). Other software implementations go through the duration estimate of every task and remove a fixed percentage to be aggregated into the buffers.

Resources are assigned to each task, and the plan is resource leveled, using the aggressive durations. The longest sequence of resource-leveled tasks that lead from beginning to end of the project is then identified as the critical chain. The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero.

Recognizing that tasks are more likely to take more rather than less time due to Parkinson’s lawStudent syndrome, or other reasons, «buffers» are used to monitor project schedule and financial performance. The «extra» duration of each task on the critical chain—the difference between the «safe» durations and the 50% durations—is gathered together in a buffer at the end of the project. In the same way, buffers are gathered at the end of each sequence of tasks that feed into the critical chain. It is the date at the end of the project buffer that is communicated to external stakeholders as the delivery date.

Finally, a baseline is established, which enables financial monitoring of the project.

An alternate duration-estimation methodology uses probability-based quantification of duration using Monte Carlo simulation. In 1999, a researcher[who?] applied simulation to assess the impact of risks associated with each component of project work breakdown structure on project duration, cost and performance. Using Monte Carlo simulation, the project manager can apply different probabilities for various risk factors that affect a project component. The probability of occurrence can vary from 0% to 100% chance of occurrence. The impact of risk is entered into the simulation model along with the probability of occurrence. The Monte Carlo simulation runs over 10,000 iterations and provides a density graph illustrating the overall probability of risk impact on project outcome.

Execution

When the plan is complete and the project ready to kick off, the project network is fixed and the buffers size is «locked» (i.e. their planned duration may not be altered during the project), because they are used to monitor project schedule and financial performance.

With no slack in the duration of individual tasks, the resources are encouraged to focus on the task at hand to complete it and hand it off to the next person or group. The objective here is to eliminate bad multitasking. This is done by providing priority information to all resources. An analogy is drawn in the literature with a relay race. Each element on the project is encouraged to move as quickly as they can: when they are running their «leg» of the project, they should be focused on completing the assigned task as quickly as possible, with minimization of distractions and multitasking. In some case studies, actual batons are reportedly hung by the desks of people when they are working on critical chain tasks so that others know not to interrupt. The goal, here, is to overcome the tendency to delay work or to do extra work when there seems to be time. The CCPM literature contrasts this with «traditional» project management that monitors task start and completion dates. CCPM encourages people to move as quickly as possible, regardless of dates.

Because task durations have been planned at the 50% probability duration, there is pressure on the resources to complete critical chain tasks as quickly as possible, overcoming student’s syndrome and Parkinson’s Law.

Monitoring

Monitoring is, in some ways, the greatest advantage of the Critical Chain method. Because individual tasks will vary in duration from the 50% estimate, there is no point in trying to force every task to complete «on time;» estimates can never be perfect. Instead, we monitor the buffers that were created during the planning stage. A fever chart or similar graph can be easily created and posted to show the consumption of buffer as a function of project completion. If the rate of buffer consumption is low, the project is on target. If the rate of consumption is such that there is likely to be little or no buffer at the end of the project, then corrective actions or recovery plans must be developed to recover the loss. When the buffer consumption rate exceeds some critical value (roughly: the rate where all of the buffer may be expected to be consumed before the end of the project, resulting in late completion), then those alternative plans need to be implemented.

Métrica V3

Fuente: http://es.wikipedia.org/wiki/M%C3%89TRICA

Fuente: http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P60085901274201580632&langPae=se

MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistemas de información. Promovida por el Ministerio de Administraciones Públicas del Gobierno de España para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology – Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination).

Elementos fundamentales

  • Procesos
  • Interfaces
  • Técnicas y Prácticas
  • Roles o Perfiles

Procesos principales de MÉTRICA

Al igual que ISO/IEC 12207, MÉTRICA está orientada al proceso y, en su versión 3, estos procesos son:

  • Planificación de Sistemas de Información (PSI).
  • Desarrollo de Sistemas de Información (DSI). Debido a su complejidad, está a su vez dividido en cinco procesos:
    • Estudio de Viabilidad del Sistema (EVS).
    • Análisis del Sistema de Información (ASI).
    • Diseño del Sistema de Información (DSI).
    • Construcción del Sistema de Información (CSI).
    • Implantación y Aceptación del Sistema (IAS).
  • Mantenimiento de Sistemas de Información (MSI).

Interfaces de MÉTRICA

MÉTRICA, en su versión 3, proporciona también cuatro interfaces que definen actividades orientadas a la mejora y perfeccionamiento de los procesos principales para garantizar la consecución del objetivo del desarrollo.

  • Gestión de proyectos (GP).
  • Seguridad (SEG).
  • Aseguramiento de la Calidad (CAL).
  • Gestión de la Configuración (GC).

Técnicas de MÉTRICA

MÉTRICA, en su versión 3, distingue entre:

Perfiles de MÉTRICA

MÉTRICA establece los siguientes perfiles para los participantes en el proceso de desarrollo de un sistema de información:

  • Directivo (Comité de Dirección, Directores de Usuarios,…).
  • Jefe de Proyecto (Responsable de Implantación, Responsable de Seguridad,…).
  • Consultor (Consultor Informático, Técnico de Sistemas).
  • Analista (Analista, Administrador de Bases de Datos,…).
  • Programador.

ITIL

  • admin 

Fundamentos de la Gestión de TI

fuente: http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

fuente: http://itil.osiatis.es/Curso_ITIL/

fuente: http://www.itil-officialsite.com/

Las tecnologías de la información son tan antiguas como la historia misma y han jugado un importante papel en la misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestión se han convertido en una herramienta imprescindible y clave para empresas e instituciones.

La información es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su vez genera ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debe considerarse como una herramienta más entre muchas otras.

Hasta hace poco las infraestructuras informáticas se limitaban a dar servicios de soporte y de alguna forma eran equiparables con el otro material de oficina: algo importante e indispensable para el correcto funcionamiento de la organización pero poco más.

Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan generalmente una parte sustancial de los procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuas redes de información: sirva de ejemplo la Banca Electrónica.

Los objetivos de una buena gestión de servicios TI han de ser:

  • Proporcionar una adecuada gestión de la calidad
  • Aumentar la eficiencia
  • Alinear los procesos de negocio y la infraestructura TI
  • Reducir los riesgos asociados a los Servicios TI
  • Generar negocio

ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:

  • Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos
  • El establecimiento de estrategias para la gestión operativa de la infraestructura TI

¿Qué es ITIL

Information Technology Infraestructure Library.

Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido en el estándar mundial de de facto en la Gestión de Servicios Informáticos. Iniciado como una guía para el gobierno de UK, la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización.

ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la Informática para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos de mantenimiento y operaciones.

A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del tiempo y del coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados, con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.

ITIL fue producido originalmente a finales de 1980 y constaba de 10 libros centrales cubriendo las dos principales áreas de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30 libros complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del negocio. A partir del año 2000, se acometió una revisión de la biblioteca. En esta revisión, ITIL ha sido reestructurado para hacer más simple el acceder a la información necesaria para administrar sus servicios. Los libros centrales se han agrupado en dos, cubriendo las áreas de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la duplicidad y mejorar la navegación. El material ha sido también actualizado y revisado para un enfoque conciso y claro.

Críticas a ITIL

ITIL ha recibido críticas de varios frentes. Entre ellas:

  • El hecho de que muchos defensores de ITIL parecen creer que es un marco holístico y completo para el gobierno de TI.
  • Su tendencia a convertirla en una religión.

Como señala Jan van Bon (autor y editor de muchas publicaciones de Gestión de Servicios de TI):

Hay mucha confusión sobre ITIL, procedente de todo tipo de malentendidos sobre su naturaleza. ITIL, como afirma la OGC, es un conjunto de buenas prácticas. La OGC no afirma que dichas mejores prácticas describan procesos puros, ni tampoco que ITIL sea un marco diseñado como un modelo coherente. Eso es lo que la mayoría de sus usuarios hacen de ella, probablemente porque tienen una gran necesidad de dicho modelo.6

El columnista CIO Magazine Dean Meyer también ha expuesto algunos puntos de vista cautelosos sobre ITIL,7 incluyendo cinco trampas típicas tales como «convertirse en esclavo de definiciones desactualizadas» y «dejar que ITIL se convierta en religión». Como Meyer señala, ITIL «no describe el abanico completo de procesos necesarios para ser líderes. Se centra en […] gestionar servicios actuales.»

La calidad de los volúmenes de la biblioteca se considera desigual. Por ejemplo, van Herwaarden y Grift señalan que «la consistencia que caracterizaba los procesos de soporte al servicio […] se pierde en gran medida en los libros de entrega de servicio.»8

Todas estas manifestaciones acerca de ITIL provienen de compañias que en un momento dado han logrado entender que `para alcanzar objetivos de manera clara es necesario practicar ciertas practicas que cumplan con ese objetivo y los resultados demostrados son beneficos para quien los desarrolla y para quien hace uso de este entorno.

Visión general de la Biblioteca de Infraestructura de TI version 2 (ITIL v2)

La biblioteca de infraestructura de TI (ITIL) toma este nombre por tener su origen en un conjunto de libros, cada uno dedicado a una práctica específica dentro de la gestión de TI. Tras la publicación inicial de estos libros, su número creció rápidamente (dentro la versión 1) hasta unos 30 libros. Para hacer a ITIL más accesible (y menos costosa) a aquellos que deseen explorarla, uno de los objetivos del proyecto de actualización ITIL versión 2 fue agrupar los libros según unos conjuntos lógicos destinados a tratar los procesos de administración que cada uno cubre. De esta forma, diversos aspectos de los sistemas de TIC, de las aplicaciones y del servicio se presentan en conjuntos temáticos. Actualmente existe la nueva versión ITIL v3 que fue publicada en mayo de 2007.

Aunque el tema de Gestión de Servicios (Soporte de Servicio y Provisión de Servicio) es el más ampliamente difundido e implementado, el conjunto de mejores prácticas ITIL provee un conjunto completo de prácticas que abarca no sólo los procesos y requerimientos técnicos y operacionales, sino que se relaciona con la gestión estratégica, la gestión de operaciones y la gestión financiera de una organización moderna.

Los ocho libros de ITIL y sus temas son:

Gestión de Servicios de TI,

1. Mejores prácticas para la Provisión de Servicio
2. Mejores prácticas para el Soporte de Servicio
Otras guías operativas

3. Gestión de la infraestructura de TI
4. Gestión de la seguridad
5. Perspectiva de negocio
6. Gestión de aplicaciones
7. Gestión de activos de software

Para asistir en la implementación de prácticas ITIL, se publicó un libro adicional con guías de implementación (principalmente de la Gestión de Servicios):

8. Planeando implementar la Gestión de Servicios

Adicional a los ocho libros originales, más recientemente se añadió una guía con recomendaciones para departamentos de TIC más pequeños:

9. Implementación de ITIL a pequeña escala

  • Soporte de Servicio

El libro de Soporte de Servicio se ocupa de asegurar que el Usuario tenga acceso a los servicios apropiados que soporten las funciones de negocio. Los temas que se tratan en el libro son:

Centro de Servicio al Usuario
Gestión del Incidente
Gestión del Problema
Gestión de Configuración
Gestión del Cambio
Gestión de la Entrega
  • Provisión de Servicio

El libro de Provisión de Servicio analiza qué servicio requiere el negocio del proveedor (entendiendo como proveedor la organización interna o externa que provee el servicio de TI), para ofrecer un soporte adecuado a los Usuarios y/o Clientes de negocio. El libro cubre los siguientes temas:

Gestión del Nivel de Servicio
Gestión Financiera de Servicios TI
Gestión de la Capacidad
Gestión de la Continuidad del Servicio de TI
Gestión de la Disponibilidad

ITIL v3

En ITIL v3 reestructura el manejo de los temas para consolidar el modelo de «ciclo de vida del servicio» separando y ampliando algunos subprocesos hasta convertirlos en procesos especializados. Esta modificación responde a un enfoque empresarial para grandes corporaciones que utilizan ampliamente ITIL en sus operaciones y aspira a consolidar el modelo para conseguir aún mejores resultados. Es por ello que los especialistas recomiendan que empresas emergentes o medianas no utilicen ITIL v3 si no cuentan con un modelo ITIL consolidado y aspiran a una expansión a muy largo plazo. ITIL v3 consta de 5 libros basados en el ciclo de vida del servicio:

1. Estrategia del Servicio
2. Diseño del Servicio
3. Transición del Servicio
4. Operación del Servicio
5. Mejora Continua del Servicio
  • Estrategia del Servicio

Se enfoca en el estudio de mercado y posibilidades mediante la búsqueda de servicios innovadores que satisfagan al cliente tomando en cuenta la real factibilidad de su puesta en marcha. Asi mismo se analizan posibles mejoras para servicios ya existentes. Se verifican los contratos con base en las nuevas ofertas de proveedores antiguos y posibles nuevos proveedores, lo que incluye la renovación o revocación de los contratos vigentes.

Procesos

  1. Gestión Financiera
  2. Gestión del Portafolio
  3. Gestión de la Demanda

Cambios en la versión 2011

Los conceptos dentro de la publicación se han aclarado, sin necesidad de cambiar el mensaje general. La publicación actualizada incluye una orientación más práctica y con más ejemplos.

  • Financial Management for IT services (Gestión Financiera de TI)

La gestión financiera de TI ha ampliado para incluir algunos de los elementos clave de la ITIL publicaciones anteriores que habían sido excluidos en la edición 2007 de la Estrategia del Servicio – tales como contabilidad, elaboración de presupuestos y de cargos.

  • Business Relationship Management (Gestión de Relaciones del Negocio)

Este es un nuevo proceso que se asemeja al existente en la ISO 20.000. Se hace una diferenciación para los distintos proveedores de servicio: tipo I, II y III . Se brinda una explicación diferente para cada tipo de proveedor.

  • Governance (Gobierno)

Ahora hay más detalles sobre el concepto de Gobierno, incluida una definición más completa de su significado, la diferencia entre el gobierno y gestión, un marco de gobierno, y cómo la gestión del servicio se relaciona con el gobierno.

  • Cloud Computing (Computación en la nube)

Se ha incluído en qué forma la gestión de servicios se ve afectada por la aparición de la computación en la nube. Se agregó un nuevo apéndice que cubre específicamente la estrategia de servicio y la nube: características, tipos, tipos de servicio, y los componentes de la arquitectura de nube.

Federico, Ricardo. «Actualizacion ITIL V3 2011: Estrategia del Servicio» (en español). BITCompany. Consultado el 09/10/2011.

  • Diseño del Servicio

Una vez identificado un posible servicio el siguiente paso consiste en analizar su viabilidad. Para ello se toman factores tales como infraestructura disponible, capacitación del personal y se planifican aspectos como seguridad y prevención ante desastres. Para la puesta en marcha se toman en consideración la reasignación de cargos (contratación, despidos, ascensos, jubilaciones, etc), la infraestructura y software a implementar.

Procesos

  1. Gestión del Catálogo de Servicios
  2. Gestión de Niveles de Servicio
  3. Gestión de la Disponibilidad
  4. Gestión de la Capacidad
  5. Gestión de la Continuidad de los Servicios de TI
  6. Gestión de Proveedores
  7. Gestión de la Seguridad de Información
  8. Coordinación del Diseño (nuevo en la versión 2011)

Cambios en la versión 2011

Las principales modificaciones del libro de ITIL V3 Diseño del Servicio en su versión 2011 incluye: un cambio a los denominados 5 aspectos del diseño y primordialmente la inclusión de un nuevo proceso de Coordinación del Diseño. De esta manera esta fase incluye ahora 8 procesos, en lugar de 7.

Nuevo Proceso ITIL V3 2011: Coordinación del Diseño (Design Coordination Process)

Se adicionó este proceso para hacer más claro el flujo de actividades en el ciclo de vida del diseño. El propósito del proceso de Coordinación del Diseño es garantizar que las metas y los objetivos de la etapa de diseño del servicio entregando y manteniendo un punto único de coordinación y control de todas las actividades y procesos dentro de esta etapa del ciclo de vida de servicio. Las salidas del proceso de coordinación del diseño son potencialmente:

  • Diseño de servicios integrado y consistente a través del SDP (paquete de diseño del servicio)
  • Revisión de la arquitectura empresarial
  • Revisión del sistema de gestión
  • Revisión de las métricas y métodos de medición
  • Revisión de procesos
  • Actualización del Portafolio de Servicios
  • Actualización de los registros de cambios

Federico, Ricardo. «Actualización ITIL V3 2011: Diseño del Servicio» (en español). BITCompany. Consultado el 28/10/2011.

  • Transición del Servicio

Antes de poner en marcha el servicio se deben realizar pruebas. Para ello se analiza la información disponible acerca del nivel real de capacitación de los usuarios, estado de la infraestructura, recursos IT disponibles, entre otros. Luego se prepara un escenario para realizar pruebas; se replican las bases de datos, se preparan planes de rollback (reversión) y se realizan las pruebas. Luego de ello se limpia el escenario hasta el punto de partida y se analizan los resultados, de los cuales dependerá la implementación del servicio. En la evaluación se comparan las expectativas con los resultados reales.

Procesos

  1. Gestión de la Configuración y Activos
  2. Gestión del Cambio
  3. Gestión del Conocimiento
  4. Planificación y Apoyo a la Transición
  5. Gestión de Release y Despliegue
  6. Gestión Validación y Pruebas
  7. Evaluación (Evaluación del cambio)

Cambios en la versión 2011

En la edición ITIL V3 2011 del libro de Transición del Servicio, se realizaron modificaciones y aclaraciones, a efectos de mejorar el entendimiento de los conceptos.
Se aclaró la estructura , el contenido y las relaciones entre el Sistema de Gestión de Configuraciones (CMS) y el Sistema de Gestión del Conocimiento del Servicio (SKMS) para hacer más entendibles los conceptos.

Se incorporó un nuevo contenido relacionado con la forma que que debe ser usado un Requerimiento de Cambio (RFC).

El proceso de Evaluación (que no se ve en fundamentos sino en el Intermediate RCV) fue renombrado como Evaluación del cambio. Se modificó su propósito y alcance, a efectos de clarificar cuando debe ser usado.

El proceso de Gestión de Activos y Configuraciones del Servicio tiene información adicional y se mejoraron los flujos de interacción con otros procesos, incluidos Gestión de Cambio, Gestión de Versiones y Entrega, y Evaluación del Cambio.

Por último se mejoraron las descripciones de los Elementos de Configuración (CI) , Sistema de Gestión de Configuraciones (CMS) y el Sistema de Gestión del Conocimiento del Servicio (SKMS)

Federico, Ricardo. «Actualización ITIL V3 2011: Transición del Servicio» (en español). BITCompany.

  • Operación del Servicio

En este punto se monitoriza activa y pasivamente el funcionamiento del servicio, se registran eventos, incidencias, problemas, peticiones y accesos al servicio.

Procesos

  1. Gestión de Incidentes
  2. Gestión de Problemas
  3. Cumplimiento de Solicitudes
  4. Gestión de Eventos
  5. Gestión de Accesos
  • Mejora Continua del Servicio

Se utilizan herramientas de medición y feedback para documentar la información referente al funcionamiento del servicio, los resultados obtenidos, problemas ocasionados, soluciones implementadas, etc. Para ello se debe verificar el nivel de conocimiento de los usuarios respecto al nuevo servicio, fomentar el registro e investigación referentes al servicio y disponer de la información al resto de los usuarios.