Do’s and don’ts when taking over a troubled project

When you become a senior project manager there are more chances that your boss or other managers may trust you when they face a troubled project and need you to bring it back to the path of success.

If they trust you for such kind of mission critical tasks you must be proud. But, after the first moments of increased self-esteem, what do you have to do in order to not deceive the confidence they are placing in you? And what should you avoid?

The following list reflects some points I consider as we must do or avoid in these situations:

The Do’s

  • Set stakeholder expectations
  • Read, look and listen (contract, project requirements,…)
  • Talk to every team member individually and grasp its vision of how the project arrived to that situation
  • Formulate what must be changed
  • Work with the team with new baselines and deliverables definition
  • Reschedule
  • Follow-up the project continuously (advance versus estimations, costs, …) and act immediately in case of deviations
  • Be transparent with the team about the consequences of continuing with the previous  ways of working and get their commitment to apply the changes
  • Change any team member uncommited or who is in a negative mood about the project (that might be spread to the rest of the team)
  • Look for improvements in the project and praise the team for them
  • Catch immediately any undesired behaviour and correct it

The Don’ts

  • Do not make commitments until you have obtained the full picture of the situation
  • Do not badmouth the previous project manager. It is not professional and your client (internal or external) does not need to have transparency of your internal problems
  • Do not criticize publicly any team member (praise in public, criticism privately)
  • Do not exchange quality for speed


This is my list but I am sure it can be improved with your comments. I’d love to read your comments and update it with your personal experience.


Do’s and don’ts when taking over a troubled project

4 bases to implement Kaizen in project management

Sometimes it is hard to stablish a system of continuous improvement in a project management office (PMO). A kind of discipline is needed to find out new ways of doing things better in a systematic way.

There are 4 bases that may help us in this challenging process: the use of foundational principles, a systematic approach, to become a learning organization and to be aware and overcome the obstacles.

Foundational principles

  • Let’s think about how can we make something happen instead of why it cannot be done
  • Develop a continuous change mindset
  • Use the 5-whys or other similar tools to find the root causes of the problems
  • Measure what you do to be able to notice if you improve

We must take the time to understand why things went wrong, measure successes and failures, and document them along the way. The wisdom must be accessible to others as well.

The Kaizen approach is to start the change, or the improvement, and build on it over time, rather than to expect perfection from the start. Project managers must focus on doing the job a little better each day.


Systematic approach to continuous improvement

It is not just about a mindset. To obtain results we must make changes, create new habits and do it in a systematic way. These six steps may be of help:

  1. Select opportunities. In your projects, set improvement milestones.  Chose the areas where less effort might have the greatest impact. Involve all the team in this point, in the second one and in the fourth one too.
  2. Find and analyze the root causes of the problems.
  3. Determine the required level of performance.
  4. Define solutions and plan tasks. Every task must have a person responsible of it and a deadline.
  5. Deploy the action plan and evaluate the results against the desired performance.
  6. Improve or change the solutions if the results do not provide the expected level.
  7. Find new opportunities.


Learning organizations

Learning organizations are organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together. (Peter Senge)

Continuous improvement is strongly connected to learning organizations. To become a truly learning organization you need to continuously improve.


Obstacles to grow as a PMO

What kind of obstacles may limit our ability to grow as a learning PMO?

  • Isolation. Every project manager works in her/his projects disconnected from the rest of project managers. The improvement efforts are not coordinated.
  • Lack of reflection. The rush to move to the next project or to the next project phase or task.
  • Attitude. In this point we might include the lack of interest in improving the organization and also the systematic denial of problems existence.
  • Lack of support from the leaders. The leaders of the organization and the PMO Manager must not just support but encourage their teams to continuously learn and improve.

In order to support the improvement in project management it should be a duty of the PMO to provide a systematic framework to help the project teams to learn and improve.

What is your opinion? Do you have this kind of continuous improvement framework in your organizations?



4 bases to implement Kaizen in project management

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

7 tips to work with virtual teams

Let’s say it. Executing projects with virtual teams has many advantages but, in spite of the many tools that are currently available to improve the communication between team members when they are not co-located, working with virtual teams has an added level of difficulty. Is it possible to take advantage of the benefits without die trying?

I have been managing some virtual teams in the last year and also following the way other project managers in our PMO were doing it. With these experiences and some documentation from experts that I have read recently I have gathered 7 recommendations to have chances of success when you have to manage a virtual team.

