Los 7 NO del Scrum Master

Hola amigos, no crean que los he dejado en el olvido. El tren del proyecto ha tenido muchos viajes entre proyectos y capacitaciones y por este motivo no se ha detenido en esta estación. Pero en cada una de sus rutas ha recopilado experiencias, errores, éxitos y mejores prácticas.

Quería compartirles algunos tips para los #ScrumMaster y los equipos ágiles.

1- No son un grupo de personas, son un equipo donde todos gozan del triunfo y luchan para que un Sprint no fracase. Que satisfactorio es ver al equipo comportarse como una unidad, dejando de lado el individualismo. Como Scrum Master nos corresponde fomentar el trabajo en equipo para lograr obtener lo objetivos del Sprint. Esta formación del juego de #Rugbi es un vivo ejemplo de lo que debe de suceder en el día a día en los equipos de trabajo.

2-No tener un registro de incidentes o «issue log». El sprint es muy corto como para almacenar incidentes, si el equipo tiene un impedimento, libérelo lo antes posible. Es normal pensar en donde se debe de documentar todos esto issues o incidentes, pero debemos de recordar que lo mas importante es solucionarlos, en un sprint de una semana si un incidente o impedimento se encuentra vivo por más de un día, la afectación al Sprint es inminente.

3-No distanciarse del #ProductOwner. Trabajemos de cerca con el negocio, mientras más cerca mejor. No necesariamente tienen que ser los mejores amigos, no exageremos, pero si es importante la comunicación constante. Si como #ProjectManager requería que estuviera 95% en #comunicación, ahora como Scrum Master me requiere el 110%. La comunicación cara a cara y constante es clave, además el involucramiento del negocio nos lleva cada vez mas cerca a satisfacer sus necesidad y por ende al éxito del proyecto.

4-No ser un generar dependencias. Recordemos que el equipo debe de ser auto-organizado. Volvamos a ser como niños donde jugábamos y nos auto-organizábamos para ellos. Rompamos las dependencias y que los equipos puedan tomar sus propias decisiones para lograr el compromiso adquirido.

5-No piense solo en Scrum. Busquemos coexistir con otras prácticas agiles, esto nos dará mejores resultados. Las diferentes #metodologías, #Framewok y herramientas ágiles pueden convivir juntas, no limitemos a una sola.

6-No soy un «SuperMan», somos la «Liga de la Justicia». Los tiempos del superhéroe solitario que salva el proyecto ya paso de moda. Ya no buscamos un superhéroe que con sus capacidades se eche el proyecto a los hombros. Ahora buscamos tener equipos multifuncionales por que juntos somos mas fuertes.

7-No te van a querer. Normalmente entramos en una organización a generar cambios y la resistencia al cambio suele ser fuerte. Tenemos que llegar a convencer con hechos y dar el ejemplo. Para realizar este cambio busquemos apalancarnos de stakeholder claves para que el esfuerzo tenga un respaldo de peso, en caso contrario no es imposible pero serás más difícil.

Hoy cerramos un grupo más con la formación de 20 Scrum Master nuevos, certificados como Scrum Master Professional Certificate SMPC® y Scrum Foundations Professional Certificate (SFPC)

Espero les sirvan estos 7 tips, existen muchos más, los insto a compartirlos en los comentarios y que los discutamos en conjunto, así entre todos ir mejorando en la práctica.

Nos vemos en el próximo viaje!

¡Vacas Sagradas!

A cuantos de ustedes les han dado esta advertencia: «Tenga cuidado esta tocando vacas sagradas»…lo entendería si estuviera trabajando en la India, donde la vaca es un animal sagrado. Pero esto me ha sucedido en algunas organizaciones cuando se trata de aplicar la agilidad.

Actualmente vivimos en un entorno lleno de incertidumbre, cambiante, donde no podemos basarnos en estructuras y mecanismos que presumen predictibilidad para un mundo estable, el cual no poseemos.

Simplemente en entornos impredecibles no podemos aplicar métodos tradicionales, lastimosamente muchas veces las «vacas sagradas» se encuentras muy apegadas a estos mecánicos que son pocos funcionales si lo que queremos es avanzar y no perder la oportunidad de ganar esta ventaja competitiva que es la adaptabilidad.

