Dirección y gestión de proyectos

• Temporal: es decir, un proyecto tiene una fecha de inicio y una fecha de finalización. Esta característica no es aplicable al producto, servicio o resultado creado por el proyecto, el cual puede no cumplir esta condición.

• Único: aunque un proyecto puede ser similar a otros proyectos, el trabajo utilizado para crear el entregable del proyecto es único. Por lo tanto, el proyecto dará lugar a un producto, servicio o resultado único.

• No repetitivo: como ampliación del punto anterior, el hecho de que un proyecto sea único también lo hace no repetitivo, aunque algunos de los elementos del proyecto sí lo sean.

• De elaboración progresiva: en un estado inicial, un proyecto puede no tener información suficiente. A medida que el proyecto avanza, la información que se tiene es más clara y conocida. El proyecto va revisándose y/o modificándose y los objetivos se conocen mejor.

• Propósito: un proyecto se realiza para satisfacer un objetivo específico y cubrir una necesidad real. Un proyecto no debería ser llevado a cabo por el mero hecho de disponer de fondos.

• Multidisciplinario: involucra recursos y habilidades diferentes para lograr los objetivos.

• Recursos limitados: por lo tanto, supone tener costes directos, indirectos y de oportunidad para la organización.

• Las operaciones son repetitivas y continuas, mientras que los proyectos son temporales y únicos.

• Una operación persigue el incremento del rendimiento de las actividades y una mejora de la eficiencia a partir de la realización de las actividades una y otra vez. En cambio, el proyecto pretende lograr la máxima eficiencia en un producto único.

• Las operaciones son permanentes, es decir, pueden ejecutarse hasta el infinito. En cambio, los proyectos acaban cuando se han logrado los objetivos y se cierran formalmente.

• Las operaciones ocupan una parte de la empresa de manera especializada y con una orientación funcional, mientras que el equipo de un proyecto se constituye específicamente para el proyecto.

• Los realizan personas.

• Están restringidos por el uso de recursos.

• Se planifican, ejecutan y controlan.

• Se llevan a cabo para cumplir los objetivos estratégicos de una organización.

• iniciación,

• planificación,

• ejecución,

• seguimiento y control,

• cierre.

• Identificar los requerimientos.

• Abordar las necesidades, preocupaciones y expectativas de los interesados (stakeholders) cuando se planifica o ejecuta el proyecto.

• Preparar, mantener y llevar a cabo las comunicaciones entre los interesados del proyecto.

• Gestionar a los interesados del proyecto hacia los objetivos de este y su resultado final.

• Equilibrar y gestionar las restricciones como el alcance, la calidad, el tiempo, el presupuesto, los recursos y los riesgos.

• Dado que todo proyecto tiene un propósito definido, la cuantificación de este propósito será lo que denominemos alcance, el cual determinará el éxito o no del proyecto. El alcance del proyecto, como declaración explícita de lo que se hará dentro del proyecto, puede contener inclusiones (lo que se realizará) y exclusiones (lo que no se realizará) en el proyecto.

• Los resultados del proyecto se expresarán en términos de entregables. Un entregable es un producto mesurable y que cumple con la calidad especificada para ejecutar una tarea o un proyecto. Un entregable puede ser tangible (por ejemplo, una aplicación, documentación, etc.) o intangible (por ejemplo, una idea).

• La calidad en los entregables será el conjunto de características inherentes que cumplen con los requisitos. La calidad tiene una dimensión objetiva (medible, conforme a las normas y especificaciones) y una dimensión subjetiva (satisfacción del cliente y/o usuario, o la calidad percibida).

• Para llevar a cabo un proyecto se requerirán recursos. Estos pueden ser tanto humanos, como materiales e internos o externos a la organización, y conformarán el coste del proyecto.

• El grupo de personas especialmente constituido para llevar a cabo el proyecto es el que denominaremos equipo de proyecto.

• El tiempo es el límite temporal en el que tiene lugar el proyecto, desde su inicio hasta su finalización.

