Portafolio de cursos de gestión de proyectos

CAMBIOS EN EL EXAMEN PMP® DEL PMI®: Se retrasa la fecha al 1 de julio de 2020.

El PMI® acaba de anunciar que os cambios en el examen no empezarán a aplicarse hasta el 1 de julio de 2010.

Tras la actualización a la 6ª ediicón de la Guía PMBOK®, y la correspondiente actualización en los cambios en el examen, el PMI® había anunciado un nuevo cambio en los contenidos del examen a partir del 15 de diciembre de 2.019.

Sin embargo, tras la abrumadora respuesta de las consultoras de formación, especialmente de los que estamos acreditados como Registered Education Provider (REP), demandando más información respecto a la manera de adaptar nuestros contenidos a los cambios y, sobre todo, más tiempo para poder hacerlo, el PMI® ha decidido posponer el cambio en el examen hasta el 1 de julio de 2020.

Por tanto, tanto las consultoras de formación como nuestros alumnos, sentimos un cierto alivio, y esperamos que este aplazamiento sirva para que el PMI® facilite más información y recursos para que podamos adaptar nuestros materiales a los nuevos contenidos, para tener así la seguridad de que serán los contenidos adecuados para la preparación del nuevo examen. Queremos, como hasta ahora, ofrecer a nuestros alumnos un material de la máxima calidad.

En todo caso, a falta de más información, sí conocemos ya por dónde van a ir los cambios, según el nuevo Exam Content Outline 2020 que ha publicado el PMI®:

  • Si el anterior Exam Content Outline, de 2015 se organizaba en base a los 5 grupos de procesos (inicio, planificación, ejecución, monitoreo-control y cierre), el nuevo se organiza en base a tres dominios:
    • Personas: 42% de peso en el examen
    • Procesos: 50% de peso en el examen
    • Estrategia/entorno de negocio: 8% peso en el examen
  • Sin embargo, lo que supone un mayor cambio es que, en el nuevo examen, los modelos ágiles e híbridos tendrán un peso de aproximadamente el 50%. La última versión de la Guía PMBOK®, apenas introduce algunas ideas sobre estos modelos, por lo que parece que, como mínimo, habrá que incluir también en el estudio la «Guía práctica de ágil» que ha publicado el PMI®, junto con la «Agile Alliance».  

Esperamos, por tanto, tener más información detallada en los próximos meses, para actualizar los contenidos. Mientras tanto, respiramos aliviados con la prórroga hasta julio de 2020 y seguimos recomendando a nuestros alumnos que, siempre que les sea posible, se examinen con la versión actual del examen, ya que todo indica que la nueva versión va a suponer una mayor carga de contenidos y, por tanto, una mayor esfuerzo y tiempo de dedicación.

¡Afortunadamente, contamos con 10 meses más para poder hacerlo!. 

evm1

Aplicación Gestión del Valor Ganado

La Gestión del Valor Ganado (EVM ®) es una de las técnicas más difundidas para el seguimiento y control de proyectos que debemos conocer y tener la posibilidad de aplicar. También es una de las áreas temáticas más importantes del examen de certificación PMP®.

En cualquier proyecto de la clase que sea, las tres variables de alcance, tiempo y costo están siendo constantemente cuestionadas e influenciadas por factores tanto internos como externos al proyecto. Surgen frecuentes cambios en los requisitos y por lo tanto en el alcance, en la calidad, en el plan de ejecución y en los costos que integran el presupuesto.

Con EVM ®, a fecha de estado durante el seguimiento de un proyecto podremos responder a tres preguntas clave:

gestión del valor ganado

El objetivo con la Gestión del Valor Ganado, es evaluar y cuantificar en el nivel de gestión deseable (cuenta de control) los siguientes valores e indicadores clave de desempeño que permiten conocer tanto el estado actual del proyecto, como también pronosticar el posible estado final de nuestro proyecto:

tablaEVM4

Tabla1EVM

Vamos a describir un ejemplo sencillo:

