Negociación y Conflictos, PMP/CAPM, Project Management

¿Conoces las diferencias entre Gestión Tradicional y Agile?

En el artículo de hoy quiero hablarte de las diferencias principales entre una gestión de proyecto tradicional (también conocida como waterfall) o una gestión Agile.

También quiero darte algunos consejos para que sepas en que casos te conviene utilizar una u otra, ya que como en otras áreas de la vida, no hay una solución mágica para todo.

Lo importante para un gestor de proyectos es contar con el mayor abanico posible de herramientas y conocimientos.

Esto nos va a permitir seleccionar los mejores planteamientos en cada caso y hacer un “tailoring” adecuado para cada proyecto, dependiendo las circunstancias.

Antes de comenzar a ver las diferencias entre una gestión de proyectos más tradicional o una basada en prácticas ágiles, me gustaría recordar que no es mejor una que otra, simplemente en algunos casos conviene usar una y en otros otra.

Diferencias principales entre la Gestión Waterfall y la Gestión Agile

Una de las principales diferencias en la gestión de proyectos empleando métodos ágiles es la elaboración progresiva.

En vez de realizar un análisis y planificación detallada al inicio del proyecto, vamos a ir trabajando en bucles (también conocidos como iteraciones o sprints)

La idea es poder adaptarse al cambio sin demasiada fricción.

Lo que se busca con la agilidad es obtener cuanto antes un producto mínimo viable que poder presentar al cliente y luego ir trabajando con incrementos de valor en cada ciclo o iteración.

No se da por válida una iteración si no aporta un valor añadido al producto del proyecto.

Después de cada iteración, se revisa lo que ha funcionado y lo que no para tenerlo en cuenta en las siguientes.

Este enfoque de elaboración progresiva basado en ciclos iterativos nos va a permitir responder al cambio mucho mejor y adaptarnos a sus consecuencias.

¿En que casos es recomendable la Gestión Agile vs la Gestión Tradicional?

Pues esto dependerá de cada situación, pero en términos generales, todos aquellos proyectos donde el alcance esté poco definido o sepamos que los cambios en el mismo van a ser muy frecuentes, tiene sentido aplicar prácticas ágiles.

Proyectos tipo desarrollo de software o de I+D son candidatos muy claros a utilizar un enfoque agile, pero no los únicos.

Realmente las prácticas e implementaciones ágiles más comunes como Scrum y Kanban, son aplicables a casi cualquier tipología de proyecto.

Por lo general vale la pena hacerse estas preguntas:

  • ¿Los requisitos y el alcance en general está bien definido y acotado por todas las partes?
  • ¿Hemos realizado un proyecto similar en el pasado y contamos con planes y lecciones aprendidas que nos pueda ayudar?
  • ¿Lo que hoy es cierto y está documentado será siguiendo cierto mañana?

Si las repuestas son positivas, apuesta por una gestión tradicional, bien planificada y por fases (waterfall) si las respuestas son negativas, opta por una gestión Agile.

¿Qué otros factores debo tener en cuenta?

Obviamente intervienen otros factores a tener en cuenta, como por ejemplo la cultura de la organización.

No es posible cambiar la manera de hacer las cosas de un día para el otro, y pasar de trabajar con un sistema de gestión tradicional a uno agile implica entre otras cosas: comunicar bien el cambio, entender el cambio y formar a las personas claves de la organización.

Si los puntos comentados en el párrafo anterior no se llevan acabo adecuadamente y dedican los recursos necesarios para apoyar la transformación, más que agilidad, estaréis implementando el caos en vuestra organización.

¡Quiero saber más sobre los métodos e implementaciones Agiles!

Espero que este artículo te ayude a entender las diferencias principales entre ambos sistemas de gestión y saber escoger el más apropiado según las circunstancias propias del proyecto y la organización.

Si quieres profundizar en estos temas, conocer que supone ser Agile, los marcos y métodos de referencia como Scrum, Kanban, XP y mucho más no dejes de revisar nuestro Curso Agile: PMI ACP + ScrumMaster, posiblemente el curso más completo del mercado para dar el salto a la agilidad.