• En todo proyecto, dada su característica de único, existe incertidumbre respecto al logro de los objetivos. Esta incertidumbre se transforma en riesgos que durante la ejecución del proyecto deben ser gestionados con el fin de minimizar (en caso de riesgos negativos para el proyecto) o maximizar (en caso de riesgos positivos para el proyecto) el impacto de los mismos.

• Puesto que todos los proyectos se llevan a cabo a partir de un encargo, el cliente es a quien va dirigido el resultado del proyecto y quien aprueba los objetivos y las modificaciones del mismo. Dentro del cliente encontraremos a los usuarios, que serán quienes utilicen el resultado del proyecto. Ambos, cliente y usuarios, tienen la necesidad o el objetivo de negocio que justifican la realización del proyecto.

La triple restricción y sus interrelaciones

Triple restricción ampliada

• Autonomía: el deseo de dirigir nuestras propias vidas. El equipo necesita autonomía sobre el qué, el cómo y el cuándo de las tareas.

• Propósito: el anhelo de que lo que estamos haciendo sea por un propósito. Tradicionalmente, las empresas han considerado el propósito como algo prescindible, pero cada vez hay más empresas que se comprometen con un propósito.

• Maestría: la necesidad de ser mejores en algo que nos importa.

Evolución del lanzamiento de los nuevos modelos de VW Golf

• Project management body of knowledge (PMBOK®)

• ISO 21500

• Projects in controlled environments 2 (PRINCE2)

• Goal directed project management (GDPM)

• Metodologías ágiles

• Simples: la relación causa-efecto existe, es predecible y se repite.

• Complicados: la relación causa-efecto existe, pero no es evidente y se requiere experiencia.

• Complejos: la relación causa-efecto no es obvia y los resultados no son predecibles.

• Caóticos: no se puede observar una relación de causa-efecto.

Marco de Cynefin

• Proyectos simples: tanto los requerimientos como la tecnología requeridos por la ejecución están definidos y el proyecto se puede gestionar con una metodología simple. Podríamos poner como ejemplo un proyecto de ingeniería en el que se conocen tanto los requerimientos como la tecnología para el desarrollo. En estos casos, se recomienda utilizar metodologías estandarizadas predecibles, basadas en mejores prácticas. El ciclo de vida de esta clase de proyectos se denomina waterfall, puesto que las fases son consecutivas y forman una cascada.

• Proyectos complicados: cuando no se conoce del todo la tecnología, los requerimientos o ambos. Podría tratarse, por ejemplo, de un proyecto de ingeniería en el que los requerimientos son conocidos, pero hay que utilizar una nueva tecnología. En este caso, es posible utilizar igualmente metodologías estandarizadas predecibles, pero será necesario basarse en buenas prácticas, es decir, dejar cierto grado de libertad. Lo mismo habrá que hacer respecto al alcance, ya que los requerimientos o la tecnología no están definidos del todo. El tipo de ciclo de vida que mejor se adapta a estos proyectos se denomina fast tracking y consiste en un solapamiento de las fases que permite mantener este grado de libertad del alcance.

• Proyectos complejos: muchos proyectos caen en esta zona, en la cual los requerimientos y la tecnología están ligeramente definidos, pero el grado de incertidumbre es muy elevado. En estos casos, un alto grado de retrospectivas, como las metodologías emergentes ágiles, es lo mejor para ir guiando el proyecto en este grado de incertidumbre y riesgo. El desarrollo de software es un buen ejemplo de proyecto complejo. El ciclo de vida es una iteración de las diferentes fases, en la que hay un resultado en cada iteración.

• Proyectos caóticos: cuando el grado de incertidumbre de los requerimientos y de la tecnología son elevados, el desarrollo del proyecto se convierte en un caos y el éxito del proyecto será más una cuestión de suerte.

Tipología de proyectos por complejidad relacionada con el ciclo de vida

• Modelos de medición del beneficio: utilización de modelos económicos para predecir el valor del proyecto una vez completo.

