Mixing Agile and Waterfall aproaches for projects

Many organizations have decided that there is no need to choose between Agile and Waterfall aproaches to manage projects. There is a sinthesys solution than can be tested in some environments.

The project management world has followed a triad evolution, as in Hegel’s dialectical method. Waterfall was the thesis, Agile the antithesis … and now there are approaches that try to be a kind of synthesis of both models. A logical evolution.

 

Mixed approaches

How can agile and waterfall be combined?

There are differents approaches to achieve the convergence of both mindsets:

 

Benefits of a mixed system

What are the benefits of these kind of approaches?

Probably there will be people used to work in ‘pure agile’ or ‘pure waterfall’ environments who will say that these approaches are just a perversion of the core values of their project management systems.

Nevertheless I think there might be situations where these options may be valuable:

  • Organizations who are transitioning from waterfall to agile and vice versa and need to remain in an intermediate step for some time instead of moving directly from one environment to the other one.
  • Organizations where the top management is used to deal with waterfall project managers and whose development teams have found that they achieve a better performance being agile.
  • Complex and big projects where there is part of software development and part of hardware or infrastructure deployment.

 

What is your opinion? Have you tried any hybrid approach to project management? What were the results?

Do you know any other hybrid approach to project management? I would like to know more about it, please add comment with your explanation.

 

 

Mixing Agile and Waterfall aproaches for projects

¿Qué es la “Extensión de Software de la Quinta Edición de la Guía del PMBoK”?

Recientemente el PMI ha publicado una extensión de software de la quinta edición de la Guía del PMBOK® (en inglés).

La Guía del PMBOK®, es un conjunto de buenas prácticas internacionalmente reconocido para la dirección y gestión de proyectos. La quinta edición se ha convertido en un estándar reconocido por ANSI (y publicado como anexo en la propia guía).

Elaboración conjunta PMI-IEEE

La “Extensión de Software de La Guía del PMBOK®” ha sido elaborada conjuntamente por el PMI y por la IEEE Computer Society. Se basa en 5ª edición de La Guía del PMBOK®, manteniendo su estructura, procesos y coherencia en el discurso pero incorpora elementos propios de los proyectos de desarrollo de software para adaptarse a sus características específicas como los métodos de desarrollo adaptativo, que permiten aprovecharse de la naturaleza específica del producto de estos proyectos: las aplicaciones. En general, se trata de productos que permiten la fácil y rápida elaboración de prototipos y el desarrollo incremental.

Público objetivo: todo el involucrado en proyectos de TI

Esta “Extensión” está escrita pensando en organizaciones y equipos que se enfrentan tanto a proyectos de desarrollo como de modificación o de implantación de software y cubre tanto proyectos llevados a cabo internamente como la gestión de proyectos externalizados.

Dado que hay aspectos que no varían en un proyecto de software respecto de uno cuyo producto sea distinto, en todos los apartados en los que no hay especificidades en un proyecto de software se deriva al lector al punto concreto de “La Guía del PMBOK®”.

Por el contrario, cuando hay técnicas o situaciones concretas y específicas de los proyectos de software éstas se mencionan o referencian en la propia “Extensión”. Como ejemplo, uno de mis intereses personales es la Calidad en los Proyectos. En el capítulo 8 del libro se trata este tema y se hace referencia a técnicas de SQA (Software Quality Assurance) y SQC (Software Quality Control) junto con estándares del IEEE aplicables a cada caso, como el IEEE Standard 829 (Software and System Test Documentation) o el IEEE 1008 (Unit Testing).

Habrá que ampliar la librería

Habrá que ampliar la librería … (Fotografía de neoprolog bajo licencia CC BY 2.0)

¿Consideráis útil esta aproximación del PMI frente a los entornos ágiles alternativos?

¿Habéis tenido oportunidad de leer el libro? ¿Qué opináis? ¿Consideráis útil y acertada su publicación o bien pensáis que no tiene sentido adaptar “La Guía del PMBOK®” a proyectos de software disponiendo de entornos ágiles como Scrum o Kanban?

¿Qué es la “Extensión de Software de la Quinta Edición de la Guía del PMBoK”?