7 tips

  1. Be available and keep frequent formal and informal conversations with the team.
  2. Provide the appropiate channels and encourage your team to share their feelings and chat informally whenever they can. It should be a kind of water cooler, using separate chat channels, for instance.
  3. This has not been my case but if there are cultural differences between your team members it is crucial to promote cultural training for all members. For instance, Mediterranean workers are used to take more time for lunch than their northern team mates. It is important that the team understands and respects it whenever it is possible.
  4. Use video calls preferably over chat and email. And, if possible, it is good to have a regular structured video call with the whole team.
  5. Schedule a periodical in-person meeting from time to time. It is better if you can do it early on the beginning of the project.
  6. Provide a rhythm to the team. Stablish regular meetings (same days and time each week) and use best practices of meeting governance.
  7. Introduce the practice of sending a status email at the end of the day to recap the status of on-going tasks and to inform the team members on updates from the customer or other stakeholders.

The key is to treat your far team members the same as your team members who work in your immediate vincinity. Respect them, listem to them, feel their needs and stay in personal and emotional communication constantly.


7 tips to work with virtual teams

A different kind of PMO. Lean-Kanban PMO.

When you talk about a PMO to a group of developers or designers or even project managers there are many prejudices about this kind of entity and in many cases a negative perception of its work.

This biased opinions have their foundations in the way PMOs tend to be used by organizations. As David Joyce explains in this presentation at the LKCE12, they focus on:

  • Governance: control. Monitoring and reporting.
  • Compliance: execution. Processes compliance prevail on delivering value to the client.

Another mindset of traditional PMOs is to maximize utilization of the resources: “The more we start, the more we finish”.  This mindset has 2 problems:

  • Increases the WIP (Work In Progress) and causes unnecessary stress to the team.
  • Increases the time to finish, as the TOC (Theory of Constraints) explains in this presentation from Teoce (in Spanish language). Starting many projects leads us to multitasking. And multitasking isn’t usually well managed. We should move from one task in a project, to another one in another project only if the first one is finished. We should jump between tasks only when it is possible to generate flow. Our project portfolio should be managed as a pull process in order to avoid overloading it.

Another kind of PMO is possible

Instead, the PMO mindset should be “The more we finish, the more we finish” as Markus Hammarberg explains in this post. “Stop starting, start finishing”.

Kanban can be a very interesting tool to improve a PMO, as it allows visual management of projects and the portfolio. This allows to keep informed the senior management limiting the overhead caused by traditional reports and meetings.

But there are other benefits that support this different approach for the PMO:

  • Risk management can be performed making work constantly visible and keeping the team together to be able to take quick decisions.
  • Break down big projects into small pieces that can be frequently delivered and allowing the teams to adapt to the changing needs of the business.
  • Producing and mantaining a dashboard of leading strategic metrics (value delivered, overall speed, quality and cost of delivery, lead times,…)

Portfolio and pipeline management deserve a special chapter and lean can be very useful for this purpose. Lean aims to focus in allocating the resources on highest priority projects to make them finish earlier and avoid starting new projects until resources are available.

What is your experience?

I think lean principles, TOC and kanban can be good project management tools in a PMO. They are a powerful way to:

  • increase value delivered
  • reduce lead times
  • improve management reporting through visual boards

and also Kanban can be introduced incrementally, step by step, without the need to implement drastic changes in the organization. What do you think?

A different kind of PMO. Lean-Kanban PMO.

5 ejemplos de contratos ágiles

Como comentaba en mi último post del año pasado, uno de los motivos del posible fracaso de la utilización de Scrum en las organizaciones es el no trabajar con ‘contratos ágiles’.

Este tipo de contratos busca principalmente dotar de flexibilidad a las relaciones contractuales entre proveedor y cliente, de forma que este aspecto de la relación se alinee con la dinámica de la agilidad en la gestión de los proyectos.

Modalidades de contratos ágiles