• Modelos de optimización apremiada: utilización de diferentes fórmulas y algoritmos para determinar la mejor alternativa.

• Valor actual (VA): permite calcular el valor presente del total de los beneficios del proyecto, teniendo en cuenta una tasa de interés fijada de manera previa.

• Valor actual neto (VAN): permite calcular el valor presente del total de los beneficios del proyecto menos los costes del mismo. El cálculo del VAN de todos los proyectos actuales de la empresa permite compararlos. Desde el punto de vista estrictamente financiero, el proyecto con el VAN más elevado será la mejor inversión.

• Tasa de retorno de la inversión (TIR): la tasa en la que el valor actual neto tiene un valor cero equivale al interés que nos daría el proyecto como inversión financiera. En este caso, y de manera comparativa, el proyecto con una tasa superior será una mejor inversión.

• Periodo de recuperación de la inversión (payback) : tiempo que tarda la empresa en recuperar la inversión efectuada en el proyecto. Es el modelo más simple y se aplica de manera habitual como primer criterio de selección.

• Screening: revisión de los beneficios de un proyecto ante una lista de criterios elaborada por la empresa (por ejemplo, el esquema anterior de criterios para valorar proyectos informáticos se podría convertir fácilmente en una lista de control o checklist para una revisión tipo screening).

• Scoring: se adjudica un peso específico a una serie de criterios y se valora la medida en la que cada proyecto presentado cumple con los criterios definidos. Los métodos de scoring sirven para establecer prioridades dentro de una cartera de propuestas.

• Coste de la oportunidad. Esto es, el valor de la siguiente mejor alternativa como resultado de elegir una alternativa. Dicho de otro modo, elegir la mejor opción e ignorar la siguiente mejor. Por ejemplo, si dentro de todos los proyectos, el proyecto A es la mejor opción y el proyecto B es la segunda mejor opción, el coste de la oportunidad de elegir el proyecto A es el valor de los beneficios del proyecto B.

• Tiene que alinearse con la estrategia y los objetivos de la organización.

• Debe proporcionar un valor o beneficio de negocio que sea medible o verificable al acabar el proyecto.

• Se tiene que apoyar en métricas cuantitativas, particularmente financieras, que permitan obtener el retorno de la inversión y calcular todos los costes y beneficios de la inversión.

• Tiene que demostrar la viabilidad técnica, organizativa y de gestión del mismo proyecto.

Fuente: Rodríguez, García Mínguez y Lamarca (2007).

• Los objetivos y los resultados que se esperan del proyecto, de modo que permitan la evaluación del éxito o fracaso del proyecto, tal y como se han descrito en los módulos anteriores.

• El alcance del proyecto que determina lo que se va a realizar (inclusiones) y lo que no (exclusiones).

• Los hitos principales del proyecto coincidentes con puntos de decisión, entregables, término de etapas, etc. Una definición más detallada de hito se establece en los apartados siguientes del módulo.

• Los mecanismos de control del alcance del proyecto y de gestión de cambios en este.

• La implicación de los diferentes interesados participantes en el proyecto, sus roles y sus responsabilidades.

• La definición de las actividades del proyecto, es decir, las tareas o grupos de tareas de las que se compone, los recursos técnicos y humanos necesarios y el resultado o hito que se debe obtener haciendo estas actividades.

• El calendario de trabajo, con los tiempos de ejecución según la fecha de inicio y la fecha de término de cada una de las actividades y de cada uno de los hitos.

• La organización y el equipo asignado al proyecto, con la matriz de roles y responsabilidades para los diferentes hitos y actividades.

• Cómo, cuándo y porqué comunicaremos la información relativa al proyecto.

• Relación de las compras y subcontrataciones que serán necesarias durante el transcurso del proyecto y sus suposiciones y restricciones.

• El presupuesto del proyecto, con las estimaciones de inversión y coste presupuestadas a partir del consumo de recursos, su previsión de evolución a lo largo del tiempo de duración del proyecto y la previsión de beneficios esperados.