¿Cómo mejorar identificación de interesados en tu proyecto?

¿Qué hacer si durante la fase de ejecución y seguimiento/control  nos encontramos con que no hemos identificado a un interesado (stakeholder) en nuestro proyecto que, además, resulta que tiene mucho interés y/o influencia en el mismo?

La gestión de interesados es un proceso vivo durante todo el proyecto

La gestión de los interesados es, en cierto modo, como la gestión de los riesgos en nuestro proyecto; no debemos darla nunca por cerrada y hay que revisarla sistemáticamente. Periódicamente es necesario revisar el registro de interesados, el análisis de cada interesado y la estrategia utilizada con él, para introducir los cambios que sean necesarios.

pmbok cafe s2w2 stakeholder 015

Stakeholder dashboard (Robert HiggingsCC BY 2.0-)

Inclusión de nuevos interesados durante el proyecto

El inicio del proyecto es la fase en que menos información disponemos. Si, como planteaba la pregunta inicial, nos hemos olvidado o no conocíamos a alguien importante deberemos:

1. Añadirlo al registro de interesados.

2. Evaluar su poder dentro de la organización y su posible interés en relación al proyecto.

3. Analizar cómo puede haber afectado al proyecto su no inclusión hasta la fecha en el grupo de interesados.

4. Definir una estrategia para gestionar nuestra relación con él, partiendo del reconocimiento de que no hemos empezado con buen pie.

5. Efectuar las correcciones necesarias en nuestro Plan de Proyecto, de acuerdo con el sistema de gestión de cambios que hayamos definido, para tener en cuenta a este nuevo interesado. Ésto es especialmente importante si su nivel de influencia en el proyecto es alto.

Técnicas de identificación de interesados

Para evitar que un interesado, especialmente uno importante, se quede fuera de nuestra estrategia de comunicación del proyecto hay algunas herramientas que podemos usar:

– Nominación de interesados: a partir de una lista inicial podemos pedir a cada uno de los interesados ya identificados que nos proponga nuevos interesados en el proyecto. Es recomendable empezar por el sponsor del proyecto y continuar luego con los interesados más influyentes.

– Investigación de base: se trata de estudiar toda la documentación existente en relación a nuestro proyecto y localizar en la organización documentación análoga de proyectos similares. A partir de aquí se toma nota de todos los interesados que aparezcan en dicha documentación, para evaluar si también pueden estar involucrados en nuestro proyecto.

Esta técnica es especialmente interesante si somos directores de proyecto trabajando en una organización nueva para nosotros o que desconocemos.

– Rueda de interesados: La rueda interesados es una especie de lista de control en la que se han identificado todos los principales grupos de interesados​​. Se usa para comprobar la lista de grupos de interés frente a grupos de interés genéricos, con objeto de identificar los que falten.

Es bueno actualizar la documentación del proyecto (lecciones aprendidas) con nuevos grupos o roles que se hayan identificado, para que pueda ser aprovechada en futuros proyectos.

Resumen final

La no inclusión de un interesado importante dentro del Plan de Proyecto puede ser catastrófica. Para evitarlo, utiliza las tres técnicas mencionadas de identificación de interesados y revisa sistemáticamente tu registro de interesados del proyecto y tu estrategia frente a cada uno de ellos.

¿Qué otras técnicas conoces para identificar interesados? Compártelas mediante un comentario a esta entrada para que todos nos beneficiemos de su uso.

¿Cómo mejorar identificación de interesados en tu proyecto?

Using a Blog to support your Project Management Information System

Last summer I started reading “Social Media for Project Managers”, from Elizabeth Harrin. There were many concepts I already knew and some tools I was already using but the book gave me some ideas to use those tools for new purposes. One of them was using a Blog as a part of the PMIS (Project Management Information System) as a project log.

Blog image from http://www.sxc.hu/profile/svilen001
Blog image from http://www.sxc.hu/profile/svilen001

How we use a blog in our project

We started using a blog in a software development project I am managing. The team is young and they are used to these kind of tools so it was not difficult to convince them to start blogging everyday their project activities.

