Formación específica para la preparación de la certificación de PMP

catalogo servicios

COACHING PARA CONSEGUIR TUS PROPÓSITOS

¿Te cuesta concretar tus objetivos? ¿Tienes claro lo que te gustaría, pero no sabes cómo llevarlo a la práctica? 

Ahora que el verano termina, nos acercamos a ese momento de los «buenos propósitos» en el que, nuevamente, retomamos esos planes que llevamos tiempo posponiendo. Pensamos que esta vez será la definitiva, y nos hacemos una lista de esas tareas que siempre tenemos «por hacer», con el convencimiento de que, esta vez sí, las pondremos en marcha. Sin embargo, como dijo Einstein «locura es hacer la misma cosa una y otra vez, esperando obtener resultados diferentes».

«De acuerdo»- pensarás – «Se dice muy fácil». «Debo hacer algo distinto… pero ¿qué? Si lo supiera, ya lo habría hecho….»

Si tengo claro que quiero hacer algo, ¿por qué no lo consigo? ¿por qué, año tras año, llega diciembre y me doy cuenta de que sigo donde estaba y de que el trabajo y los demás deberes cotidianos han consumido todo mi tiempo y no he hecho lo que QUERÍA  hacer?

En primer lugar,  te diré que proponerse una tarea ya es un primer paso y, además, muy importante. Si no estás dispuesto a dejarte llevar, si tienes una ilusión, si quieres algo más, pero no sabes cómo darle forma, participar en un proceso de coaching puede servirte de ayuda para salir de donde estás.

Estas son algunas de las «causas» que, a menudo,  nos impiden avanzar en nuestros propósitos. ¿Te sientes identificado con alguna?:

No tener claramente definido un objetivo: A veces tenemos claro «lo que no queremos», lo que no nos gusta, pero no sabemos definir dónde queremos llegar. Tenemos un sueño difuso, una idea abstracta, o simplemente tenemos un malestar, no nos sentimos a gusto, pero no sabemos por qué.
No ser consciente de la realidad: Normalmente, creemos tener clarísimo lo que hacemos e, incluso, el por qué. Sin embargo, es sorprendente la cantidad de cosas que hacemos sin darnos cuenta, las conductas repetitivas y los pensamientos inconscientes que están boicoteando nuestro objetivo. Es necesario sacarlos a la superficie, porque sólo desde la consciencia se podrán cambiar.
Adoptar los objetivos de otros: A veces «nos imponemos» objetivos a nosotros mismos . Pero, ¿de verdad queremos cumplir lo que nos hemos propuesto? Te invito a que te preguntes si TIENES QUE hacerlo o si QUIERES hacerlo. Si tu objetivo no es suficientemente motivador para tí, si no te seduce lo suficiente como para vencer las resistencias e, incluso, los temores, seguirás anteponiendo cualquier otra tarea.
Falta de confianza: si no sientes que puedes cumplirlo, dificilmente lo harás. Según las palabras atribuidas a Henry Ford, «si crees que puedes, tienes razón. Si crees que no puedes, también tienes razón».
No quieres asumir la responsabilidad: Es cierto, a veces conseguir lo que uno se propone, cuesta, hay que hacer un esfuerzo. ¿Hasta dónde estás dispuesto a poner de tu parte? ¿Qué precio estás dispuesto a pagar? ¿Qué pasará si no lo consigues? (Recuerda: ¡no hay fracasos, sólo aprendizajes!).
No sabes como hacerlo: a veces no nos permitimos ponernos objetivos porque no sabemos cómo cumplirlos. «Como no se cómo hacerlo, lo ignoro y hago como si no lo quisiera». Sin embargo, ésto, raramente se consigue y, normalmente, eso que no hemos cumplido nos persigue en forma de «tarea pendiente»…

La lista podría ser interminable… ¿Te sientes identificado con alguna ellas? Si es así, te invito a que valores realizar un proceso de coaching. Podemos cerrar una primera sesión exploratoria gratuita, en la que explicarte, con todo detalle, como funciona el proceso, y resolver todas tus dudas.

¡Ponte en marcha y el destino actuará en tu favor! ¿Te atreves?

 

Fechas de publicación PMBOK® 6ª edición y actualización Examen PMP®

Nuevo Examen PMP® con PMBOK® 6ª edición: desde el 26 marzo 2018

Ya se ha anunciado por parte del PMI® (Project Management Institue) las fechas oficiales de la renovación de tres de sus estándares (Gestión de Programas, Gestión de Portafolio y Análisis de Negocio), además de las fechas de actualización de la Guía PMBOK ® (6ª Edición) y la publicación de la Guía Práctica Ágil.