• Los riesgos identificados de manera previa a la implantación del proyecto, su posible impacto sobre el plan de proyecto y el plan de gestión de estos riesgos.

• La calidad de los trabajos llevados a cabo, según los resultados funcionales y operativos esperados y la definición de las condiciones y los principios de aceptación de los mismos.

Proceso de recogida de requisitos segun el PMBOK®

• Entrevistas: ya sean formales o informales, con el fin de obtener información de los interesados.

• Grupos de opinión: formados por interesados cualificados y expertos que recogen información acerca de las expectativas y del producto o servicio a proponer.

• Talleres: sesiones en las que los interesados trabajan conjuntamente en definir los requerimientos del producto.

• Técnicas de grupo creativas: tales como brainstorming, Delphi, mind mapping, análisis multicriterio, diagramas de afinidad, etc.

• Técnicas de decisión en grupo: estas técnicas pueden ayudar a generar, clasificar y priorizar los requerimientos del producto utilizando varios métodos tales como «por unanimidad», «por mayoría», «por pluralidad», «dictatorial».

• Otros: tales como cuestionarios y encuestas, prototipos, benchmarking, documentos de análisis, etc.

• Documento de requisitos: el objetivo de este documento es detallar a un nivel coherente los requerimientos recogidos y toda la información necesaria. El documento puede incluir lo siguiente:

  • necesidad del negocio con sus correspondientes limitaciones,

  • propósito del proyecto,

  • objetivos del proyecto.

• Matriz de trazabilidad de los requisitos: se trata de una tabla (o tabla resumen del documento de requisitos) que describe y vincula un requerimiento con su origen y lo rastrea a lo largo del ciclo de vida del proyecto. Se utiliza para vincular cada requerimiento con cada necesidad de negocio o con los objetivos de proyecto. También se puede emplear posteriormente para rastrear los requerimientos con los entregables de la EDT, los escenarios de prueba o los solicitantes.

• (M) must have: requerimiento crítico para el éxito del proyecto.

• (S) should have: requerimiento importante pero no crítico para la entrega del proyecto.

• (C) could have: requerimiento deseable pero no necesario.

• (W) won’t have: requerimiento acordado que no es crítico ni necesario para cumplir con los objetivos del proyecto, con lo que no se planificará dentro del proyecto.

Proceso de definición del alcance según el PMBOK®

• Descripción actualizada del producto, servicio o resultado y, frecuentemente como anexo, la documentación de requisitos.

• Criterios de aceptación de los productos. El conjunto de condiciones requeridas que los entregables del proyecto tienen que cumplir para ser aceptados.

• Entregables del proyecto, tanto si son productos como servicios, componentes del proyecto o material complementario (por ejemplo, documentación).

• Exclusiones del proyecto. Por diferentes razones, muchos directores de proyectos o compañías de servicio no se atreven a incluir este apartado, que es extremadamente crítico. Se trata de una descripción argumentada de lo que no se hará y porqué, que ayuda de una manera extraordinaria a gestionar las expectativas de clientes e interesados.

• Limitaciones y asunciones. Son las condiciones organizativas, de calendario o de presupuesto bajo las cuales se llevará a cabo el proyecto y, si procede, las condiciones para modificarlo. Actualmente, muchos proyectos se hacen bajo presupuestos cerrados, pero se establecen condiciones bajo las cuales el presupuesto se puede revisar. O, por el contrario, se hacen por administración (horas invertidas), pero se establecen unos productos mínimos que se han de obtener y unas condiciones para sustituirlos.

Crear la estructrura del detalle de trabajo (EDT) según el PMBOK®

Ejemplo de EDT

• La EDT comprende el 100% del alcance del proyecto. Todo entregable que no esté representado en la EDT no forma parte del proyecto.

• El primer nivel de la EDT es suficiente para llevar a cabo el proyecto, es decir, los entregables 1-3.