Hay que entender que esto conlleva cambio en la planificación estratégica y en lugar de buscar generar luchas, tenemos que buscar aliados para promover estos cambios.

La primera vez que escuche esta frase, me llamo mucho la intensión, ya que no era mi intención, pero inmediatamente entendí el por qué me lo advertían….me puso a analizar y pensar un poco, hasta preguntarme: En realidad estoy haciendo lo correcto?

Me encuentro leyendo el libro de Michael N. Kennedy «El desarrollo de productos en TOYOTA», en este libro se explica un caso de estudio, donde el autor explica como desactivar la resistencia al cambio existente en toda organización y dentro del dialogo del caso que se expone, me encuentro lo siguiente:

Creo que fue mi respuesta a la pregunta. El simple hecho de tratar de cambiar el mindset de las personas y buscar aplicar transparencia, inspección y adaptación en las prácticas cotidianas, saca de su zona de confort a muchas estructuras organizacionales.

Necesitamos generar ingeniería basada en el conocimiento en las organizaciones y salirnos del esquema basado en el entorno de la estructura de actividades. Seguir más un esquema de responsabilidades en lugar del esquema de tareas.

Mientras más nos logremos adaptar rápidamente ocuparemos tambien una toma de decisiones descentralizada y evitar las estructuras rígidas.

Mecanismos como Kanban y Kaisen utilizados en empresas como Toyota, nos pueden servir para romper paradigmas.

Cuentame como recomendarías hacer el cambio: ir de poco a poco o transformar toda la empresa de golpe?

Porqué tenemos dos orejas y una boca?

Zenón de Citio afirmó que “para oír más y hablar menos”, Epícteto dijo que “para que podamos observar y escuchar el doble de lo que hablamos”, Plutarco defendió que “para saber hablar es preciso saber escuchar”.

Tenemos que hablar menos y escuchar más. Tenemos escuchar el doble de lo que hablamos, para asegurar que se entrega el mensaje adecuado, a la audiencia del Proyecto adecuada, y en el momento correcto.

El 90% del tiempo que invierte el Project Manager dentro del tiempo del Proyecto lo usa para comunicarse, de ahí la importancia de dirigir el proyecto hacia el éxito y minimizar los riesgos.

Les comparto una publicación que dice Para ser un buen líder, aprenda a centrarse y escuchar a sus empleados.  En mi caso yo la aplico de esta manera: “Para ser un buen líder, aprenda a centrarse y escuchar a su equipo y a sus stakeholder para gestionarlos y lograr el involucramiento adecuado al proyecto”.

En todos los proyectos la comunicación es vital, pero cuando estamos implementando marcos de trabajo ágiles en gestión de proyectos, o haciendo un híbrido entre predictivo y ágil; la importancia de la comunicación se multiplica, debido a que es un cambio de la forma en que vemos los proyectos tradicionalmente y eso hace que las expectativas del mismo se puedan mal interpretar.

Los invitó a seguir en el #TrendelProyecto comunicándonos de forma efectiva, apoyándonos y compartiendo recomendaciones sobre nuestras lecciones aprendidas, de esta forma cada un de nosotros podremos ir mejorando día con día.

 

Costa Rica Ágil y los «Elefantes que deben de aprender a correr»

En el transcurso de varias semanas he participado impartiendo varios talleres al sector público sobre el marco de trabajo de Scrum, logramos certificar a +100 personas certificadas de diferentes entidades públicas.

Mediante este blog quisiera compartirles algunas lecciones aprendidas de la experiencia y como hacer que estos «Elefantes empiecen a correr»

Esta analogía de los «Elefantes» la he tomado de la columna semanal del BBVA Bancomer donde se hace referencia de la necesidad de mover esos «Elefantes» pesados y lentos (entidades bancarias de alta regulación y complejas) lo más rápido posible.

Existe una frase que me gusta utilizar la cual dice «Scrum es fácil de entender, pero extremadamente difícil de aplicar».  En principio suena contradictorio, pero es muy cierta.