Nos encargan el siguiente proyecto: vallar una finca de forma cuadrada, con 4.000m de perímetro, es decir, 1.000m cada lado:

valla

La planificación que realizamos como directores de este proyecto es la siguiente: completaremos el vallado en 4 días con un presupuesto de 4.000€, según lo siguiente:

Día 1                                   Día 2                                  Día 3                                   Día 4

1.000m/1.000€                 1.000m/1.000€            1.000m/1.000€                  1.000m/1.000€

1.000m/1.000€                 750m/1.200€                    750m/1.000€

100%                                    75%                                         75%

El día 1 marcha según lo planificado, es decir, vallamos 1.000m y nos hemos gastado 1.000€; el día 2 marcha encontramos unas piedras que no habíamos previsto y solo avanzamos el 75% de lo planeado y, además, a un coste de 1.200€, ya que hemos tenido que traer maquinaria para quitar las piedras, y el día 3 volvemos a encontrar piedras, por lo que de nuevo sólo avanzamos el 75% según lo planeado a un coste de 1.000€, ya que la maquinaria ya estaba allí del día anterior. Por lo tanto, al final del tercer día, el avance es el marcado en rojo en la tabla de arriba.

El cliente nos pregunta que, ante estos sucesos imprevistos, ¿cuánto será la estimación del presupuesto a la finalización de las obras el 4º día?

Tenemos los siguientes datos al final del día 3:

  • Valor Planificado/Planned Value = 3.000€ (1000+1000+1000)
  • Coste Real/Actual Cost = 3.200€ (1.000+1.200+1.000)
  • Valor Ganado/Earned Value = 2.500€ (1.000+750+750)

Y según esos datos, las variaciones son las siguientes:

  • SV (Variación del cronograma/Schedule Variance) = EV-PV = 2.500-3.000 = -500€
  • CV (Variación del coste/Cost Variance) = EV-AC = 2.500-3.200 = -700€

Además, podemos conocer los índices del rendimiento tanto del cronograma como del coste:

  • SPI (Índice del Rendimiento del Cronograma/Schedule Performance Index)
    • SPI = EV/PV = 2.500/3.000 = 0,83. Estamos progresando al 83% del ritmo originalmente planificado.
  • CPI (Índice del Rendimiento del Coste/Cost Performance Index)
    • CPI = EV/AC = 2.500/3.200 = 0,78. Estamos obteniendo un valor de 0,78€ por cada 1€ que estamos gastando en el proyecto.

Con los datos anteriores, el cliente nos pregunta cuánto será el presupuesto final, para lo cual calculamos varios EAC basado en las hipótesis sobre el desempeño hasta la fecha (Estimación a la conclusión/Estimation at completion):

Que el 4º día no encontremos más piedras, es decir, que no existirá variabilidad ni del coste ni del plazo y volvamos al ritmo originalmente planificado:

EAC = AC+(BAC-EV) ; EAC = 3.200+(4.000-2.500); EAC = 4.700€

BAC = presupuesto a la finalización/budget at completion

Que el 4º día nos vamos a encontrar con los mismos problemas, es decir, que la variabilidad del coste y del plazo será la misma que hasta la fecha actual:

EAC = AC+[(BAC-EV)/(CPI*SPI)] ; EAC = 3.200+[(4.000-2.500)/(0,83*0,78)] = 4.738,46€

 

Control de Alcance

Corrupción del Alcance («Scope Creep») y Control del Alcance

El estudio del 2105 del PMI® sobre el «pulso» de la profesión muestra los siguientes datos a la pregunta para las organizaciones de las causas principales del fracaso en proyectos que se emprenden:

pmipulse

Evidentemente el primer motivo sobre los cambios en prioridades de las organizaciones debido a los entornos de negocio tan exigentes, dinámicos y cambiantes, esta justificando la necesidad para el Project Manager de tener esa visión del conocimiento de estrategia de la organización y alineación continua de los proyectos que gestiona con dicha estrategia a lo largo de todo el ciclo de vida.