• Los elementos inferiores de un nivel equivalen al 100% del nivel. Por ejemplo, 1.1 y 1.2 equivalen al 100% del entregable 1.

• El último nivel se denomina paquete de trabajo (work package) y esto es lo que nos va a ayudar a costear, controlar y programar. También nos permite asignar un responsable.

• El nivel de detalle de los paquetes de trabajo variará dependiendo del tamaño y la complejidad del proyecto.

• No es un listado de tareas: la EDT del proyecto comprende el alcance, el qué, no cómo tenemos que hacer las cosas. Por lo tanto, no es un listado de tareas, sino de entregables. Así pues, es recomendable el uso de nombres y no de verbos.

• Nivel de paquetes de trabajo: no hay que dejar la descomposición tan arriba que el proyecto se convierta en inmanejable y sea imposible asignarle recursos, costes y responsabilidades; pero tampoco hay que ir tan abajo como para que el control se convierta en insoportable.

• Trazabilidad: vincular tanto como sea posible las EDT a los productos y los hitos. Esto hace más fácil la comprensión y el diálogo con el cliente y con el equipo, así como la orientación de unos y otros al resultado. Muchos productos intermedios o actividades auxiliares de tipo técnico no interesan a nadie al final del día.

• proporciona una identificación de los entregables del proyecto y una descripción elaborada de los componentes de la EDT; y

• describe el trabajo que se requiere en cada componente para producir el entregable. También se pueden incluir estimaciones de costes, recursos, tiempos y dependencias.

Proceso de definición de las actividades según el PMBOK®

• Cada actividad individual no debería implicar una carga muy grande de trabajo.

• Se debería poder observar y evaluar fácilmente si se ha completado o no la actividad.

• Debería ser posible hacer un control de calidad del resultado de la actividad.

• Lista de actividades: lista que normalmente incluye, para cada actividad, su correspondiente identificador, el alcance del trabajo de la actividad en un nivel de detalle suficiente para asegurar que el equipo de proyecto pueda entender el trabajo a realizar.

• Atributos de las actividades: extiende la lista de actividades a partir de un conjunto de atributos. Por ejemplo, las actividades tienen un paquete de trabajo, predecesores, sucesores, responsables, área geográfica, requerimientos, restricciones, suposiciones, duración, recursos asociados, costes, etc. En este punto de la planificación del proyecto, algunos de estos atributos no se conocen y/o se conocerán posteriormente. Aun así, es importante que en este estadio el director de proyecto empiece a crear esta lista de las actividades del proyecto con los atributos necesarios y la información conocida hasta el momento.

• Lista de hitos: un hito es un punto o evento significativo dentro del proyecto. Su tratamiento es similar al de las actividades, tal y como veremos posteriormente, pero a diferencia de estas, los hitos tienen una duración cero en el tiempo. Un conjunto de actividades, o un conjunto de paquetes de trabajo puede dar lugar a un hito dentro del proyecto que el equipo de proyecto puede considerar importante destacar y tener en cuenta.

Proceso de secuenciación de las actividades según el PMBOK®

• FS, finish-to-start, una actividad sucesora no puede empezar hasta que la actividad predecesora haya finalizado.

• FF, finish-to-finish, una actividad sucesora no puede finalizar hasta que la actividad predecesora no haya finalizado.

• SS, start-to-start, una actividad sucesora no puede empezar hasta que la actividad predecesora no haya empezado.

• SF, start-to-finish, una actividad sucesora no puede finalizar hasta que la actividad predecesora haya empezado.

Tipos de precedencias

• Dependencias obligatorias: aquellas dependencias que son inherentes a la naturaleza del trabajo que hay que llevar a cabo.

• Dependencias discrecionales: serán dependencias de lógica preferente y que no resultan imprescindibles. Normalmente limitarán opciones posteriores.

• Dependencias externas: la dependencia es de una organización externa al proyecto, por ejemplo, la Administración pública.

• Dependencias internas: corresponden a dependencias entre actividades del proyecto y, por lo tanto, generalmente están bajo el control del equipo de proyecto.

