PMI Madrid Spain

Artículos

I was talking recently about someone in my professional life who I am really proud of.  Besides the fact that she is a friend and her success is great news, her success is even more special because I think I played a partial role in it.

As a leader or manager, this feels great.  As a friend, it feels great.  As a human being who loves to help others along the way, it feels great.

Is there someone in your life who you can say the same thing about?

When we study leadership, we focus on the people we lead. But so often, that focus goes to the successful completion of the work or projects or strategies that we are working on.  But what about the individuals themselves and their successes.  Great leaders take pride in their people – not just the current state but the future state as well.  Where they end up.  Where they go next.  The awards, recognition and promotions that came along the way

As a leader or manager, take pride in developing talent.  Be proud of them as they walk out the door to something bigger and better.  You can replace them – get over it.  Hopefully, if you did a great job in training, coaching and mentoring, they will recognize the role you played.  But if not – so what.  You can still be proud of your results.

I am a serial entrepreneur and a dreamer.  I come up with new ideas all the time, which comes with good news and bad news.  

The good news is that some of these ideas, well under 50% admittedly, are good ones: ideas that could serve my community well, or employ many people or even, shockingly, be profitable. 

The bad news is that sometimes (OK… often) my ideas don’t stand up well to the Strategy Stress Test (SST).  In fact, last year, I was cut-off from any new ideas unless it was given the OK by my coach and by my wife/business partner.  From that day on, I had to include these two individuals in my own SST.

We all need an SST – organizationally, professionally and personally.  We need a test that will put our strategic plans through the scrutiny that will ideally help avoid disasters or disappointment in the future.  

I would love to be able to present a perfect SST that will fit all organizations and all individuals, but I cannot. Every strategic plan is unique and thus every SST is unique.

ABSTRACT

 El análisis de riesgos en los proyectos, dentro de la globalidad existente, es una herramienta necesaria y fundamental ante el actual mercado competitivo. Sin duda, esta clase de sucesos siempre ha existido y de una manera u otra se han tenido que afrontar.

Dada la complejidad de los proyectos, se ha de realizar una adecuada gestión que garantice un uso eficiente de los recursos. No solo es necesario plasmar una planificación estratégica de los portafolios o programas de las compañías, además se debe analizar cada proyecto de manera específica con independencia de su tipología y singularidad para desarrollar la identificación de los sucesos.

Implantar de manera defectuosa la gestión de riesgos, o no hacerla con las herramientas adecuadas, es una de las principales causas de fracaso de los proyectos.

Por todo esto, hay que llevar adelante una planificación estratégica de la organización como un conjunto de buenas intenciones; además, se deben desarrollar mecanismos que los plasmen en la práctica.

De estas necesidades se estableció una serie de metodologías, normas, buenas prácticas o estándares y sistemas de gestión de riesgos: PMI®, IPMA®, COSO®, ISO®, etc.

dsdm

 

En un proyecto ágil se fija el tiempo que dispone la organización para conseguir los objetivos. No se calcula plazo estimando el tamaño de los requisitos, el trabajo que supondrían y lo que tardarían los recursos disponibles. No puede hacerse así porque no se conocen los requisitos en detalle suficiente. En lugar de calcular un plazo del proyecto, se toma este plazo como una restricción del negocio. Se hace una planificación inicial en la que se acaban sabiendo los requisitos de alto nivel, el plan de entregas, las restricciones de plazo, etc. Así planificamos inicialmente el cronograma y también el coste, pues un equipo continuo durante un plazo concreto tendrá un coste determinado.

Un proyecto de 12-24 meses, por ejemplo, suele dividirse en 4-6 fases de 3-4 meses cada una. Cada una de estas fases puede gestionar a su vez como un proyecto o fase, teniendo en cuenta los 49 procesos del PMBOK, si es preciso. En proyectos software, estas fases suelen denominarse "releases" porque tienen el objetivo de entregar a los usuarios finales una funcionalidad terminada. Al proceso de planificar una release se le denomina "release planning" y consiste en determinar en equipo las historias más importantes de la release y asegurarse de que se pueden entregar. Teniendo en cuenta la velocidad del equipo, que suele medirse en historias por iteración, puede calcularse el número de iteraciones, que deben tener una duración fija durante toda la release (concepto de time-box: las iteraciones ágiles siempre terminan en fecha, normalmente duran entre 1-4 semanas, pero si se decide 2 semanas, por ejemplo, esto no se debe cambiar hasta la siguiente release).

El alcance se va planificando en detalle a medida que la release avanza. El resultado del "release planning" suele denomiarse "release backlog", que es propiamente un subconjunto del "product backlog". Al principio de la release, en el release backlog tenemos historias muy grandes (deberían denominarse épicas, mejor que historias) y deben irse descomponiendo y refinando gradualmente. El Product Owner es el encargado de mantener refinada la planificación de las historias del release backlog, especialmente aquellas planificadas para la siguiente iteración. Las historias pueden cambiarse, los cambios son bienvenidos porque ocurren en el product backlog. No debe cambiarse, sin embargo, el trabajo que ha entrado en la iteración, en el que ya está trabajando el equipo de desarrollo.

En la ceremonia llamada iteration planning, el equipo de desarrollo planifica la iteración descomponiendo las historias en tareas que deben ir procesando para ser completadas antes de que finalice la iteración. Típicamente se usan tableros kanban con columnas to-do, doing, done, para visualizar cómo va el trabajo del equipo durante la iteración.

Cada día, en el daily standup, los miembros del equipo informan unos a otros de lo que han hecho desde el último daily, lo que se proponen hacer durante el día, y los impedimentos que les dificultan trabajar al ritmo que esperaban.

Es decir, en un proyecto agile, si se ejecuta siguiendo el marco Scrum, se planifica el día, la iteración (2 semanas), la release (3-4 meses), el proyecto (12-24 meses)...

La planificación suele quedar como reflejo fiel a los trabajos ejecutados, no hay scope creep, no hay padding, etc.

¿Podríamos decir que en un proyecto ágil, si se gestiona bien, se dedica más esfuerzo a planificar que en un proyecto predictivo?

  JoseBarato

Por Jose Barato, PMP, PMI-ACP, vocal de PMI-Madrid

 

¿Sabes qué impulsa a iniciar un proyecto

Una organización, cuando decide poner en marcha un nuevo proyecto, no lo hace de manera arbitraria o por un impulso incontrolado. O al menos no debería ser así. Siempre va a obedecer a alguna razón.

¿Y qué impulsa a dedicar energía, recursos y talento a iniciar un nuevo proyecto? En el ánimo de tal decisión habrá seguramente una combinación de factores.¿Podríamos llegar a categorizar unas razones concretas como factores impulsores de proyectos?

A continuación veremos como cuales son las 5 razones que según la Guía de los Fundamentos para la Gestión de Proyectos PMBOK6 se establece para dar inicio a un nuevo proyecto. Cual es el contexto de iniciación de nuevos proyectos.Toma nota para tu examen de Certificación PMP

¡Empecemos!