En segundo lugar, como causa muy correlacionada con la primera, aparece la baja capacidad de análisis de negocio asociada a las deficientes recopilaciones de requisitos en los proyectos. El análisis de requisitos plasmado de la forma que necesitemos, en un documento o en una pila de producto, es la base para realizar a su vez una buena definición del Alcance en los proyectos, tanto para dar la visión del entregable a nuestro cliente como para permitir a nuestros equipos de trabajo seguir profundizando en la definición del alcance final a entregar.

En las fases de ejecución de los proyectos, nos encontramos muchas veces con la conocida corrupción de alcance que esta potenciada por causas como la descrita más arriba, ya que conlleva un mayor volumen de peticiones de cambio de alcance para nuestro proyecto; pero realmente el «scope creep» esta relacionado con la falta de control: expansión incontrolada del alcance del producto o del proyecto sin ajustes de tiempo, costo y recursos. Lógicamente a mayor número de cambios seguramente mayor probabilidad de perder el control tengamos sin un buen proceso de control de cambios establecido.

En saber implementar el proceso de control de alcance esta el reto para un Project Manager, la Organizaciones y la metodologías de gestión de proyectos que tratemos de implantar.

La guía de PMBOK® por ser una guía y no una metodología, nos dice el qué pero no el cómo definido. En este caso, las buenas prácticas para materializar el control de alcance en la gestión de los proyectos, nos proponen:

Control de Alcance

Si llega una solicitud de cambio de alcance a nuestro proyecto, en primer lugar asegurar que se cumple con el alcance establecido, para lo cual necesitamos tener definida una línea base de alcance- LBA-, que estaría formada por un enunciado de alcance del proyecto, una EDT y su diccionario. De esta forma, y comparando con la LBA, seremos capaces de responder: «¿la solicitud de cambio, es un cambio de alcance?».

En segundo lugar, el proceso ayuda a gestionar de forma controlada el cambio de alcance haciendo que se formalice la petición a través del proceso de control integrado de cambios que tengamos implementado para el proyecto. Si el cambio es aprobado, control de alcance también debe preocuparse de la integridad de la LBA, de forma que siempre este actualizada.

Por último, cuando el cambio aprobado se implemente según el plan establecido, el control de alcance debe asegurar que se implemente de forma correcta, es decir, según la nueva LBA establecida- última versión.-

Vamos a utilizar una simulación sencilla para ilustrar todo esto, haciendo participar a otros diferentes procesos de gestión que aparecen:

Proyecto Construcción Tractor de Lego:

prtractor1

El proyecto se pone en marcha, y aparece una solicitud de cambio de alcance:

ProyectoTractor2

Control de alcance interviene para verificar comparando con la LBA establecida que tenemos un cambio de alcance y para hacer que se gestione a través del proceso de control de cambios establecido. En la realidad de los proyectos, un cambio de alcance tiene impacto como mínimo en los costes y el plazo:

ProyectoTractor4

La solicitud de cambio aprobada, que incluye cambio de alcance, deberá ser implementado de forma correcta según nueva LBA, y también de forma correcta según los criterios de calidad establecidos-sello de control de calidad-:

prtractor5

Que este «modelo» de puesta en acción del proceso de control de alcance sea más o menos formal y estricto dependerá de diferentes criterios: tipo, importancia y envergadura del proyecto, cliente, área de aplicación, cultura de gestión de proyectos en la Organización,…

 

 

Lego4Scrum

Scrum en acción: Dinámica con LEGO

Con la manos en la masa: Dinámica de puesta en escena de SCRUM basada en LEGO.
Objetivo del proyecto: construyamos nuestra Ciudad.

Scrum es ágil, y ágil es flexibilidad para adaptar el marco de trabajo a las necesidades de tu organización como un todo y probar y probar para ver qué nos funciona mejor y qué opciones debemos modificar.