Adelantos y retrocesos

Estimar la duración de las actividades

• duración de la actividad: $O + 4 M + P 6$;

• desviación estándar: $P − O 6$

• varianza: $( P − O 6 ) 2$

• Se recomienda su uso cuando la incertidumbre de la estimación es alta.

• Permite estimar el riesgo asociado a las estimaciones.

• Permite decidir si hay que dedicar más esfuerzo para obtener unas estimaciones más precisas.

• Permite calcular la probabilidad de que se pueda cumplir con un objetivo de tiempo o coste en un ámbito de todo el proyecto.

Tallas

Puntos

Proceso de desarrollo del cronograma según el PMBOK®

El diagrama de Gantt

El diagrama de Gantt

El diagrama de Gantt

• El conjunto de actividades que determinan la duración del proyecto.

• El camino más largo entre el inicio y el final del proyecto.

• Las actividades dentro del camino crítico son las que deben controlarse con más precisión y el retraso de alguna de ellas supone un retraso de todo el proyecto.

• Calcular la duración del proyecto.

• Ayudar a conocer dónde focalizar sus esfuerzos.

• Identificar dónde actuar para reducir la duración del proyecto en caso de que sea necesario.

• Identificar las tareas que tienen un margen y que, por lo tanto, se pueden retrasar sin que esto afecte a la duración del proyecto.

• ES, early start, lo más pronto que puede empezar.

• LS, late start, lo más tarde que puede empezar.

• EF, early finish, lo más pronto que puede acabar.

• LF, late finish, lo más tarde que puede acabar.

EARLY

LATE

• Sacar los buffers ocultos y acumularlos en un buffer final. De este modo, el buffer es visible para todo el equipo del proyecto y su gestión deja de ser individual para corresponderle al jefe del proyecto.

• Utilizar el LS y no el ES. Empezar todas las tareas que no sean del camino crítico lo más tarde posible, pero añadiendo el buffer necesario al final del proyecto.

• Practicar el monotasking y evitar que se trabaje en paralelo.

Método de la cadena crítica

Compresión del cronograma

Proceso de estimación de costes de acuerdo al PMBOK®

• La estimación de costes del proyecto debería cubrir todos los costes en los que se incurra, así como los costes de calidad, comunicación, formación del equipo, etc.

• La estimación de costes también tendría que considerar los costes en los que incurrirá el cliente debido al proyecto o, al menos, presentarlos en el capítulo de asunciones y limitaciones de la definición de alcance.

• Los costes de un proyecto (en especial si incluye el desarrollo o la instalación de un producto) tendrían que incluir todos los costes presentes y futuros, así como los de mantenimiento, evolución, formación, etc.; en definitiva, lo que se conoce como coste total de la propiedad (total cost of ownership).

Proceso de determinación del presupuesto de acuerdo al PMBOK®

Presupuesto del proyecto con los márgenes de contingencia y de gestión

• Margen de contingencia: se trata de los costes estimados que utilizará el jefe de proyectos para gestionar los acontecimientos previstos, pero no ciertos; es decir, el coste de las acciones correctivas del plan de riesgos.

  • Coste de los known unknowns (riesgos conocidos).

  • Corresponde al coste de las acciones correctivas del plan de respuesta de los riesgos.

  • La gestión es del jefe de proyectos.

  • Está incluido en la línea de base.

• Margen de gestión: es un presupuesto reservado para cambios y riesgos no planificados, pero potencialmente necesarios. Por lo tanto, se trata de incógnitas desconocidas y el jefe de proyectos deberá obtener la aprobación antes de comprometer esta reserva. No forma parte de la línea de base de coste, pero sí del presupuesto del proyecto. No se distribuye como presupuesto ni de los cálculos del valor ganado.

  • Coste de los unknown unknowns, (riesgos no conocidos).

  • La gestión es del patrocinador.

  • No está incluido en la línea base, pero sí en el presupuesto.