Scrum es muy fácil de entender, en un breve resumen podemos decir que tenemos: 3 Roles, 4 Ceremonias y 3 artefectos, los cuales contienen pocas reglas y sencillas a la vez.

Todos estos elementos interactuando en diferente momento durante el ciclo de cada Sprint, siempre teniendo claro los 12 principios del Manifiesto Ágil

 

Entonces, porqué se convierte en extremadamente difícil de aplicar?

Compartiendo con varios de los participantes de estos talleres las estructura organizacionales y sus procedimientos actuales no se encuentran listos para dar este paso. Hay que hacer cambios de políticas y normativas en aras de que los proyectos generen el mayor valor posible para la organización y en el menor tiempo.

Por ello es necesario cambiar de su forma tradicional de trabajo, de su forma de pensar y de su forma de actuar.  Dejar de lado la gestión el pensamiento tradicional y predictivo, haciendo un cambio hacia el mundo ágil y adaptativo, o hasta hacer un híbrido de ambos mundos, aplicando lo mejor de ellos.  Todo esto conlleva realizar un cambio de la cultura de la organización lo cual no se logra de la noche a la mañana.

 

Mito 1: «Scrum es solo para proyectos pequeños».

Un error es pensar que Scrum solo funciona para proyectos pequeños, este pensamiento muchas veces lo respalda a partir de que el tamaño del equipo de Scrum  es de máximo de 10 personas según el SBOK Guide tercera edición. Esto no implica que no pueda tener varios equipos de Scrum trabajando, para lo cual se utiliza el «Escalamiento de Scrum en Grandes Proyectos»

Mito 2: «Scrum es solo para proyectos de Software»

Aunque Scrum es muy utilizada para proyectos de desarrollo de Software por la naturaleza de estos proyectos y por la malas experiencias de  la metodología de desarrollo de cascada, en Costa Rica se ha utilizado además en otras áreas.

«Compañías de educación, implementación de estrategia, diseño gráfico e incluso hardware ya han ejecutado agile.» Tomado de El Financiero.

No es una receta, es un marco de referencia de trabajo.  Debe de existir un diagnóstico inicial para identificar cuando aplica o no un marco de trabajo como el de Scrum.

Mito 3: «En Scrum no se documenta»

Es cierto, no existe una documentación excesiva, pero si existe la documentación necesaria, en el SBOK Guide tercera edición se indica el uso de «historias de usuario», «Backlog» y el «Sprintbacklog» para documentar los requerimientos de los usuarios.

Específicamente en mis proyectos, ademas de esto, utilizó otras herramientas y documentación que no están necesariamente bajo el marco de Scrum, pero que me facilitan y ayudan a prever muchos problemas que pueda identificar en la organización.

---

Por último, un buen ejercicio que realizamos durante el talle fue realizar «Mi ciudad de Legos», donde yo como usuario final no tenía claro que era lo que quería en su totalidad, y cada iteración al ir conociendo el producto solicitaba cosas nuevas o modificaba los requerimientos iniciales (típico de los usuario finales).

En este pequeño ejemplo se evidenció lo difícil que es iniciar los trabajos e interactuar entre varios equipos de Scrum y entre todos como equipo llegar a una misma meta.  Pero también, quedó claro la aplicación de la teoría de Tuckman y además como al utilizar las reuniones de revisión en cada ciclo se aclaraba cada vez más el alcance del entregable.

 

Existen muchos «Elefantes» pero no es imposible hacerlos correr en este mundo que cambia velozmente.

Para finalizar, un gran agradecimiento a #Cenfotec en Costa Rica por organizar todas estas capacitaciones y a #Certiprof por todo el apoyo brindado.  Seguiremos aportando hacia una Costa Rica Ágil.

 

Ágil o Predictivo

En estos días he escuchado diferentes versiones que dicen:

«Ágil no sirve para los proyectos, es solo una moda»

«La gestión de proyectos según PMI es muy complicada»

«Scrum solo aplica para proyectos pequeños»

Que es mejor? Si tuvieras que escoger alguna de las dos píldoras cual tomarías para gestionar tu proyecto?