Os presentamos algunas fotos de nuestro último curso práctico de SCRUM, dónde dentro de las diferentes dinámicas que llevamos a cabo para mostrar qué podemos llegar a hacer con una gestión ágil basada en esta meta-metodología de gestión de proyectos, se realizó un taller usando el juego con LEGO (Lego Serious Play).

SCRUMLEGO2 SCRUMLEGO1

 

Beneficios de la dinámica con LEGO:

  1. El aprendizaje PRÁCTICO enseña más que cualquier TEORÍA.
  2. PILAS DE PRODUCTO QUE GENERAN IDEAS sobre SEGUIMIENTO DE INSTRUCCIONES MUY DETALLADAS: pila de producto abierta para una invitación a la colaboración entre el cliente y los equipos.
  3. DESARROLLO CONSCIENTE DE PRODUCTOS sobre UNA SERIE DE TAREAS A REALIZAR: desarrollar productos y no micro-gestión a nivel de tarea. La pila de producto no debe estar compuestas por una serie de tareas sino que debe ser la visión de un producto – algo grande que los equipos van a construir.-
  4. EQUIPOS COLABORANDO HACÍA UN ÉXITO COMÚN sobre COMPETIR POR LA PUNTUACIÓN: practicar las habilidades de colaboración entre los equipos.
  5. MÉTRICAS ÚTILES PARA EVALUAR LOS BENEFICIOS DE ÁGIL: Poder aprender el equipo de sus propios procesos.
  6. MEJORA CONTINUA sobre GANAR O PERDER EL JUEGO EN UN ÚNICO INTENTO: El juego diseñado de manera que los equipos dispongan de varios intentos. Cada sesión genera lecciones aprendidas y ayuda a entender mejor los procesos.

 

Derechos de autor (juego LEGO):

Licencia Creative Commons Attribution 3.0 Unported

WEB DE LA COMUNIDAD Y DEL PROYECTO DE TRADUCCIÓN

Hemos decidido crear un lugar donde las personas interesadas en la enseñanza de Scrum con LEGO puedan venir y colaborar. www.lego4scrum.com – Únete a la comunidad y ayúdanos a difundirla.

 

 

Curso Scrum Agile

Gestionproyectos.es   ya es Centro Asociado de Scrum Manager.

¿Has oido hablar de la «gestión ágil» de proyectos? ¿Sabes qué es Scrum? ¿Conoces términos «pila de producto», «sprint» o «kanban»?

La Gestión ágil de proyectos  está adquiriendo cada día mayor relevancia, a veces como sustituta de la tradicional gestión «predictiva» y, otras muchas, como complemento de ésta, de manera que, en un mismo proyecto, pueden convivir y complementarse ambos marcos de trabajo.

En sus orígenes, Scrum empezó a implementarse  en el sector de desarrollo de software y TIC. Sin embargo, en la actualidad, se está comprobando su utilidad en muchos otros sectores, en los que se pone de manifiesto la necesidad de introducir cambios y modificaciones en los requisitos del cliente durante el proyecto. El marco de trabajo de Scrum propone un desarrollo incremental del proyecto, con un enfoque iterativo, en el que se hacen al cliente entregas frecuentes, que éste puede valorar y aprobar, antes de llegar a la fase final y entrega del mismo.

Este marco de trabajo tiene su razón de ser en aquellos proyectos en los que se hace muy difícil conocer a priori los requerimientos del cliente (dueño del producto), de manera que el proyecto debe ir adaptándose a las sucesivas aportaciones que el cliente y los usuarios del producto van haciendo, después de cada entrega parcial.

En este ámbito, adquiere gran importancia la experiencia y capacitación de los equipos de trabajo. Habitualmente, esta forma de trabajo genera una mayor implicación  de los miembros del equipo en el proyecto. Por una parte, se obtienen como beneficio mayores índices de satisfacción laboral, a la vez que aumenta el grado de satisfacción el cliente.