As we all are not working at the same office and also some team members have different working hours, we thought that this tool would help us with its universal accessibility (well, in fact we have limited the access to the blog to the project stakeholders).

These have been the results

After some months of work we have:

  • A project log, explaining what we have done and why we have done it that way. A knowledge repository.
  • A tool useful to train new team members is they are needed in the future.
  • A tool to collaborate. We can receive feedback from the community of project stakeholders through their comments at the blog posts.
  • A tool to build relationships between the team members, as not all of them are collocated.

Some difficulties and risks

But not everything has been easy. We have had establish some ground rules about what to post and how. As every stakeholder may read a post it is not easy to decide the kind of information to include as not all of them have the same needs.

There are some posts that are for internal use (just for the team members), some others are for everybody involved in the project and we are working now in the weekly project status reports, for the project sponsor and the final product users.

As everybody can read every post, the tool we use to filter are tags. If you want to read a project status report you must look for “status” tags in the blog. When a team member looks for some information about the data base he must use some of the tags we have previously agreed to use for these issues, and so on.

What’s your opinion?

What about you, are you using any social media tool to support your projects? What has been the most difficult challenge you have faced to deploy it? What have been the benefits for the project? Any negative result?

Using a Blog to support your Project Management Information System

Leading with our example

Some days ago I read an interesting post from Voices on Project Management. It made me think about the way our behavior can influence our team in a project, especially its young members, that can be prompted to imitate our conduct.

The way we deal with the project stakeholders or even the way we manage our relationship with managers and people from other functional areas, even if they are  unrelated with the project, are telling our team mates how we expect them to deal with these people too.

Desert leader
Image by Hamed Saber (CC BY 2.0)

For instance, if we do not control ourselves and criticize without compassion the manager from a functional area because we are having problems to obtain the resources she had committed to provide to our project we are also telling (consciously or not) our team that this behavior against some project stakeholders is accepted (or acceptable).

On a positive situation, a smart negotiation (win-win) with a project vendor can show our team that we expect them to keep a good relationship with the sellers involved in the project, we want our vendors to grow with us and we want the relationship with them to last further than the project.

Many different situations come to my mind when I think about the way that our actions or communications show our team mates what we consider an appropriate behavior:

  • the way we answer emails,
  • the way we manage meetings, especially difficult meetings,
  • the way we manage arguments between members of the team,
  • the way we react when a job mate comes to see us with a problem,
  • the way we follow the ground rules established for the project,
  • the way we act when somebody comes late to a meeting,
  • the way we accomplish our commitments,
  • the way we react when others make mistakes,
  • the actions we take when the team misses a milestone,
  • our conduct when we, or someone else from the team, receive a present from a vendor,

There are many situations during the life of a project that allow us to point out, implicitly or explicitly, the way to be followed by the team.

What other situations do you think that can help us indirectly coach a project team?

Leading with our example

Ya soy PMP. Valoración, agradecimientos y consejos

Después de 3 meses vuelvo a tener tiempo para escribir en este blog. Creo que esta entrada va a ser la más personal que he escrito hasta ahora.

Llevaba un año y medio preparándome para obtener la certificación PMP pero estos últimos meses han sido los más intensos, estudiando y preparándome en “modo test” para el examen. Finalmente me presenté el pasado jueves 19 de abril (de 2012) y aprobé.

Pero, ¿qué significa tener la certificación PMP? ¿se es mejor project manager por disponer de esta certificación? No es fácil de responder.

Lo que me ha aportado hasta ahora el PMP no es tanto el propio certificado como todo lo que he aprendido a lo largo del proceso de preparación.  Técnicas, buenas prácticas, metodologías, conocimiento de buenos profesionales y formadores en gestión de proyectos y también el hecho de demostrarme a mi mismo que sigo en condiciones de marcarme un objetivo ambicioso y esforzarme al máximo hasta conseguirlo.

Prepararse para el PMP requiere tiempo y esfuerzo y no es fácil hacerlo en el actual contexto de crisis en el que en el trabajo debes hacer cada día más con menos y al llegar a casa te esperan tus obligaciones familiares. Los ratos que se pueden dedicar a la preparación no siempre son los más productivos del día.