Alejandro Pérez, PMP, PMI ACP

PMP/CAPM, Project Management

¿Cónoces la Teoría de las Restricciones o TOC?

En las últimas semanas me han hablado de la teoría de las restricciones en varias ocasiones, por lo que he considerado oportuno tratar el tema en este artículo de mi blog para dar a conocer la teoría a todos aquellos que aún no la conozcan.

Las siglas TOC (Theory of Constraints) fueron definidas por Eliyahu M. Goldratt, un doctor en Física Israelí.

Inició su investigación y el desarrollo de su teoría en forma de una novela, su best-seller “La meta”.

En este libro, Eliyahu Goldratt desarrolla su teoría de manera lúdica, en el entorno de una empresa manufacturera sentenciada a la liquidación; su gerente, Alex Rogo, tiene tres meses para recuperar la rentabilidad de la empresa y la estabilidad en su familia.

La teoría se basa en que un sistema (una planta de producción, una empresa, etc) está formado por elementos interdependientes y que, al igual que en una cadena, el sistema sólo puede ser tan fuerte como su eslabón más débil, es decir, la restricción/limitación o cuello de botella.

En este caso el concepto de restricción/limitación es todo aquello que nos limita a conseguir nuestro objetivo.

Existen tres tipos de limitaciones:

1. Limitaciones físicas: son equipos, instalaciones o recursos humanos, entre otros, que evitan que el sistema cumpla con su meta.

2. Limitaciones de políticas: son todas las reglas que evitan que la empresa alcance su meta (por ejemplo: no hacer horas extras, trabajar en otros turnos, no vender a plazos, etc).

3. Limitaciones de mercado: Cuando el impedimento está impuesto por la demanda de sus productos o servicios.

La teoría de las restricciones se basa en cinco puntos correlativos de aplicación:

TOC

Gran cantidad de organizaciones utilizan actualmente como sistema de gestión la teoría de las limitaciones, para identificar los cuellos de botella y buscar soluciones ágiles a los problemas.

Muchos conceptos de mejora continua, Lean Kanban, están intimamente relacionados con la teoría de las limitaciones y la obra del físico israelí.

Si te interesa la teoría de las restricciones y quieres saber más puedes adquirir el libro en Amazon: La Meta de Eliyahu M. Goldratt

Para finalizar os dejo un interesante vídeo que ilustra el contenido teórico del libro:

Alejandro Pérez, PMP, PMI ACP

PMP/CAPM, Project Management

Scrum y 40 Métodos Ágiles – ¿Los conoces todos?

Scrum no es ni de lejos el único framework ágil, aunque si uno de los más extendidos y conocidos.

El artículo de hoy ha sido inspirado por otro publicado en el blog de la consultora Deloitte: Navigating the Agile Landscape

Este artículo ha sido muy comentado en las redes, y aparte de algunas críticas recibidas por la complejidad de los mapas visuales mostrados (se supone que todo lo ágil debe de ser fácil de usar), me ha parecido un interesante y completo resumen.

Ser ágil hoy en día no es tan sencillo como seguir un único método o framework como Scrum, para conseguir el éxito en un proyecto, se necesita, como muchas veces he comentado en mis artículos, “hacer un traje a medida”, es decir utilizar el método o técnica apropiado para solucionar el problema en particular con el que nos encontramos.

Por lo tanto una correcta y exitosa gestión de proyectos hoy en día, requerirá del uso combinado de diferentes técnicas, modelos o frameworks, ágiles y tradicionales así como de la experiencia en gestión del Project Manager y su equipos para conseguir los objetivos marcados.

Os dejo a continuación, el “famoso” mapa de la agilidad creado por el equipo de Deloitte:

Pódeis ver el mapa en movimiento con las diferentes capas incluidas en el post original que os adjuntaba al inicio del artículo.

Hace no mucho escribí en el blog un artículo sobre los 3 métodos ágiles más conocidos: Scrum, XP, Kanban, pero no son ni mucho menos los únicos frameworks existentes en el mercado, habiendo más de 40 (incluyendo algunas modificaciones de los originales).