Hay muchas modalidades de contratos que incorporan esa flexibilidad en la relación cliente-proveedor. El objetivo principal es repartir el riesgo de forma razonable entre ambas partes. La forma de hacerlo, en pocas palabras, es fijar coste y plazos de entrega y permitir flexibilidad/variabilidad en el alcance. El cliente va sabiendo conforme avanza el proyecto qué es lo que va a querer como resultado de su proyecto y el contrato debe permitir moldear el alcance conforme el proyecto avanza beneficiando a ambas partes y priorizando la entrega de valor para el cliente por encima del cumplimiento de un plan. Voy a enumerar y explicar brévemente algunos tipos de contrato ágiles  que conozco:

  • Money for nothing, change for free; el cliente puede cancelar el proyecto en cualquier momento pagando al proveedor un porcentaje del alcance cancelado. Cualquier funcionalidad puede cambiarse por otra de igual peso.
  • Time and materials iterativo e incremental; entregas funcionales al final de cada sprint. Posibilidad de terminar el contrato en cualquier momento (con o sin coste).
  • Precio por función; incentiva la entrega de software funcional cuanto antes. Los cambios son bienvenidos si se pagan.
  • Puntos y velocidad; calcula puntos y velocidad. Calcula el coste del proyecto en base a horas. Reduce el precio de horas y pon el resto en precio de puntos.
  • Compromiso agile; target time para MoSCoW. Mínimo y máximo agresivos. Por encima del máximo el proveedor pierde, por debajo del mínimo el proveedor gana. En el medio comparten costes y beneficios al 50%.

Recomiendo la revisión de esta presentación de Proyectalis y esta otra de Peter Stevens donde se analizan en profundidad las características, riesgos y beneficios de estas formas de contrato y algunas más.

¿Y todo esto por qué?

Pues, como decía al principio, para evitar movernos en el triangulo de hierro que acostumbra a perjudicar al proveedor y entrar en una dinámica de ganar-ganar en la que ambas partes salgan beneficiadas.

¿Utilizáis contratos ágiles en vuestras organizaciones? ¿qué tipos de contratos empleáis? ¿cuáles son los resultados? ¿estáis satisfechos?

5 ejemplos de contratos ágiles

Scrum no es para todos

Hace algún tiempo que me pregunto si Agile y Scrum en particular son una moda o si están aquí para quedarse. En mi trabajo tengo contacto con gente de muchas empresas que desarrollan software; desde clientes a proveedores o candidatos a los que entrevisto en procesos de selección. La gran mayoría me explican que en sus respectivas empresas usan Scrum pero todos ellos puntualizan en seguida que no son talibanes de Scrum. Utilizan aquello que les es útil. No sé si eso es Scrum o si en muchos casos se pervierte el sistema y se pierden los beneficios.

Scrum es fácil de entender a nivel teórico pero más complejo de aplicar en la práctica. Y es que Agile no es para todos. No se trata simplemente de una forma de hacer las cosas por parte del equipo de desarrollo. Se precisa de un cambio organizacional importante y de equipos experimentados y técnicamente muy capaces.

Hay muchas cosas que pueden hacer que una implementación de Scrum no funcione. En mi empresa hemos estado probando Scrum durante unos 6 meses y estamos llegando a la conclusión de que no es la forma ideal de trabajo para nosotros por diversos motivos:

– Trabajamos con contratos de precio fijo y alcance definido.
– Nuestros clientes, en general, no están interesados en comprometerse como Product Owners.
– Nuestros equipos, con frecuencia, no tienen la madurez suficiente y no se autogestionan.
– Los equipos de proyecto no son estables y sus integrantes trabajan en varios proyectos simultáneamente.

Y podría seguir con más razones.

Eso sí, en nuestras pruebas hemos descubierto cosas positivas. Los valores ‘lean’ y los tableros Kanban nos resultan muy útiles. Detectar y eliminar desperdicios (waste) además de ver todo el proceso en su conjunto nos está resultando provechoso.

Y es que, como en muchas otras disciplinas de conocimiento, la dirección de proyectos está en constante evolución. Es importante mantener una actitud abierta a los cambios, a la posibilidad de cometer errores y aprender de ellos y a la mejora constante (un valor de ‘lean’).
Estoy seguro de que en breve (si no han aparecido ya) surgirán metodologías de síntesis entre lo ágil y lo predictivo, como ya anunció hace años Juan Palacio. Y deberemos seguir experimentando y aprendiendo de forma constante y con actitud al tiempo crítica y abierta.

¿Cuál es tu opinión? ¿Qué experiencia tienes con Scrum o con otras formas de trabajo ágiles?

Scrum no es para todos