• Estimaciones de coste: respecto a las probabilidades de cumplimiento y las limitaciones de presupuesto.

• Estimaciones de tiempo: respecto a las probabilidades de cumplimiento o no de fechas.

• Ámbito: empezando por las hipótesis del proyecto, que son una fuente importante de riesgo. También los entregables y los paquetes de trabajo (EDT) pueden ser una fuente de riesgos en función de su capacidad para definir claramente el trabajo y las probabilidades de que haya cambios en el alcance del proyecto.

• Interesados: especialmente aquellos clave para la definición del alcance.

• Planes de gestión de costes: cronograma y calidad respecto a determinadas exigencias o márgenes que los planes pueden aportar.

• Recursos: cantidad, calidad, disponibilidad, responsabilidad y otros aspectos de los recursos asignados al proyecto.

• Técnicas de recogida de información: técnicas como brainstorming, Delphi, entrevistas o análisis de causas principales son algunas de ellas.

• Diagramas: como por ejemplo, diagramas de causa/efecto (Ishikawa/Fishbone), gráficos de proceso y diagramas de influencia.

• Suposiciones y limitaciones: esta técnica parte de las suposiciones y limitaciones que hayamos descrito en el proyecto para situarlas como posibles riesgos del proyecto.

• Análisis DAFO: o en inglés SWOT (strengths, weaknesses, opportunities and threats), examina el proyecto bajo cada una de estas perspectivas para:

  • identificar oportunidades del proyecto e

  • identificar las amenazas.

• Risk breakdown structure (RBS) : es una técnica que utiliza la misma estructura de la EDT, pero con las posibles causas de riesgos. Normalmente, se parte de una plantilla estándar y se va profundizando en cada una de las ramas para ir identificando riesgos. En la siguiente imagen podemos ver una plantilla estandarizada con una separación inicial en cuatro elementos principales.

Risk breakdown structure (RBS)

Proceso de análisis cualitativo de los riesgos de acuerdo al PMBOK®

Probabilides frente a impacto

• Ignorar. Frente a riesgos con P/I muy baja, hay que ignorar el riesgo, pero sin dejar de hacer un seguimiento del mismo por si hay cambios en la P/I.

• Suposiciones. Ante riesgos con alta probabilidad y bajo riesgo, debemos tratarlos como si fueran suposiciones del proyecto.

• Aceptar o transferir. Ante riesgos de alto impacto y baja probabilidad, se recomienda la estrategia de transferirlos o, simplemente, aceptarlos.

• Evitar. En riesgos con el nivel más elevado de exposición, la estrategia es eliminarlos.

  • Gestión reactiva: actuar de una manera reactiva, solo en el supuesto de que se dé el riesgo. También se recomienda realizar acciones preventivas para mejorar el riesgo, pero no habría que considerar acciones correctivas puesto que el grado de exposición es relativamente bajo.

  • Gestión proactiva: actuar de una manera proactiva y previa a que se dé el riesgo. Por lo tanto, se recomienda tanto tomar acciones preventivas como considerar acciones correctivas.

Planificación de respuestas a los riesgos según el PMBOK®

• Evitar: cambiando el plan del proyecto, de modo que se elimine la amenaza.

• Transferir: en este caso no se elimina el riesgo, sino que se encarga a una tercera persona de la organización que le haga frente.

• Mitigar: tanto si son acciones preventivas para mitigar la probabilidad de que suceda, como de contingencia, para mitigar el impacto.

• Aceptar: cuando no es posible diseñar respuestas efectivas o estas no son rentables.

• Explotar: para asegurarse de que la oportunidad se hará efectiva, modificando el plan del proyecto.

• Compartir: de modo que, a un tercero más preparado para hacerlo se le asigna toda la oportunidad o una parte de la misma.

• Mejorar: de manera que se actúa sobre la probabilidad o el impacto, para incrementar lo que efectivamente suceda o el beneficio cuando se produzca.

• Aceptar: cuando no es posible diseñar respuestas efectivas o estas no son rentables.