Publicación Liberación versión PDF Liberación Versión Impresa Actualización Examen
Guía PMBOK® 6ª Edición Septiembre 2017 Septiembre 2017 26/marzo/2018(PMP®)

21/mayo/2018 (CAPM®)

Guía Práctica Ágil Septiembre 2017 Septiembre 2017  26/marzo/2018(PMI-ACP)®
Estándar para la Gestión de Programas –4ª Edición Q3 2017 Q4 2017 Q1 2018 (PgMP)®
Estándar para la Gestión de Portafolios – 4ª Edición Q4 2017 Q4 2017 Q2 2018 (PfMP)®
Guía PMI para el Análisis de Negocio Q4 2017 Q4 2017 Pendiente (PMI-PBA)®

Podemos ver los cambios propuestos a nivel de áreas de conocimiento y procesos de gestión en esta tabla:

ÁREAS DE CONOCIMIENTO GRUPOS DE PROCESOS de Gestión de Proyectos
INICIACIÓN (2) PLANIFICACIÓN (24) EJECUCIÓN (10) MONITORIZACIÓN Y CONTROL (12) CIERRE (1)
4. Gestión de Integración del proyecto 4.1 Desarrollar Acta Constitución del Proyecto 4.2 Desarrollar Plan de Dirección del Proyecto 4.3 Dirigir y Gestionar el Trabajo del Proyecto

4.4 Gestionar el conocimiento del Proyecto (Manage Project Knowledge)

4.5 Monitorear y Controlar el Trabajo del Proyecto

4.6 Realizar Control Integrado de Cambios

4.7 Cerrar Fase o Proyecto
5. Gestión de Alcance del proyecto   5.1 Planificar  Gestión de Alcance

5.2 Recopilar Requisitos

5.3 Definir Alcance

5.4 Crear la EDT

  5.5 Validar Alcance

5.6 Controlar Alcance

 
6. Gestión de la programación/cronograma del proyecto   6.1 Planificar  Gestión del Cronograma

6.2 Definir Actividades

6.3 Secuenciar Actividades

6.4 Estimar Duración Actividades

6.5 Desarrollar Cronograma

  6.6 Controlar el Cronograma  
7. Gestión de Costes del proyecto   7.1 Planificar gestión de Costos

7.2 Estimar Costos

7.3 Determinar Presupuesto

  7.4 Control de Costos  
8. Gestión de Calidad del Proyecto   8.1 Planificar Gestión de Calidad 8.2 Gestionar la calidad (manage quality) 8.3 Control de Calidad  
9. Gestión de Recursos del Proyecto   9.1 Planificar  Gestión de Recursos

9.2 Estimar Recursos de actividades

 

9.3 Adquirir recursos

9.4 Desarrollar el Equipo de Proyecto

9.5 Dirigir el Equipo de Proyecto

 9.6 Controlar Recursos  
10.Gestión de Comunicaciones   10.1 Planificar Gestión de Comunicaciones 10.2 Gestionar Comunicaciones 10.3 Controlar Comunicaciones  
11.Gestión de Riesgos   11.1 Planificar gestión de Riesgos

11.2 Identificar Riesgos

11.3 Análisis Cualitativo de Riesgos

11.4 Análisis Cuantitativo de Riesgos

11.5 Planificación de Respuesta Riesgos

 11.6 Implementar respuestas de riesgos 11.7 Monitorizar Riesgos  
12.Gestión de Adquisiciones   12.1 Planificar Gestión de Adquisiciones 12.2 Realizar Adquisiciones  12.3 Controlar Adquisiciones  
13.Gestión de los Interesados 13.1 Identificar Interesados 13.2 Planificar Gestión de Interesados 13.3 Gestión Compromiso(engagement)  de los Interesados 13.4 Monitorizar el compromiso de los Interesados  
user story mapping 2

Mapa de historias de la gestión de proyectos: aplicación de una técnica ágil en un escenario tradicional