La clave esta en el ciclo de vida de su proyecto.  Los cuales pueden ser predictivos, iterativos, incrementales, adaptativos o un modelo híbrido.

Ágil o adaptativos

En este tipo de proyectos el alcance detallado se define y se aprueba antes del comienzo de una iteración.

Predictivo o Cascada (waterfall)

En cambio en el predictivo, el alcance, el tiempo y el costo del proyecto se determinan en las fases tempranas del ciclo de vida.  Cualquier cambio en el alcance debe de gestionarse cuidadosamente.

El modelo conocido como Cascada o Waterfall se origino en 1970 por el Dr. Winston Royce al escribir el paper que hizo historia «Managing the Development of Large Software Systems».  El cual en realidad al analizarlo en realidad no recomienda este método, prevé sus riesgos y sugiere que se debe de iterar por lo menos dos veces.  Ademas el mismo paper menciona que invita al fracaso.

Entonces, cuando utilizo un modelo ágil y cuando un modelo predictivo? 

En mi caso todo ha dependido del tipo de proyecto, la industria en el que se encuentre y del tipo de estructura organizacional en la que se encuentre desarrollándose.

Cuando los interesados no tienen claro el alcance del proyecto (suele pasar mucho en software) he utilizado el marco de trabajo de Scrum, lo cual permite entregar mayor valor al inicio del proyecto y que los interesados vayan conociendo funcionalidades del producto y de esa forma ir planificando de manera progresiva. Hay que tener claro que para esto también es necesario tener un contrato ágil (sobre este tema hablaremos luego)

Por otro lado, cuando se tiene el alcance claro al inicio se puede optar por una gestión para un proyecto de forma predictiva.  Hay que recordar que los procesos del PMBOK no son una metodología, son mejores prácticas para la gestión de proyectos, donde el  Project Manager debe de seleccionar cuales de los 49 procesos son necesarios de aplicar en mi proyecto específico.  Al igual que los proceso del SBOK son un marco de trabajo para utilizar de la mejor manera dependiendo de la organización en la que se encuentre.

En algunas organizaciones me he enterado que aplican el PMBOK al pie de la letra, lo cual hace que se pierda el valor que pueda dar estas prácticas a la gestión de proyectos y como resultado se cree que estas mejores prácticas no funcionan.

En conclusión, no existe una mejor que otra. Ágil no es una moda, es una forma de adaptarnos al mundo cambiante en el cual estamos viviendo, tanto así, que en la sexta edición del PMBOK ya se encuentran algunas de herramientas del marco de trabajo de Scrum (burndown chart) como herramientas a utilizar bajo las mejores prácticas del PMBOK.

Para finalizar, el tamaño del proyecto no es una referencia para optar por Ágil o Predictivo, independientemente del tamaño del proyecto se puede utilizar tanto Scrum como prácticas del PMI.

Cual ha sido su experiencia?

 

 

 

 

 

 

 

 

 

 

 

Como hacer que una PMO fracase?

En la semana anterior se subieron un par de pasajeros al tren del proyecto en diferentes viajes y me comentaban algo en común: sus malas experiencias en la ejecución de una PMO (Project Management Office).

 

Cada uno de ellos mostraban un poco desilusionados de ver como en la organización un profesional PMP llego a implantar la PMO y sus resultados no son los mejores.  Lo cual pone en tela de duda la Oficina de Gestión de Proyectos, su necesidad y su funcionalidad.

 

En Costa Ricas es muy común ver una PMO funcionando en organizaciones transnacionales las cuales traen dentro de sus políticas y cultura la estructura de una PMO.  En algunas organizaciones gubernamentales ya se encuentran algunos esfuerzos y en otras privadas el tema ya va naciendo poco a poco.

 

Me parece importante contener en este tren una serie de pasos que puedes seguir en caso de que quieras hacer que una PMO fracase:

 

