2 strategies when you do not master the tools your team uses.

Sometimes you may be assigned as a project manager to a project that includes in its scope a technology that you know superficially or just do not know at all. What can you do? How can you be part of the project team, contribute positively and not be a blocker?

There is a parallel discussion that we could start about the deeply commented topic of the project manager and the level of technical knowledge she should have about the technologies used in the project. But this is something I want to let aside in this post and focus on the fact that ‘you have been assigned to the project’ for no matter what reason and you have to deal with it.

My basic strategy would be: in the short term focus on being a facilitator and trust the specialists. On the long run, if you are going to manage more projects of this kind in the future, improve your skills.

Focus yourself in being a facilitator.

You must understand what is your main role in the project and avoid doing something you are not prepared to do. Focus in helping the team work and in obtaining the best possible outcome of their efforts: remove obstacles, identify the causes of problems and help them finding the best solutions.

Improve your skills when the project situation allows it.

If you are going to face a similar situation in future projects or you are just like me, an insatiable seeker of knowledge that constantly looks for new tools for my toolbox, you can do a training on the techniques your team has been using in the project. The level of depth will depend on your interest and the kind of job you have to do.

What is your opinion? Do you face frequently this situation? How do you deal with it?

2 strategies when you do not master the tools your team uses.

Budget owners and budget managers

Are project managers accountable for potential overruns in the costs of their projects?

This is a typical question that appears frequently in conversations between PMs. In my opinion PMs must:

  • obtain estimations of the whole costs of the project
  • determine the budget for the project
  • obtain the funds from the sponsor
  • agree with the sponsor on how to control the costs of the project
  • ensure that there is a system to track all the costs of the project and that it is properly used
  • inform periodically all the relevant stakeholders about the actual costs (vs the planned ones)
  • manage change requests and obtain approvals (or not) if additional costs are required

In big organizations there are usually sponsors and executive sponsors.

Executive sponsors are the ones who own the budget.

They provide the funds and guide the project in order that it delivers results according to the strategy. However these kind of people are usually very busy and is not easy to get access to them. It is important to ensure that thay delegate some functions in the ‘simple’ sponsors.

Sponsors are less senior people but frequently more prepared to understand technical details and with enough availability to dedicate time to the project in a regular basis. It is important to identify one of them in your project and to obtain their commitment to support you as a PM.

Sponsors do not own the budget but they have authority to manage it.

They are the ones that can follow with the PM the day to day of the project, read the updated cost reports and even approve some limited additional costs. They make the life of the PM easier and are crucial for the project success.

What is your experience with sponsors? Have you identified these 2 roles in your projects? Do you have this kind of sponsors in your organization?

 

Budget owners and budget managers

4 situations where the communication channel matters

Communications are the area where project managers spend most of their time. It is a complex and important area because interacting with people is complex and because it significanty affects the way others see the project, their perceptions.

Choosing the most appropriate communication channel in each situation is crucial to be successful in critical situations.

In general, we have synchronous communication tools, like phone, videoconference, personal meetings or just conversations in the corridors. And also asynchronous tools like email. Chat could be considered a mix between both; it is supposed to be synchronous but many people use it asynchronously.

Let’s analyze some situations now and get some insights about the prefered channels in each case:

  • There is a serious problem in the project. It must be solved urgently as it will affect seriously the delivery date or the quality or the costs of the project.
    • Direct conversation with the client or the project sponsor. Prefered channel: formal or informal personal meeting. If not posible, video conference (the posibility of seeing you increases the chances of success because it transmits also non verbal language) or phone call.
    • After the conversation write an email to confirm the agreements.
  • There is a misunderstanding with a remote collaborator related with specific details of a technical issue.
    • Email with the details followed immediately by a video conference or phone call to clarify.
  • A decision about an issue must be taken by a group of stakeholders. It is a very open point where different approaches could be valid.
    • Meeting with all the involved stakeholders, preferably in person. Alternatively a video or audio conference could be an acceptable option.
    • Follow up email with the minutes of the meeting and the summary of action points agreed upon.
  • One of the project stakeholders disagrees publicly with you and uses an email with many other recipients in the loop.
    • Call him, or better meet him in person, and try to solve the issue directly with him.
    • After the meeting go back to the email and share the conclusions with the rest.

What do you think about the approaches to these situations? Have you been involved in any of them or a similar one? How did you manage it? Did it work?

4 situations where the communication channel matters

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

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

Do you control your projects or do they control you?

“A tree as great as a man’s embrace springs from a small shoot;
A terrace nine stories high begins with a pile of earth;
A journey of a thousand miles starts under one’s feet.”

Lao-Tse – Tao Te Ching

It is a lot easier to face a problem when it is in an early stage than when it has grown too much. So, this shows us one of the most important attributes of a good project manager: proactivity.
A project manager’s work should not focus on dealing with problems, it should focus on preventing them. We must manage the risks of a project, but how can we do it more efficiently? It is not possible to preview everything.

In my opinion, we must be prepared and have:

A system

A system, for instance, like the one explained in the PMBoK. It is necessary plan to manage risks, to identify them not only in the beginning of a project but during the project too, analyze the identified risks and develop responses. And repeat this process periodically during the life of the project.

Team support

The whole team must participate in the process of identifying risks and planning responses. They are able to help us identify possible problems that the project manager couldn’t imagine.

Communication

That takes me to the third point: good and fluent communication with the team, the client (and/or the Product Owner).
The Project Manager also must contribute to create an environment of confidence amongst the project team so that ideas, problems, risks, solutions, … flow in the team.
Everybody should feel that they can share their thoughts freely and all the important information should flow easily so that the ones who must use it to make decisions have it when they need it.

Tools

And that brings me to the final point: the tools.
We need tools to support communication, plans, assessments, … I have included them in the end because I think they are necessary but they don’t make the system. They make our life easier but they are useless if we do not have a plan and processes to systematically manage risks and we have not created an environment with the team where they feel free and motivated to communicate.

What do you think is more important? What kind of processes do you use in your projects to manage risks? Does the team always help proactively?
Please, share your comments.

Do you control your projects or do they control you?