Los principios de las metodologías ágiles y el marco de referencia de trabajo de Scrum son fáciles de estudiar y entender. Sin embargo, normalmente, la mayor dificultad radica a la hora de llevarlos a la práctica. Por una parte, debido a la ya comentada necesidad de contar con equipos de trabajo muy cualificados y, por otra, por la necesaria implicación del cliente, que no siempre es fácil de conseguir.

Respecto a la adquisición de conocimientos en este campo, existen en la actualidad diferentes Certificaciones en Scrum, que acreditan  que su poseedor ha adquirido estos conocimientos, y está preparado para implementarlos en su organización.

Existen diferentes asociaciones, todas ellas privadas y con sus propios criterios de evaluación, que certifican el conocimiento de la gestión ágil y Scrum, tales como El Project Management Institute, Scrum Alliance, Scrum.org o Scrum Manager, la más difundida en la comunidad profesional hispanoamericana.

Scrm Manager aporta, como valor diferenciador respecto a otras entidades certificadoras, la aplicación de Scrum de forma flexible y global: flexible al conceder la máxima importancia  a la capacitación de los equipos de trabajo, más allá de las metodologías o reglas establecidas, para adaptarse a las características de cada proyecto y de cada organización, y global al ir más allá de los departamentos de gestión de proyectos, para abarcar a toda la Organización de la empresa en su conjunto.

Gestionproyectos.es es centro Asociado de Scrum Manager, lo que significa que estamos acreditados para  ofrecer los servicios y formación y examen de Certificación presencial de Scrum Manager. En nuestros cursos damos a conocer el origen del modelo y las prácticas que emplea para gestionar proyectos de forma ágil y evolutiva. Además, mediante juegos, dinámicas y prácticas de coaching, el objetivo es que tanto la dirección como los equipos de trabajo, puedan llegar a adaptar lo aprendido a las características  de sus propios proyectos.

Tras el curso, los alumnos que lo deseen pueden realizar con nosotros el examen de Certificación Profesional Oficial de Scrum Manager.

Más información sobre el curso: http://www.gestionproyectos.es/curso-scrum/

 

 

MSProject2013GP

Sobre Valor Ganado y MS Project 2013

¿Sabías que…?

Microsoft Project 2013 permite utilizar la técnica del Análisis del Valor Ganado obteniendo de forma automática para nosotros los parámetros de Valor Ganado o Valor Acumulado, Valor Planeado y Costos Actuales en función de una fecha de estado dada del proyecto y para los costos acumulados y por defecto prorrateados.
De esta forma podemos también obtener y presentar en informes visuales ilustrativos, indicadores clave del desempeño de nuestro proyecto como son el CPI (desempeño de los costes)  o el SPI (desempeño del cronograma).

Para hacer esto con MS Project tenemos que decidir si queremos que se calcule sobre el valor de %completado o sobre el %físico completado. En el primer caso Project hace el cálculo de forma automática si así queremos, mientras que en el segundo caso debemos introducir manualmente el dato para cada tarea.

Si usamos el atributo %completado, MS Project hace los cálculos del valor ganado en función de la duración para tareas y en función del esfuerzo (trabajo real) para los recursos y que seria el campo de Project llamado % Trabajo Completado. Tenemos que visualizar un conjunto vista+tabla en Project de los datos del valor ganado, que nos muestren unos resultados consolidados y alineados con la propia definición del valor ganando:

  • Valor Ganado: trabajo realizado-finalizado- en términos del presupuesto autorizado. ¿Lo que he realizado, cuanto vale según lo presupuestado/planificado?

Y donde debemos tener claras las reglas de imputación de nuestros equipos de trabajo sobre las tareas que realizan. Con esta definición, el dato de MS Project que mejor esta alineado con el concepto de Valor Ganado es el %Trabajo Completado:

EVM_msproject

Como se observa en esta gráfica, Project según consolida datos a nivel de tarea o nivel de recursos asignados a las tareas, obtiene valores del Valor Ganado/Acumulado que difieren, pero las gráficas de los informes visuales que se obtienen con MS Project para representar estos parámetros muestran el %trabajo completado para el valor ganado que es lo más correcto.