Me ha parecido interesante adjuntaros también este SlideShare de Craig Smith, donde se describen estos métodos y frameworks, entre ellos Scrum, de manera resumida:

 

Si os interesa la agilidad, y quéreis conocer los diferentes métodos y técnicas ágiles que existen a día de hoy, a la vez que obtener 2 importantes y reconocidas certificaciones profesionales como son PMI ACP (Agile Certified Practitioner) y PSM I (Professional Scrum Master) no dejéis de consultar el Curso Online Agile.

El curso online Agile facilita también 21 Technical PDUs para aquellos que ya tengáis alguna certificación profesional del PMI.

Alejandro Pérez, PMP, PMI ACP

PMP/CAPM, Project Management

El coste de Oportunidad (Opportunity Cost)

Hoy he asistido a una ponencia y evento de networking dentro del ciclo de conferencias del grupo Lean Startup, el título de la ponencia era: “How (Not) to Succeed in Silicon Valley, USA”, el ponente Antonio García uno de los creadores de Facebook Exchange (FBX), ha comentado sus experiencias vividas en San Francisco y los errores que cometió durante esos años en los que creo una empresa y la vendió a Twitter para después pasar a trabajar para Facebook.

Una de las slides de la presentación trataba sobre el coste de oportunidad, me ha llamado la atención el concepto, ya que aparece definido en el PMBOK Quinta Edición y es sujeto de preguntas capciosas en el examen de Certificación PMP (Project Management Professional), siendo una de las clásicas que la mayoría suele fallar si no ha entendido correctamente su definición y aplicación.

El objetivo de este artículo que os presento hoy es repasar el concepto de “coste de oportunidad” y ver alguno de los posibles escenarios donde se puede aplicar, para finalmente mostraros un ejemplo de pregunta de examen y como seleccionar la respuesta correcta.

El coste de oportunidad como veremos a continuación, está muy relacionado con la toma de decisiones, es la forma que tenemos para denominar aquello a lo que renunciamos cuando decidimos tomar una decisión.

coste de oportunidad

 

Coste de Oportunidad Económico:

Para entender un poco mejor el coste de oportunidad a nivel económico podemos usar un ejemplo simple:

Un trabajador autónomo tiene un precio hora de 20 EUR, por lo tanto si tiene una jornada laboral de 40h semanales (suponiendo que las pueda facturar todas), su sueldo bruto serían: 3200 EUR al mes, en este escenario si el autónomo decide parar durante una hora y ponerse a navegar por internet, el coste de oportunidad de esta decisión son 20 EUR, es decir el valor de la hora de trabajo que ha decidido no ejecutar en favor de la hora de navegación.

Coste de Oportunidad Personal:

El coste de oportunidad no siempre se puede medir de forma monetaria, por ejemplo:

Tenemos 16 años y nos encontramos ante dos posibles escenarios: seguir estudiando o seguir trabajando. Si elegimos seguir estudiando, nuestro coste de oportunidad sería el dinero que podríamos ganar trabajando, y si decidimos trabajar, nuestro coste de oportunidad sería el mayor sueldo que podríamos tener en el futuro gracias a los estudios.

Coste de Oportunidad en la Selección de Proyectos:

Seleccionamos algunos proyectos y rechazamos otros. El coste de oportunidad en la selección de proyectos es el valor total del proyecto que no hemos llevado a cabo, por ejemplo si hemos de decidir entre un proyecto A o proyecto B, el coste de oportunidad de elegir el proyecto B, es el valor del proyecto A.

Ejemplo Pregunta examen PMP:

El proyecto Nexus tiene un IRR de 19% y un NPV de $26,000 con una duración de 3 años. El proyecto Lemon tiene un IRR de 24% y un NPV de $28,000 con una duración de 5 años. Cual es el coste de oportunidad de elegir el proyecto Nexus en vez del proyecto Lemon.

A.)$ -2,000

B.) $2,000

C.) $26,000

D.) $28,000

Solución:

Todo y que la pregunta juega a desorientarnos introduciendo el concepto de IRR y duración que para este escenario son irrelevantes ya que nos está preguntando únicamente por el coste de oportunidad, que en este caso será el valor total del proyecto no escogido, esto es: 28.000$

Espero que el artículo os resulte de interés, si estáis interesados en obtener la certificación PMP o mejorar vuestros conocimientos en el área de gestión de proyectos, no dejéis de visitar nuestra web, donde encontraréis información sobre nuestros cursos presenciales y online de preparación para la certificación PMP.

Alejandro Pérez

PMP/CAPM, Project Management

¿PMP, Prince2, Scrum/Agile, ITIL, Lean Six Sigma?

Cada vez son más los alumnos que me pregunta cuáles son las diferencias principales entre las diferentes certificaciones de gestión de proyectos, estándares y metodologías y en cuál deberían enfocarse y centrar su esfuerzo. Como supondréis no existe una respuesta universal ya que dependerá de la experiencia del interesado, su trayectoria profesional y sus objetivos a medio y largo plazo, y es que efectivamente hay tantas opciones como lapices de colores.

lapices

Comenzaré este artículo describiendo brevemente las diferencias entre unas y otras, dado que aunque muchas veces las metemos en la misma “bolsa” hay importantes diferencias entre unas y otras:

PMP: La certificación PMP (Project Management Professional) está basada en la guía PMBOK publicada por el PMI (Project Management Institute), el PMBOK es un estándar de gestión de proyectos no una metodología, por lo tanto se basa en “best practices” y recomendaciones recogidas durante años por expertos en la gestión de proyectos y reunidas a modo de guía en el Project Management Body of Knowledge (PMBOK).

Prince2: Prince2 es una metodología establecida originalmente por el gobierno británico y usada actualmente en todo el mundo, por lo tanto determina y guía que procesos deben ejecutarse y en que orden, aportando plantillas e instrucciones más detalladas. La certificación Prince2 está basada en esta metodología.

Scrum/Agile: Scrum es un framework o modelo de desarrollo ágil caracterizado por adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto. Utilizado en mayor medida en proyectos de desarrollo de software. A día de hoy sobre este framework destacan dos certificaciones: Certified Scrum Master (CSM) de la ScrumAlliance.org y Professional Scrum Master (PSM) de Scrum.org, la diferencia de opinión y visión de los fundadores de Scrum terminó en la separación de los mismos y la creación de estas dos certificaciones. También existe una certificación del PMI que cubre una visión más global de las metodologías Agile (sin cerrarse a un framework en concreto), la PMI-ACP (Agile Certified Practitioner) que es recomendable para aquellos que buscan obtener una visión más global (incluyendo Scrum, Lean, Kanban, XP, etc).

ITIL: Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido en el estándar mundial de facto en la Gestión de Servicios Informáticos, por lo tanto no es un estándar o metodología de gestión de proyectos sino de gestión de servicios.

Lean Six Sigma: Lean Six Sigma es una metodología de mejora de procesos que combina dos ideas: Lean, una recolección de técnicas para reducir el tiempo necesario para la producción de productos o servicios, y Six Sigma, una recolección de técnicas para mejorar la calidad de los mismos. Las certificaciones comprenden diferentes niveles, denominados “belts” que indican el nivel de experiencia y conocimientos de los practicantes.

¿Que certificación me conviene?

Como he comentado al inicio del artículo dependerá de tu trayectoria profesional, tu experiencia y tus necesidades actuales y  a medio/largo plazo la elección de una u otra certificación. Personalmente recomendaría el PMP como primera certificación para tener una visión global y luego elegir cualquiera de las otras certificaciones comentadas dependiendo de tu perfil, necesidad y motivación.

Espero que el artículo os resulte de interés, si tenéis intención de formaros en gestión de proyectos y obtener vuestro certificado PMP (Project Management Professional) o PMI ACP (Agile Certified Practitioner), no dudéis en contactarme para recibir más información o resolver cualquier duda que podáis tener.

Alejandro Pérez