1. No realice un diagnóstico de la organización: un diagnóstico de la situación actual no sería necesario.  Debido a que este diagnóstico te daría un panorama del terreno actual y un reconocimiento de las debilidades existente.
2. No ataque las debilidades: si no realizo el paso anterior, entonces este segundo punto tampoco será necesario. Normalmente es necesario generar una cultura de proyecto en la organización y poseer un lenguaje común debido a que es una carencia de muchas organizaciones. Esto se logra generando conciencia de proyecto mediante capacitaciones y charlas.
3. Imponga sus reglas: al imponer sus reglas como PM el recurso humano no le va a encontrar sentido y esto hará que las siga. Además, si soy un recurso que he trabajado años de forma empírica en proyectos para que voy a seguir ahora reglas de una oficina de proyectos
4. No busque demostrar los resultados con proyectos pequeños: si ya impuso sus reglas para que va a demostrar resultados. Al demostrar aplicar las mejores prácticas de gestión de proyectos en proyectos pequeños, esto servirá para demostrar los buenos resultados y evidencias que existen mejores formas de gestionar los proyectos.  Cuando los recursos de otros proyectos observan estos resultados, sentirán curiosidad y querrán conocer que es lo que se está haciendo diferente.
5. Implemente una documentación y herramientas excesivas: este es un paso infalible para que la PMO fracase, debido a que la mayoría de las personas encontrar en los procesos de la PMO una pérdida de tiempo y verán el uso de las herramientas como innecesarias. Recuerde que depende del tipo de proyecto existen Herramientas adecuadas para el tipo de proyecto que se trabaja y documentación esencial para el mismo.
6. No realice ningún plan de divulgación: al realizar un plan de divulgación o comunicación en un proyecto como estos, el cual afecta a nivel de toda la organización esto tendrá un efecto de conocimiento e involucramiento por parte de los stakeholders.

 

Por otro lado, es bueno recordar que existen varios matices de PMOs en las organizaciones.  Las cuales pueden ser:

1. De apoyo: este tipo de oficina de proyecto tiene un rol de consultoría para los proyectos.  Suministrado plantillas, mejores prácticas, capacitaciones y lecciones aprendidas.
2. De control: esta PMO proporciona soporte y exige cumplimiento por diferentes medios
3. Directiva: en esta última ejerce el control del proyecto asumiendo la dirección de los mismo.

El tipo y la estructura de PMO va a depender del tipo de organización y sus necesidades y recuerde que:

,

Cual crees que pueda ser otro paso para que la PMO no tenga éxito?

El PMI reconoce las estructuras organizacionales híbridas

Muchas veces al intentar llevar la teoría a la práctica, tratamos de identificar en qué tipo de organización nos encontramos, pero no logramos ubicar una estructura organizacional la cual sea exactamente en el que estamos trabajando en nuestro proyecto.

Las empresas tienen características diferentes aunque se encuentren  trabajando en la misma industria.  Cada una de ellas se organizará de cara a las actividades propias de su actividad comercial y su objetivos estratégicos.

Esto es muy sencillo de entender, todas las organizaciones son organismos vivos y dinámicos, los cuales se encuentran en constante cambio debido a muchos factores del entorno, por ejemplo la tecnología con la que contamos hoy en día y las nuevas generaciones de recurso humano que son la motor que mueve la empresas.

En estos escenarios las organizaciones deben de adaptarse a todas estas nuevas necesidades para sobrevivir en un entorno empresarial turbulento, lo cual obliga que los proyectos y su gestión deben convivir también con estas nuevas demandas, buscando la satisfacción del cliente y generando un mayor valor para la empresa.

Debe ser partes de las habilidades del director del proyecto el detectar con cual tipo de estructura organizacional se encuentra trabajando y mejorar su actitud para mejorar su valor como administrador del proyecto.

Los procesos de gestión de proyectos deben de tomar en cuenta estos tipos de estructura organizacional entre los cuales se encuentran:

 