¡Próxima Convocatoria del Curso Online-Presencial!:

CURSO PRÁCTICO DE MICROSOFT PROJECT 2013 CON LOS FUNDAMENTOS DE LA GUÍA DEL PMBOK®

Puzzle 1 GP

El puzzle de la Gestión de Proyectos

El puzzle de la gestión de proyectos ¿Qué es la gestión de proyectos?
Una pregunta que puede tener múltiples respuestas y tan sencillas o complejas como queramos que sean.
Estamos muy acostumbrados hoy en día, por ejemplo a través de las numerosas redes sociales, a estos titulares de artículos: «Los 7 errores de…» o «5 claves para …». Evidentemente es un modo de atraer lectores y por consiguiente visitas a un blog o página web, es un buen cebo pero siempre te acabas preguntando: ¿y por qué no 8 claves o 9 errores?.

La gestión de proyectos es un puzzle con un diseño final y un número de piezas que no es fijo y que dependerá de muchos factores que incluso podrán variar a lo largo del tiempo. Tomemos algunos ejemplos de esos factores que podrían formar parte de nuestro puzzle:

  • Organizacióncultura corporativa y estructura– y su sector.
  • Tipología– envergadura, ciclos de vida, clientes internos y externos, …-  de los proyectos que se desarrollan y su alineación con una estrategia establecida.
  • Madurez en gestión de proyectos e implementación de metodologías- procesos, herramientas, áreas de conocimiento- basadas en mejores practicas de la profesión. Reconocimiento del rol de gestor de proyectos y perfil asociadoa este rol.

Todos son factores muy variables e incluso no dependientes: para un mismo sector hay Organizaciones que sí usan metodologías y otras que no las aplican e independientemente de esto, puede ser que el perfil de gestor de proyectos incluya participar en la ejecución para producir entregables de proyectos en curso que lidere, además de las tareas de gestión que comúnmente se atribuyen a un Project Manager y, de la participación en desarrollo de negocio para apalancar clientes existentes y buscar oportunidades en nuevos clientes creando y defiendo propuestas.

Cuando diriges proyectos en tu Organización:

  • ¿Cómo gestionas su incertidumbre?
  • ¿Cómo se definen los objetivos? ¿Eres capaz de saber si se cumplen?
  • ¿Eres capaz de medir el éxito de los proyectos? si el proyecto esta bien gestionado: cumple plazo, costes y alcance con la calidad requerida ¿es exitoso…, o debes ir más allá y ser capaz de medir el éxito de la idea que originó el proyecto?

Estas preguntas u otras, y sus posibles respuestas pueden formar parte de tu puzzle para la gestión de los proyectos y definir una diseño sencillo o complejo.

En uno de nuestros últimos seminarios impartidos el objetivo genérico para uno de los asistentes era saber como encontrar un equilibrio en el tiempo que debía dedicar a gestionar su proyectos respecto al tiempo que debía dedicar para desarrollar los entregables que le correspondían.

Por último, hay una pieza que siempre deberías incluir: las personas o técnicamente los interesados-stakeholders– del proyecto. En una charla informal con un colega me transmitía su frustración: en un escenario de gran presión y con numerosos interesados en varios proyectos, no podía hacer depender exclusivamente de él y su equipo todos lo hitos que se definían. Lógicamente en los proyectos suelen existir tareas e hitos que dependen de otros pero que son necesarios cumplir para avanzar según la planificación realizada y en este caso poco importaba que la gestión directa funcionará sino que también se exigía al project manager control de dicha gestión indirecta.

Habrá metodologías de gestión de proyectos con procesos y herramientas que nos ayuden, pero estas no tratan con las personas ni piensan por nosotros, ni toman decisiones, no son capaces de liderar a equipos, escuchar y comunicar o resolver problemas. Detrás de los proyectos están las personas con sus necesidades, deseos o expectativas, caracteres, ambiciones y miedos, … y están mezcladas con organizaciones y su historia, cultura e intereses.