En todo este proceso he tenido algunas ayudas que ahora me gustaría compartir (siguiendo la filosofía de este blog) porque creo que pueden ser útiles para quien se quiera presentar al examen:

  • Libros: recomiendo 2 lecturas,
  • Herramientas complementarias: en la parte final de la preparación para el examen me ha ido bien utilizar
    • PM Flashcards, ayudan mucho al hacer un repaso final por áreas de conocimiento.
    • PM Formulas, permite entender bien todas las fórmulas susceptibles de aparecer en el examen y asegurarte de que no se te escapa ninguna. Además viene con 105 preguntas de examen sobre fórmulas. Muy práctico.
  • El blog de Josh Mankivel (en inglés) es muy interesante y proporciona consejos útiles basados en su experiencia con muchos aspirantes a PMP.

Quiero agradecer a Angel Águeda Barrero toda la información que habitualmente publica en su blog y especialmente la recopilación de exámenes gratuitos. Me ha resultado muy útil. 

Para acabar, mi agradecimiento también a otro PMP y compañero en el MGTI, Victor Carazo. Sus consejos y la información que ha compartido conmigo no tienen precio.

Acabo repitiendo el mensaje fundamental de esta entrada; si te estás preparando para el PMP no te limites sólo al resultado final, procura disfrutar y aprender al máximo durante todo el proceso.

Ya soy PMP. Valoración, agradecimientos y consejos

La utilidad del Earned Value (EV)

Esta semana, durante mi proceso de preparación para el PMP me he encontrado con un concepto nuevo e interesante para mi dentro del proceso de gestión de los costes del proyecto: Earned Value (EV), algo así como el valor de venta de lo que hemos hecho hasta ahora en el proyecto.

EV by Garry L. Booker con copyright cedido al dominio público

Utilidad del EV

Como he mencionado, se trata de un concepto nuevo para mi. Por lo que he podido deducir, su principal utilidad está en ayudar al Project Manager (PM) a saber si su gestión de costes es correcta en relación a lo planificado y a simplificar la estimación de los cálculos para conocer lo que acabará costando el proyecto (Estimated At Completion, EAC). Ésto permite  compararlo con el presupuesto asignado para tomar decisiones y, si es preciso, solicitar los cambios oportunos mediante el proceso de control de cambios establecido en el proyecto.

Dificultades prácticas

No obstante, en la práctica, le veo algunos problemas al método:

1. Las fórmulas para el cálculo correcto de EV y términos derivados (EAC) pueden llegar a ser muy complejas. Especialmente el EAC, cuya fórmula de cálculo no es única sino que depende de diversos factores.

2. En muchos proyectos, o bien el producto en sí no va a ser vendible, o bien sólo lo será al final del proyecto. Por el camino podemos obtener entregables no vendibles que sólo nos permiten hacer una estimación poco realista del EV.

Conclusiones

En cualquier caso, estoy de acuerdo en que al utilización del EV reduce mucho el tiempo de cálculo del EAC (la estimación de los costes del proyecto en base a lo que llevamos gastado y lo que nos falta por gastar para compararlo con el presupuesto inicial).

Ésto es especialmente claro si lo comparamos con el esfuerzo que puede representar en grandes proyectos recalcular todos los costes de las actividades o paquetes de trabajo pendientes y agregarlos para obtener el nuevo EAC.  Las estimaciones, para ser correctas, deberían ser realizadas preferiblemente por quien debe ejecutar las actividades y el proceso puede consumir bastante tiempo del proyecto (que acaba siendo más coste) y causar retrasos si lo vamos haciendo con cierta frecuencia.

Sin embargo, el cálculo del EV puede llevar a simplificaciones en algunos proyectos y, siempre que hacemos ésto debemos saber interpretar y valorar el resultado en su justa medida.

¿Cuál es tu opinión? ¿Utilizas el concepto de EV habitualmente en los proyectos que gestionas? ¿Cómo lo calculas? ¿Te es útil?

Agradeceré que incorporéis vuestras opiniones como comentarios a esta entrada. Compartiendo experiencias y opiniones todos salimos ganando.

La utilidad del Earned Value (EV)