Orgánico o sencillo:	En este tipo estructura el trabajo es ordenado por las personas que trabajan hombro con hombro y muchas veces el mismo dueño es la persona que gestiona el presupuesto del proyecto.  Este tipo de estructura es muy común verlo en organizaciones pequeña.
Funcional:	Estructura orientada en algunos en muchos casos en organizaciones gubernamentales donde existe un gerente funcional. En este tipo de organizaciones el problema se da en la disposición del recurso para realizar el proyecto, debido a que su prioridad serán sus funciones principales en la organización y no el proyecto.
Multi-divisional:	Existen grupos de trabajo ordenados por procesos de producción, regiones geográficas, tipos de cliente.  En este tipo de estructura organizacional pueden duplicar funciones en cada división con poca centralización.
Matricial fuerte:	La organización en este tipo de estructura donde existe un director de proyecto designado a tiempo completo y este es la persona responsable de gestionar sus recursos.
Matricial débil:	El director del proyecto en este tipo de organización se encuentra de tiempo parcial, de igual forma el gerente funcional es la persona que gestión el presupuesto del proyecto.
Matricial -balanceado	Esta estructura organizacional es una mezcla entre la matricial débil y matricial fuerte donde el presupuesto del proyecto es gestionado de forma mezclada entre el director de proyecto y el gerente funcional.
Orientado a proyecto:	Este tipo de organización es la ideal para todas aquellas que trabajan todos los días con proyectos, planificando proyectos y ejecutando proyectos.  Donde los grupos de trabajo son organizados por los proyectos y la autoridad del director del proyecto es casi total.
Virtual	Con todos los avances tecnológicos y las nuevas generaciones existentes, hoy en día es muy común ver organizaciones donde el teletrabajo es lo más normal.  En este tipo de organizaciones distribuidas el trabajo se encuentra en una estructura de red con nodos en puntos de contacto con otras personas.
Híbrido	Como la misma palabra lo dice este tipo de organización tiene una mezcla de todas las anteriores, donde no predomina un matiz especifico, este tipo de organización se ha ido adaptando según las necesidades incorporando las características según sus necesidades.
PMO	Hace referencia a una oficina u organización de dirección de proyectos, programas y/o portafolios.  Por este motivo dando una importancia al director del proyecto el cual se encuentra tiempo completo y gestionando el presupuesto del proyecto.

Veamos estas estructuras como las líneas del tren para nuestro viaje, cual creen que es la mejor estructura organización sobre la cual deba de viajar su proyecto?

Valor del Project Manager

Muchos pensaran en todas las fórmulas correspondientes al valor ganado y aún así no encontraran relación lógica con esta fórmula.

Están en lo correcto, esta fórmula no se encuentra en los procesos PMBOK® 6, ni en los procesos de Guía SBOK™. Pero creo que es muy necesaria para gestionar los proyectos.

Hace unos días vi un vídeo en el TEDx sobre esta fórmula y estuve recapacitando el impacto que tiene tanto en la vida personal como en los proyectos que he participado.

Donde,

V = al valor de la persona
C = Capacidad
H = Habilidad
A = Actitud

V=(C+H)*A

Como los dice Victor Kuppers en su video, en esta fórmula, la capacidad suma a la habilidad.  Un director de proyecto siempre es importante que posea la capacidad para dirigir el proyecto y además las habilidades necesarias dentro del mismo, pero lo que en realidad multiplica es la actitud que tenga esta persona

Podemos tener en un proyecto un director de proyecto con gran capacidad y excelentes habilidades pero una pésima actitud y esto hace que el valor como director de proyecto caiga de forma exponencial.

La experiencia me enseñado que no es necesario ser un dictador para que las cosas se realicen, tampoco es necesario ser un centinela en los equipos de trabajo.

Claro esta, que tampoco hacemos nada teniendo solamente una gran actitud.  Por eso podemos aplicar esta fórmula del valor de la persona y convertirla al Valor del Project Manager.

Muchas veces la actitud con la que gestiona un proyecto se contagia a los demás y esto multiplica el valor de un director de proyecto.  Los invito a que contagien a todos los pasajeros en el Tren del Proyecto que estén desarrollando y que compartan sus resultados.

Adjunto el video para que lo puedan disfrutar y lo más importante aplicar esta fórmula en su vida.

 

Qué hay de nuevo en el PMBOK 6?