En tu puzzle de gestión de proyectos tendrás 5, 8 o 12 piezas que deberás conocer para ensamblar y obtener el mejor diseño que te valga en este momento.  En el futuro esas piezas y el dibujo final podrán cambiar.

¿Cómo es ahora tu puzzle?

Fundamentos Gestión de Proyectos

Pregunta examen PMP®: Diagramas de red y dependencias entre actividades

En la siguiente pregunta ejemplo de examen test de la certificación PMP® , se plantea un diagrama de red, las secuencia de relaciones lógicas entre las actividades y la cuestión sobre el inicio temprano (lo antes que puede comenzar una actividad) de la actividad J, y un relación de dependencia con predecesora (SS: Inicio-Inicio) diferente a la más común (FS: Final-Inicio):

EjercicioExamenPMP

En rojo describimos el recorrido por el diagrama de red de izquierda a derecha de los diferentes camino lógicos de la red que permite calcular el Inicio temprano (ES) y el Fin temprano (EF) de cada actividad.
Comentamos únicamente las que tienen relaciones con adelantos/retrasos diferentes a la estándar FS: Final-Inicio =>una actividad sucesora no puede iniciarse hasta que la predecesora haya finalizado:

  • B–> H (FS-2): Sin el adelanto de dos días, H tendría ES(H)=7 y EF(H)= 15. Como se aplica ese adelanto ES(H)= 5 y EF (H)=13
  • G–> K (FS 4): Sin el retraso de 4 días, K tendría ES(K) = 14 y EF(K)= 15. Cuidado aquí porque como hay 3 predecesoras (H,J y G) aplicamos la regla de que el ES de la sucesora es el EF (fin temprano) más tardío de las predecesoras (+1 día por estar incluyendo en las «cuentas» el ultimo día en los EFs), de esta forma mantenemos la coherencia de la relación lógica entre actividades (predecesora-sucesora). Con el retraso de los 4 días en G, el EF más tardío pasa a ser justamente el de esta actividad (14)=> ES(K)=15 y EF (K) =16
  • Para J, tenemos dos predecesoras y aunque hay una relación SS (inicio-inicio: una actividad sucesora no puede iniciar hasta que la predecesora haya iniciado) con F, para seguir manteniendo la coherencia de las relaciones lógicas entre las actividades, el ES de J seria el EF más tardío de las predecesoras => ES(J)= 8 y EF(J) =13

NOTA: Si J solo tuviera como predecesora a F, SÍ que deberíamos haber forzado a que su ES(J)=5 y por lo tanto su EF(J) =10 para mantener la relación SS.

Para el camino de vuelta  través del diagrama de red, en verde, calculamos el Inicio tardío (LS) y el Fin tardío (LF) de cada actividad:

  • EjercicioExamenPMPRESPUESTA2Para G, volvemos a aplicar el retraso de 4 días (con cuidado porque estamos recorriendo el camino a la inversa), esto es, sin el retraso para G LF(G)=14, con la retraso de 4 días y teniendo en cuenta que la relación es FS (Final-Inicio)=> LF(G) =10 y LS(G)=5
  • Para B (es la única predecesora de H), sin el adelanto LF(B)=5, Como B tiene una relación FS con H y un adelanto de 2 días (H debe iniciar cuando B finaliza – 2 días)=> LF(B)=7 y LS(B)=3
  • En el caso de F (solo tiene una sucesora J y una relación SS con ella)=> si fuera una relación estándar FS(Final-Inicio) entonces LF(F)=8 y LS(F)=7 pero como la relación es SS, debemos forzar a que el LS(F) sea el LS(J)=> LS(F)=9 y por lo tanto LF(F) =10.
caminocritico2

Ejercicio práctico del método del camino crítico o ruta crítica

Os mostramos en este vídeo un ejemplo práctico de aplicación del método de la ruta crítica de un proyecto en un ejercicio para un diagrama de red del cronograma:

logo_gestionproyectos

Nueva Convocatoria Curso Certificación PMP

¡INSCRÍBITE YA!