The importance of the study phase at the beginning of a project

Have you ever faced a situation where your project sponsor or other stakeholders expect that you start delivering results just after​ your first contact with the project?

Many people tend to start working in the execution phase when facing a problem instead of dedicating enough time to understand what they need to do. This may result in delivering the wrong solution or a not efficient one.

What should we do at the beginning of a project?

Let’s start dedicating enough time to understand the problem. When I was studying engineering I had a teacher who told me that I should dedicate half of the time he gave me to do a exam to understand the problem. The other half should be enough to describe and calculate the solution.

I followed this strategy not only in his exams but in other exams as well and I never regretted it.

Understanding the problem means not only reading what is said but also what is not said when our client explains his need.

Moreover we should not stop when we find the first potential solution to our problem. That is laziness. There are many tools to find creative solutions to a problem, once we find some of them a good approach is to compare them and identify the best one. And when we have the one we consider the best we should consider it from a different point of view and identify all the possible negative points it has. After that we can consider if it is still the best option for our problem.

Understanding your project

It is the same with projects. Dedicating enough time to the study phase of a project usually pays off.

It is important to identify and meet all stakeholders, to understand their expectations, how the outcome of the project would affect them, their priorities and their level of support and commitment with the project.

The scope of the project should be clearly identified (at least at a higher level). Sometimes we do not know at that stage all what will have to be done but we should know what will not be done in the project. Risks, budget and timing should be discussed as well with the project sponsor and main stakeholders.

And everything should be written down in a document that the team members and other stakeholders can consult at any time during the project.

What do you think? How many time do you tipically spend in this phase of your projects? What is the proportion in comparison with the whole duration of the project?

 

 

 

The importance of the study phase at the beginning of a project

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