Este tren ha dado inicio su viaje mediante las líneas del Internet, en el momento en que el PMI ha lanzado su versión del PMBOK 6ta edición, por lo tanto, no podemos dejar pasar el hacer una revisión a alto nivel sobre lo nuevo que podemos encontrar en él.

Procesos nuevos:

4.4 Gestionar el Conocimiento del Proyecto

9.6 Controlar los Recursos

11.6 Implementar la respuesta a los Riesgos

Procesos que cambian de nombre

6.Gestion del tiempo del proyecto, cambia su nombre a 6. Gestión del Cronograma del Proyecto

8.2 Realizar Aseguramiento de Calidad, cambia su nombre a 8.2 Gestionar la Calidad

9.Gestion de los Recursos Humanos del Proyecto, cambia su nombre a 9. Gestión de los Recursos del Proyecto, cambiando así no solamente el nombre el proceso, sino también ahora incorporando los recursos del equipo como los recursos físicos.

9.1 Planificar la Gestión de los Recursos Humanos, cambia su nombre a 9.1 Planificar la Gestión de Recursos.

9.2 Adquirir el Equipo del Proyecto, cambia su nombre a 9.3 Adquirir Recursos

9.3 Desarrollar el Equipo del Proyecto, cambia su nombre a 9.4 Desarrollar el Equipo

9.4 Dirigir el Equipo del Proyecto, cambia su nombre a 9.5 Dirigir el Equipo

10.3 Controlar las Comunicaciones, cambia su nombre a 10.3 Monitorear las Comunicaciones

11.6 Controlar los Riesgos, cambia su nombre a 11.7 Monitorear los Riesgos

13.2 Planificar la Gestión de los Interesados, cambia su nombre a 13.2 Planificar el Involucramiento de los interesados

13.4 Controlar la participación de los interesados, cambia su nombre a 13.4 Monitorear el Involucramiento de los Interesados

 

Procesos que se re-ubican en otra Área de Conocimiento

6.4 Estimar los recursos de las actividades, pasa a estar fuera del área de conocimiento de tiempo para reubicarse en el área de conocimiento de 9. Gestión de los Recursos del Proyecto

Procesos que se eliminan

12.4 Cerrar las adquisiciones

Por otro lado, en esta nueva versión, ahora tenemos una nueva línea base como parte del Plan para la Dirección del Proyecto.

---

En el Mapa de Procesos se muestran los 49 procesos de la Gestión de Proyectos contemplados en el PMBOK sexta edición. Este Mapa de Procesos se irá actualizando poco a poco, de tal forma que podamos navegar entre todas las herramientas, entradas y salidas de cada proceso.

Si este tren tuviera que escoger alguno de estos procesos como la siguiente parada, cual crees que debería de ser la más indicada?

Espero que sea de aporte esta pequeña actualización, saludos.

 

Tren del Proyecto

Bienvenidos al blog dedicado para usted y sus proyectos.

La idea inicial de este blog que compartamos experiencias como Administradores de Proyectos utilizando las mejores prácticas del PMI.  Además de aportar conocimientos como Scrum Master y Product Owner en los equipos ágiles que se encuentran detrás de los proyectos de la organización.

Por que el «Tren del Proyecto«?

Todo proyecto debe de ser un viaje hacia un destino definido.  Esta analogía, me permite analizar como en esta travesía se incorporan diferentes pasajeros durante el viaje, los cuales nos pueden acompañar todo el camino o abandonar el tren en el transcurso del mismo, dejándonos experiencias buenas o malas.

Por otro lado, podemos ver nuestro proyecto como un tren con diversos vagones, tantos como sean necesarios durante el viaje, donde cada vagón representará un área o etapa específica, pero todos en conjunto conforman un solo tren.

Nuestro viaje puede verse afectado por situaciones de diversas índoles, lo importante es lograr llegar a nuestro destino de una forma exitosa. Por eso les doy la más grata bienvenida a todos aquellos que quieran en rumbarse en un viaje de aprendizaje mediante el Tren del Proyecto, las consultas o aportes sobre temas que deseen que sean abordados en este tren serán todos bienvenidos…saludos a todos los nuevos pasajeros!