El mapa de historias de usuario- Jeff Patton (http://jpattonassociates.com/user-story-mapping/)  es una técnica ágil que permite trabajar con una de las mayores problemáticas que aparece en la construcción de aplicaciones y productos tecnológicos software : la elaboración de documentación compartida no genera entendimiento compartido. Un ejemplo tradicional y común: definir y analizar los requisitos de cómo queremos que funcione una determinada aplicación y plasmar los resultados de reuniones, entrevistas, encuestas,… que podamos realizar con todos los interesados clave, en diferentes tipos de documentación como documento de requisitos alto y bajo nivel, casos de uso, diseño de arquitectura, patrones,….

Todo parece ir bien al inicio del proyecto, dónde existe un alineamiento entre todos los participantes o al menos esa es la impresión. Pero una vez que ya estamos obteniendo resultados de los requisitos definidos nos damos cuenta que esa sinergia inicialmente consensuada no lo es tanto en absoluto, y empezamos a ser conscientes que tenemos un entendimiento diferente en nuestras cabezas.

Este es un ejemplo de cuantas veces ocurre que lo que inicialmente interpretamos como una meta conjunta y consensuada, cuando empezamos a trabajar, nos damos cuenta que estábamos pensando cosas completamente diferentes.

user story mapping 2

 

 

 

 

Fuente: www.comakewith.us, Jeff Patton

El mapa de historias de usuario trata de mitigar el riesgo de este escenario a través de la gestión visual y la conversación. Por un lado, usa herramientas visuales como tableros físicos- posteriormente se puede llevar a un soporte digital si es necesario- y postits para trasladar el entendimiento que se va generando de lo que se quiere construir con la participación de todos los interesados clave, y además utiliza el modo de comunicación que tiene mayor probabilidad de éxito, la comunicación cara a cara con retroalimentación a través de la conversación continua entre todos los participantes, como base para la generación del entendimiento compartido.

Fuente: www.comakewith.us, Jeff Patton

Se trata pues de una técnica  ágil perfectamente utilizable no sólo por el motivo para el que se ideó, construir aplicaciones de software, sino en cualquier contexto que demande conseguir el entendimiento compartido más allá de los resultados que se muestran en la documentación a desarrollar.

En particular utilizamos la técnica para trabajar el mapa de historias de usuario de la gestión de proyectos de una organización. El mapa resultado dinámico y evolucionable, es el fundamento junto con el apoyo de otras técnicas para construir una nueva metodología para la gestión de los proyectos de dicha organización, que no parece por concepto algo «ágil».

Lo más importante no es el documento o documentos entregables como resultado del proceso de definición de la metodología de gestión de los proyectos, sino este propio proceso o camino en la búsqueda del entendimiento compartido, el empoderamiento en los propios involucrados para participar  en la construcción del cambio en la forma de trabajar de la organización, y establecer la base de un proceso de mejora continua mediante la inspección y adaptación conforme se vaya implementando la metodología inicialmente establecida para aprender  tanto de lo que funciona como de aquello que no genera los resultados esperados.

La técnica del mapa de historias de usuario en este contexto abarca el ciclo de vida global end-to-end de la gestión de proyectos para la metodología, que sería el “producto” a definir,  incluyendo la etapa de viabilidad pre-proyecto e incluso parte de la etapa del posible  traspaso al área de operaciones.

La técnica del mapa de historias de usuario comprende una serie de pasos a realizar, que de forma resumida serian:

1. Enmarcar: Qué se quiere hacer, Quienes participan y Por qué se quiere hacer. Antes de mapear, creamos una breve descripción del producto para enmarcarlo y contextualizar el mapa. Este paso inicial fundamental lo trabajamos con una técnica ideada por nuestro compañero Raúl Herranz: el diagrama WAGI (http://blog.utopicainformatica.com/2014/03/el-diagrama-wagi-o-diagrama-de-mangle.html ) que recopila a su vez de forma ingeniosa una serie de técnicas ya reconocidas en su utilidad como los 5whys y el GQM (Goal, Question, Metric), para ayudar a enmarcar un proyecto de coaching/asesoría de implementación de agile en una organización. Vuelve a ser un objetivo trabajar con gestión visual el entendimiento compartido, en nuestro caso para la pregunta ¿Por qué queremos una metodología de gestión de proyectos en la organización?.

Se trabaja en identificar los beneficios/objetivos que la organización pretende obtener, o problemática que se quiere resolver  con el producto “metodología de gestión de proyectos”, como seremos capaces de medir los logros pretendidos y quienes deben participar en el proceso y como deben hacerlo.

Es importante identificar cuáles son los diferentes usuarios que usaran el producto, y lo «electores» o clientes que “compraran” el producto, y para cada usuario y elector establecer el beneficio que pretende obtener de utilizar el producto.

A modo de ejemplo,  diferentes actores que participan en la gestión de proyectos y productos de una organización (con una nomenclatura estándar) podrían ser:

  • CEO/Presidencia (“comprador”)
  • Director/Gestor de proyecto
  • Dueño de producto(agile)
  • Miembro del equipo
  • Manager funcional
  • Cliente
  • Usuario
  • ….

Esto nos permitirá personalizar el “producto” metodología a las necesidades de cada rol y empatizar con todos los participantes. Se trata de crear el escenario de cada rol.

2. Mapear el Big Picture: Focalizarse en obtener la historia completa –think «mile-wide, inch deep»-: lo importante es cubrir todo el ciclo de vida de experiencia del usuario a través de las actividades y tareas de alto nivel que realiza y que cuentan la historia completa, formando el llamado backbone de nuestro mapa de historias.

user story mapping 3 

 

 

 

 

 

 

Fuente: www.comakewith.us, Jeff Patton

Un mapa de historias de usuario contiene dos importantes características “anatómicas”

  • El backbone de la aplicación/producto es la lista de actividades-grandes historias o metas- esenciales que la aplicación/producto soporta.
  • El walking skeleton es el producto que construimos que soporta el mínimo número de tareas necesarias a través del ciclo completo de la experiencia del usuario.

De forma generalista y resumida, para el desarrollo del backbone comenzamos con el usuario más crítico para el éxito del proyecto  e imaginamos un típico día en la vida del usuario con el nuevo producto. Mapeamos las acciones como tareas del usuario de izquierda a derecha.

A continuación identificamos las actividades del usuario, que son los grupos de tareas que trabajan juntas para soportar una meta común. Las actividades típicamente emergen después cierto tiempo transcurrido tras haber empezado a trabajar el mapa.

Después, se añaden los usuarios adicionales. Una vez hayamos pensado en el típico usuario del producto, podríamos trabajar con los otros tipos de usuario en nuestra historia. Continuamos modelando su historia de izquierda a derecha.

Para nuestro particular “producto” de la metodología de gestión de proyectos, como elemento de ayuda para plantear este nivel más alto del mapa de historias –backbone– podemos partir del marco propuesto por la guía de buenas prácticas en gestión de proyecto del PMBOK, que no es una metodología y que, en contra de creencias extendidas, no promulga un estricto apego a normas o documentación que no sean valiosas. A partir de PMBOK podemos construir tanto una metodología más predictiva aplicable a proyectos simples o complicados, como una metodología más ágil en escenarios de proyectos complejos (https://en.wikipedia.org/wiki/Cynefin_framework).

Tenemos pues el backbone identificado y establecido a través de las etapas de gestión propuestas en PMBOK: Estudiar la viabilidad del proyecto-esta no es formalmente PMBOK-, Iniciar el proyecto, Planificar el proyecto, Ejecutar el proyecto, Monitorizar y Controlar el proyecto y Cerrar el proyecto. Posteriormente podremos usar las diferentes áreas de conocimiento descritas en PMBOK para trabajar el mapa de historias en los diferentes niveles.

Hacer hincapié en que el mapa de historias de usuario puede reflejar de izquierda a derecha el posible orden cronológico de las acciones a realizar por los diferentes actores de la aplicación, aunque esta característica es posible que no siempre se cumpla o incluso que haya intercambios temporales para ciertas acciones.

Nuevamente para el caso de la gestión de proyectos, el propio planteamiento de la etapas de gestión implica cronología, si bien es cierto que es fundamentalmente en la etapa de planificación dónde se llevan a cabo procesos/ actividades con lógica temporal. Por ejemplo, se define/estima que se quiere construir a alto nivel, para después tratar de detallarlo- al menos el corto-medio plazo- y estimar cuanto tiempo  y dinero implica desarrollarlo.

3. Explorar: Se trata de rellenar el cuerpo del mapa de historias descomponiendo las grandes tareas/actividades del usuario en sub-tareas más pequeñas y detalladas, e idealmente obtener como segundo nivel el llamado walking skeleton, que representa la primera versión/release del producto metodología que pretende entregar el mejor producto posible con las restricciones temporales presentes. Es  la versión de funcionalidades más simple posible del producto que cubre el ciclo de vida completo del usuario a través de las actividades objetivo mostradas en el primer nivel del mapa –backbone-. Debe servir para validar el desempeño cuando se comience a implementar y ser  escalable, por ejemplo por tipo o tamaño de proyecto.

En esta fase podremos añadir tarjetas al tablero físico del mapa de historias, dividir una tarjeta en dos, re-escribir tarjetas y reorganizarlas. Usar esta fase para pensar en el «cielo azul» sin restringir sobre todas las posibilidades que aparezcan y para pensar en todo lo que podría ir mal y qué tendría que hacer el usuario para corregirlo. No preocuparse si las ideas están «fuera de alcance».

Jugar a: «no sería fantástico si…» para grandes ideas del producto. Investigar variaciones: ¿qué más podrían haber hecho los usuarios?

Seguir considerar  los otros usuarios: ¿Que podrían hacer otros tipos de usuario para alcanzar sus objetivos?

Añadir otros detalles del producto como herramientas de ayuda a la gestión del proyecto, reglas de negocio,…

Involucrar a otros: contar la historia de tu producto a otros para explicarles los usuarios y el uso. Encontrar agujeros en tu historia y la ayuda para cubrirlos. Ellos te pueden apuntar a áreas con riesgos o  que resulten caras de implementar.

4. Dividir en Versione/Releases viables: El mapa de historias pretende ser dinámico y poder evolucionar, así como implementar el producto metodología de gestión de proyecto resultante de forma gradual e incremental para ir midiendo los resultados y aprender a través de un proceso de mejora continua. Se trata pues de cortar el mapa en “versiones” de producto viables que dividan los usuarios y el uso del producto. Estas rebanadas forman una hoja de ruta incremental de las versiones-releases- del producto donde cada versión es una liberación de lo que se conoce como producto mínimo viable.

Es recomendable para cada release, describir los resultados que son objetivo e impacto esperado, y como contribuyen a la meta global descrita tras el paso 1 sobre  el por qué. Esto sirve de motivación para la construcción del producto.

Para cada release identificar la métricas clave de identificación de éxito del producto (forma parte también de la técnica wagi).Es la respuesta a la pregunta ¿Que podremos medir para determinar si este producto es exitoso?.

5. Estrategia de desarrollo/implementación: El mapa de historia también trata de reflejar en el eje vertical de arriba a abajo el criterio de importancia/necesidad en orden descendente de las historias conforme se van descomponiendo y detallando hasta un nivel apropiado.

El objetivo es cortar la primera release/versión del mapa, el “walking skeleton”, para permitir a la organización aprender rápidamente y evitar/mitigar riesgos de implementar toda una metodología y procesos asociados que no se vayan probando y midiendo el beneficio que se obtiene  o la problemática que se resuelve.

A partir de esta primera versión, avanzamos completando las principales funcionalidades, haciéndolas más ricas y más detalladas. Seguimos buscado las pruebas con los usuarios y recibiendo retroalimentación para ajustar el producto.

Con el desarrollo de los talleres de trabajo para construir el mapa de historias de la gestión de proyectos, se profundiza y adapta para considerar casuísticas como tipologías- interno, para terceros- y tamaño de los proyectos, orientaciones predictiva y ágil para la gestión,… que pueden conducir incluso a la generación de más de un mapa.

Como ejemplo ilustrativo del trabajo sobre el mapa hasta un segundo nivel (las historias que aparecen son ficticias y parciales pero sirven para mostrar el resultado de la técnica):

EjemploUMGP

apply pmp

Cómo acreditar la experiencia profesional exigida por el PMI

¿Cómo tengo que “demostrar” al PMI® que dispongo de la experiencia profesional que me exigen para poder optar al examen de PMP®? ¿Debo entregar un Certificado emitido por mi empresa? ¿Presento alguna documentación oficial?

Estas son algunas de las preguntas más repetidas por aquellos que se interesan por la certificación PMP®, hasta el punto de que algunos llegan a plantearse si optar o no a ella, temiendo no poder, llegado el momento, demostrar la experiencia que tienen, que muchas veces excede por mucho la exigida.

Por ello, en este post, vamos a explicar cómo es el proceso de “Application”, en el que el candidato debe acreditar que cumple los siguientes requisitos:

  • 35 horas de formación en el ámbito de la gestión de proyectos (normalmente los cursos que preparan para este examen sirven a la vez para cumplir este requisito, emitiendo el correspondiente Certificado de realización)
  • Una determinada experiencia profesional:

a) 3 años de experiencia (4.500 horas), si tienes estudios universitarios.

b) 5 años de experiencia (7.500 horas) si no los tienes.

Bien, en el caso de que cumplas estos requisitos, ¿Cómo debes acreditarlos?

Para ello, debes cumplimentar tu application a través de la página web de PMI®. Para ello, debes crearte  un usuario con tus datos a través de su página www.pmi.org.

Una vez registrado, ya puedes presentar tu candidatura on line para la Certificación PMP®, registrando la información requerida. Primero, te pedirán los datos de tu nivel de estudios (básicos, universitarios, etc). A continuación, deberás acreditar dónde y cuando has realizado la formación en Gestión de Proyectos (recuerda que, si haces la formación con una empresa acreditada cono REP – Registered education Provider- tendrás la garantía de que será aprobada por el PMI®.

Hasta aquí, la parte “sencilla”.

A continuación, pasamos a detallar la experiencia profesional. Y no es que esto sea complicado ni difícil, pero si suele resultar una tarea laboriosa. Tendrás que ir introduciendo proyectos en los que hayas participado (en todo o en parte)- y que el total de estos proyectos sumen los 3 o 5 años requeridos. No es necesario que tu rol en estos proyectos haya sido “oficialmente” el de Project Manager o Jefe de Proyectos, pero si es importante que quede claro que has tenido un cierto grado de responsabilidad en los mismos, ya sea porque has gestionado los costes, has dirigido equipos de trabajo, has tenido que tratar directamente con el cliente, o ejercido alguna otra labor de responsabilidad.

Nunca te van a pedir que envíes ninguna información oficial de la empresa que acredite la veracidad de lo que has contado (contrato laboral, contrato del proyecto con el cliente, partes de trabajo, etc), simplemente tendrás que introducir una persona de contacto (o varias) que, en su caso, pueda acreditar lo que has reportado. Esta persona de contacto puede ser alguien que haya co-liderado contigo el proyecto, algún responsable o superior, alguna persona del departamento de Recursos Humanos de tu empresa, alguien de la empresa cliente, etc. El abanico es bastante amplio, y no importa que, en el momento en que haces tu application, esa persona o personas ya no trabajen en esa empresa o, incluso, se hayan jubilado.

Y ya está: una vez finalizada la cumplimentación de tu solicitud de elegibilidad, le das a “enviar”, y el PMI® te responderá en 5 días laborables.

Como ves, todo el proceso se hace a través de internet, sin aportar ninguna documentación.

Como sabrás, existe la posibilidad (estimada en un 15% aproximadamente), de que tu solicitud resulte seleccionada para pasar la “auditoría”. Existe la errónea creencia  bastante extendida de que las auditorías se deben a defectos en la application enviada. Sin embargo, no es así: las auditorías se comunican al interesado en el momento del pago de tasas de examen, es decir, con su application ya aprobada, y son totalmente aleatorias.

En nuestro próximo post comentaremos qué pasa si nos auditan, pero ya os adelanto que tampoco supone ningún problema, y que las auditorías se superan sin ninguna dificultad.

Aula virtual

Nueva política para el examen PMP®

Con carácter efectivo inmediato, PMI® y Prometric han decidido el siguiente cambio para el formato en el examen de las certificaciones del PMI®: No se permitirá tomar ninguna nota durante los 15 primeros minutos de tiempo correspondientes al tutorial del examen. La nueva política explicita del PMI® para el examen PMP®:

  • Los candidatos que realizan el examen podrán comenzar a utilizar las hojas para notas/apuntes una vez que el examen haya comenzado oficialmente.
  • Realizar un “volcado de memoria” durante el tutorial de 15 minutos o incluso previo, ya no está permitido.
  • Todas las hojas de papel utilizadas durante el examen serán recogidas a la finalización del mismo.

Esta nueva política parece indicar que ya no se permite usar un “volcado de memoria”, pero lo único que refleja es que ya no se puede hacer durante los 15 minutos del tutorial del examen. Se puede esperar hasta que el examen haya comenzado oficialmente y una vez que esto ocurra, y no antes, se puede escribir el volcado de memoria. El impacto obviamente es que se resta tiempo de dedicación a resolver preguntas del examen, y si tu preocupación es si el tiempo- 4 horas– es suficiente para responder a las 200 preguntas, puede ser que valores no realizar el volcado.

Por lo tanto, la principal conclusión de la nueva política es que hay que decidir si dedicar o no un tiempo durante el examen a realizar este volcado de memoria, según las capacidades y preparación de cada uno. En todo caso como esta nueva política se acaba de publicitar, su exacta implementación podría variar de un centro examinador a otro, y es mejor preguntar antes de comenzar el examen:
¿Qué puedo escribir en las hojas de apuntes y cuando puedo empezar a escribir?

Recordar también que un volcado de memoria no es más que un apoyo al examen PMP®, pero no te va hacer aprobarlo o no pasarlo.

PMP2

Best TIPS for the PMP Exam

The PMP® exam has a lot of situational questions, i.e. we should answer many questions about the real behavior in project management so we need to figure out and try to identify «What is the best thing you could do«, «What is following action to do…» or «You therefore…» .

We must therefore assume that certain «conditions» are being fulfilled in such situations, for example: We assume that we are integrated in a large project in different locations and with a multi-cultural international team. Our projects are always of high-cost, long-term and many resources.

Sometimes, especially when we have spent so much time in the PMP exam – 4hours- and we are tired or there are big questions, it may be a good option/approach to read first the possible answers and then read the question. In this manner we got a better approach into the question and it is easier eliminating the superfluous in the same time of the reading of the paragraph.

tips examen PMP

Let us look at this example:

You are in the early stages of a project to assemble a new optical telescope with a segmented mirror of more than 10 meters of diameter. You need a number of engineers including ones with specialties in mechanical, environmental, and systems engineering. In the early stages of this project, your resource pool includes a large number of both junior and senior engineers in the various specialty areas. However, as the project progresses—
a. Fewer systems engineers will be needed
b. The resource pool can be limited to those people who are knowledgeable about the project
c. To complete the project on time, you will continue to require access to a large number of engineers in their specialty areas
d. You will only need junior level engineers as the senior level people can be used early in the project to mentor and train them

First we are going to read the last paragraph of the question: «However, as the project progresses…», and then we read the four possible answers. The answers a. and d. are easily disposable in the first review because are focused on a «how-to» very specific. You should remember that the PMBOK® is a general guide for the project management profession
PMBOK® is a framework of good practice in project management but it is not a project management methodology.
We can understand that PMBOK® says «what» but not «how specific»: when an answer of the PMP® exam lead to think that «always «or «never » something should be done in a certain way we have to suspect that this is not the valid option. Responses that include «probably» or «frequently» will be better options.

The correct choice may be selected among the answers b. and c.

Now as we read the question from the beginning really should be easier for us identifying that the relevance of the question is indeed to know how to manage a pool of resources in a large-scale project in the most optimal way. In this case the best answer is b: The resource pool can be limited to those people who are knowledgeable about the project.
Resource calendars are an input to the estimate activity resource process and to the estimate activity durations process. They are used to estimate resource use. Early in a project, the resource pool might include people at different levels of expertise in large numbers, but as the project progresses, the resource pool then can be limited to those people who are knowledgeable about the project because of their work on it. [Planning]

Pieza Certificado PMP

Buenas prácticas en el examen PMP®

El examen de PMP® tiene muchas preguntas situacionales, es decir, plantea muchas cuestiones posibles sobre la gestión de un proyecto que hay que discurrir y tratar de identificar «Qué es lo mejor que podrías hacer», «Qué es lo siguiente que harías», …  y por tanto, debemos asumir que ciertas “cosas” se cumplen en dichas situaciones, por ejemplo: Hay que asumir que estamos integrados en un gran proyecto en diferentes localizaciones y con un equipo multi-cultural e internacional. Nuestros proyectos son siempre de mucho coste, mucho plazo y muchos recursos.

En algunos casos, especialmente cuando llevamos bastante tiempo transcurrido de las 4 horas de duración del examen PMP® y estamos cansados, o las preguntas son muy largas, puede ser buena opción leer primero las respuestas y luego leer la pregunta. Con esto conseguimos centrar mejor la cuestión y eliminar lo superfluo en el momento de la lectura del párrafo.

tips examen PMP

Veamos este ejemplo:

Eres director de un proyecto para la construcción de un nuevo telescopio óptico de espejo primario segmentado de mas de 10 metros de diámetro y estas en la fase inicial del proyecto. Necesitas un número estimado de ingenieros de diversas especialidades incluyendo ingenieros mecánicos, ingenieros de sistemas y técnicos de montaje. En las etapas iniciales del proyecto, el fondo de recursos incluye un gran número tanto de ingenieros senior como junior para las diferentes especialidades. Sin embargo conforme el proyecto vaya progresando:

a. Se necesitaran menos ingenieros de sistemas.
b. El fondo de recursos puede estar limitado por aquellas personas que conocen el proyecto.
c. Para completar el proyecto en tiempo, continuarás requiriendo acceso a un gran número de ingenieros de sus áreas de especialización.
d. Sólo necesitaras ingenieros de nivel junior ya que la gente de nivel senior puede ser usada inicialmente en el proyecto para dirigirlos y entrenarlos.

Leemos el último párrafo de la pregunta: «Sin embargo conforme el proyecto vaya progresando». De las posibles repuestas, la a. y la d. son fácilmente descartables en la primera evaluación. Son repuestas muy centradas en un «cómo» muy especifico, alejado del objetivo de una guía como el PMBOK® Guide generalista de buenas prácticas.

La Guía del PMBOK® es un marco de buenas prácticas de gestión de proyectos, no es una metodología. Es decir, la Guía del PMBOK®  dice el qué, pero no el cómo específico: cuando una respuesta del examen lleve a pensar que “siempre “o “nunca “ habría que hacer algo de una determinada manera, tenemos que sospechar que esa no es la opción válida. Respuestas que incluyan “probablemente” o “con frecuencia”, serán mejores opciones.

Las dudas pueden estar centradas en las respuestas b. y c.

Conforme leemos la pregunta desde el comienzo, realmente nos debería ser más sencillo interpretar e identificar que lo relevante de la cuestión es efectivamente saber cómo gestionar un pool de recursos en un proyecto de envergadura de la forma más optima, y en este caso la respuesta más correcta es la b.: podría ser que al comienzo del proyecto se incluyan muchos perfiles de diferentes niveles de experiencia, pero conforme un proyecto va progresando, el fondo de recursos puede estar limitado por aquellas personas que conocen el proyecto (lo conocen ya que trabajan en el proyecto).

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€

 

Gracias por tu consulta

Enhorabuena a nuestros últimos Alumnos PMP® certificados

¡Tasa del 100% de Aprobados en el Examen PMP®!

En Gestionproyectos estamos de celebración, todos nuestros alumnos que se han presentado al examen de certificación PMP® durante estas últimas semanas han logrado el objetivo: ¡Enhorabuena a los nuevos PMPs®*!. Algunos de ellos:

  • Antonio Manuel Vargas Alcaide. PMP Number: 1829033
  • Sergio Alvarez Timón. PMP Number: 1823971
  • Joan r Solà. PMP Number: 182722
  • Antonio Jimenez. PMP Number: 1810590
  • Roberto Mendez Vidal. PMP Number: 1824002
  • Carlos Javier Gómez-Limón Sanchez. PMP Number: 1810660
  • Fernando Poveda. PMP Number: 1819496
  • Maitane Urdangarin. PMP Number: 1816638
  • Isabel Sánchez Ruiz. PMP Number: 1850199
  • Luis Conde Miranda. PMP Number: 1850560

*Acceso al registro oficial del PMI®: https://certification.pmi.org/registry.aspx

Sin duda es una demostración del compromiso del equipo de Gestioproyectos con nuestros clientes y del éxito de la metodología de aprendizaje que proponemos, dividida en tres fases o etapas que pueden superponerse:

Fase de Conceptualización=Asistencia Curso:

Basado en nuestra plataforma de Aula Virtual, con los webinars teóricos, documentación y apuntes entregados; y en las sesiones online en directo del curso con los objetivos de:

  • “Apalancar” las claves conceptuales teóricas. Ejemplos:
    • El grupo directivo de Planificación es el único grupo de procesos que puede seguir un orden cronológico determinado.
    • Existen dos flujos que debes tener muy claros: el flujo de la información (datos desempeño del trabajo, información sobre el desempeño del trabajo, informes del desempeño ) y el flujo de los entregables: en qué proceso se desarrollan y se implementan cambios aprobados, en cual se validan, en cual son aceptados por el cliente y/o patrocinador y en cual se realiza la aceptación en conjunto formal y la entrega.
  • Practicar: con preguntas tipo del examen que ayuden a enmarcar en este escenario los conceptos clave, y dónde importa más la calidad que la cantidad.

Fase de Estudio:

  • Solapa con la fase previa de conceptualización.
  • Empezar a estudiar/leer con mayor intensidad los recursos (diagramas, mapas conceptuales, …) y apuntes de resumen entregados con el curso, apoyado con el PMBOK 5º ed.
  • No es recomendable empezar por estudiar directamente el PMBOK® porque es un material de referencia, no está pensado como material de estudio.
  • Además, tener en cuenta que un porcentaje de las preguntas del examen (un 25%?) no están directamente extraídas del PMBOK®, sino que provienen de otros textos y bibliografías recomendadas.

Fase de ensayo de test de examen:

  • En la última fase de preparación previa al examen, dedicar a ensayar muchas preguntas, cuantas más mejor.
  • Se puede usar el simulador recomendado y otras fuentes de preguntas y simuladores, gratis y de pago. Debes tener una tasa aproxima de 80% de aciertos para presentarte con garantías al examen, ya que aunque el porcentaje necesario para pasar el examen PMP® será mas bajo, el rendimiento el día del examen en menor.
  • Sin apoyo directo de la documentación de estudio, como si se estuviera haciendo el examen real.
  • Es muy importante el rendimiento en el examen (en media, 1m20” por pregunta). Simular un examen real de 4 horas (200 preguntas).

 

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,…