3 ways to manage difficult Project Sponsors

The role of the project sponsor is key in the success of a project. The sponsor must ensure the alignment of the project with the strategy of the organization, he must champion the project in front of other senior managers and provide ongoing direction as the project evolves. And his responsibility does not end when the project finishes; he must also ensure that the client makes effective use of the project deliverables to achieve the results planned in the business case.

So the role of the project sponsor is strategic; she must be an enabler to create the conditions for the project team to work successfully and let the project manager the day-to-day execution.

However, many times project sponsors do not have the skills, the experience or just the awareness of their duties regarding the project and how they can affect its final outcome. What can we do as project managers to:

  • detect this risk for the project
  • help the sponsor to fulfil his/her obligations

Find out sponsor’s expectations on the project

In a subtle way, a communications and risk assessment strategy con be prepared so that the PM can adapt his/her approach and communication methods to obtain the maximum support from the sponsor. An effective approach is to ask open questions to the sponsor in your first meeting with him, like: ‘What are your expectations for this project? What kind of risks would you consider? What is the level of priority of this project in your strategy? This kind of approach will allow you to learn more than by asking closed and very focused questions.

Early discovery of the sponsor capabilities and capacities

During the first meetings with the sponsor it is important also to assess his capabilities regarding this role and also his capacity to assume the workload that it involves. It is common that  sponsors are very busy executives who have a full time ordinary activity and the sponsorship of a project is something added to their usual job.

Moreover the interest in the project by the sponsor is critical an should not be taken for granted. Sometimes there are sponsors who are assigned to a project just because there must be a sponsor or because the project outcome is somehow related with their function. This situation will affect the project day-to-day and the involvement of the sponsor in the project.

The sooner the situation is detected the earlier the project manager can start preparing a plan to manage the risks. One possible option is helping the sponsor build his/her sponsorship competencies by framing possible solutions to the problems you escalate and explain the options.

The Project Sponsor as a facilitator

Finally, it is important to confirm that the sponsor understands that he should not interfere in the day-to-day  of the project. The project manager is responsible for this. The sponsor would better be a facilitator that helps the project manager and provides the necessary organizational support needed to make strategic decisions and create a successful outcome from the project.

What is your experience? Have you ever had to deal with a difficult sponsor? What was your strategy?


3 ways to manage difficult Project Sponsors

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

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.

Problem solving process

Many times we must deal with problems in our management activity that it is necessary to face in a systematic way, without improvisations, in order to be able to solve them effectively.

3D Problem Solving
3D Problem Solving

3D Problem Solving by StockMonkeys (under CC by 2.0)

During my professional activity I have successfully used many times the following process of 7 steps:

1. Symptom detection.

2. Problem definition

3. Root cause analysis

4. Research of various alternatives of solution

5. Analysis of alternatives

6. Decission taking

7. Action plan.

Now I am going to explain each phase a little bit:

Symptom detection.

Frequently, it is not the root cause of a problem what we notice but some of its consequences, its symptoms. It is important not to take a symptom as the cause of a problem.

Problem definition

Once we have analyzed the symptoms it is important to focus in the real problem. For instance, maybe you have found that you cannot access the intranet of your company but the real problem is that your LDAP services has failed and you cannot also start a session in your file server or navigate using the corporative proxy server. In this phase it is very important to collect as much data as possible about the problem.

Root cause analysis

What is the real reason of the problem? This is probably the most important point. If you fail to identify the root cause of the problem any solution that you may implement will not solve the problem.

There are many methodologies to help you find the root cause of a problem: 5 whys method, fishbone diagrams, pareto charts, brainstorming, …

Research of various alternatives of solution

Once we have identified the root cause of the problem we can start looking for apropriate solutions. it is important not to stop once we have found a feasible solution. That is laziness of thinking. It is necessary to struggle a little bit more and look for some more alternative solutions.

Analysis of alternatives

When we have a group of solutions, it is necessary to study each one. We must look for pros and cons of each solution and decide which one is the best one.

Decission taking

Once we have the best possible solution it is important to review it again from another point of view. We must look for all the possible inconveniences of the solution. One way to do so is to put yourself in the place of your boss or somebody who will have to aprove the final action plan and try to find all the possible weak points in our argumentation.

Action plan

After one of the alternative solutions has been approved it is necessary to implement an action plan to take it into practice. The action plan must have a set of ordered actions with people responsible to carry them on and the final dates to have each one implemented.

Of course, the plan must be communicated apropriately and have the approval and support of at least a member of the organization with enough authority and executive power to ensure it will be implemented as planned.

A final step.

And a final point. It is a must to verify the results of the action plan and review if the problem has been solved. If it has not yet been solved it will be necessary to analyze if the failure has happened because of a bad implementation or because of a bad root cause analysis, and act in consequence going back to point 7 or to point 3 of the method.

What about you? Do you use this methodology to solve problems? What could be improved? Please, share with us any alternative methodologies that you know or use.

Problem solving process

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

Planificando la transición a IPv6

Tengo que reconocer que había subestimado las implicaciones de la inminente transición de IPv4 a IPv6. El pasado jueves (19/01/2012) tuve el privilegio de asistir a una jornada formativa sobre la transición a IPv6 de la mano de un reconocido experto mundial como Jordi Palet y mis impresiones previas sobre este asunto han cambiado por completo.

En este blog hablo exclusivamente de cuestiones profesionales por lo que voy a limitarme a analizar las implicaciones que este proceso de transición tiene en un entorno empresarial, dejando de lado las afectaciones a los usuarios domésticos.

El cambio es necesario y no negociable

No es una cuestión de decidir si me cambio o no a IPv6. Si no hacemos nada a nivel de empresa y seguimos trabajando con IPv4, en los próximos meses nos podemos encontrar con varios efectos:

1. Podemos empezar a tener problemas para acceder a determinadas páginas web. Por ejemplo, si tenemos proveedores en China podría darse el caso de que no pudiéramos acceder a sus páginas web. En la región de Asia Pacífico ya se han quedado sin direcciones IPv4. Eso significa que cuando un nuevo usuario de esa zona del mundo vaya a su ISP y le pida nuevas direcciones públicas éste le va a decir que ya no puede dárselas en IPv4. Este nuevo usuario podrá optar por implementar sus servicios con IPv6 (en China ya llevan años haciéndolo) o trabajar con IPv4 pero no con una dirección IP pública sino privada (asignada por el ISP y compartida con otros usuarios mediante NAT).

La consecuencia para mi es que si este usuario chino decide montar su portal web en IPv6 puede que yo no sea capaz de llegar hasta su portal (estamos suponiendo que nosotros nos quedamos en IPv4) o que si opta por trabajar con IPv4 bajo NAT determinados servicios y/o partes de su portal web no sean accesibles para mi (es bastante complejo desarrollar aplicaciones web que funcionen a través de varios niveles de NAT).

2. Si la web corporativa de mi empresa sólo funciona con IPv4 no podrá ser accedida por usuarios que trabajen exclusivamente con IPv6 (como ya empieza a pasar en algunas regiones del mundo). Las aplicaciones de mi organización, como por ejemplo el portal web corporativo, deben ser capaces de funcionar con una doble pila IPv4-IPv6 si quiero que sigan manteniendo su funcionalidad actual.

3. El próximo 6 de junio de 2012 los grandes proveedores de contenidos de internet (Google, Facebook, Yahoo, Microsoft Bing…) activarán de forma definitiva y permanente IPv6.

Ese es un primer paso que pretende forzar a los ISP a la transición a IPv6 y que antecederá al despliegue de nuevos servicios basados en las nuevas características de IPv6 de las que carece IPv4.

Eso significa que si no hago cambios y sigo en IPv4 no podré acceder a esos nuevos servicios.

Quiero que uses IPv6
Fotografía cortesía de Blacknight (CC BY 2.0)

Necesito un plan

Como consecuencia de lo expuesto en el apartado anterior, aunque sólo sea para seguir manteniendo los servicios actuales, necesitaremos elaborar un plan (un proyecto en sí mismo en el caso de organizaciones de cierto tamaño) para organizar la transición.

¿Qué elementos deberemos tener en cuenta? Siguiendo las recomendaciones de Jordi Palet, será conveniente que nuestro plan incluya los siguientes puntos:

1. Formar en IPv6 al departamento TIC.

2. Hacer un nuevo plan de direccionamiento IP.

Y no sirve intentar traspasar lo que hay en IPv4 de forma análoga a IPv6. Eso sería un error porque los cambios en el nuevo protocolo nos llevan a una nueva estrategia de direccionamiento de partida. Es muy recomendable utilizar un plan de direccionamiento NO contiguo (que puede ser gestionado por un dispositivo IPAM) y que nos permite aprovechar las nuevas prestaciones de IPv6 y dificultar ataques de escaneo de puertos

3. Obtener direcciones IPv6.

En el caso de una empresa que trabaje con varios ISP aquí hay una novedad. Hay que gestionar la obtención de las nuevas direcciones globales con RIPE NCC directamente (en el caso de Europa y Oriente Próximo y parte de Asia Central). Es lo que se llama direccionamiento IPv6 Independiente del Proveedor o “portable” y se regula mediante lo que se conoce como “contrato de usuario final”.

RIPE NCC nos va a entregar direciones IPv6 de tipo /48, por defecto. Si sólo trabajamos con un ISP y gestionamos la obtención de direccionamiento IPv6 con él deberemos exigirle ésto mismo.

4. Auditar la red.

Se trata de analizar si nuestro equipamiento actual (cortafuegos, balanceadores de carga, IDS, proxys, …) soporta IPv6.

5. Planificar actualizaciones y/o adquisiciones.

Aquí incluyo tanto aplicaciones (propias o ajenas) como sistemas operativos, firmware, o incluso certificados ssl.

Un punto importante es hacer las gestiones necesarias de forma que desde “ya” no se adquiera ningún nuevo equipamiento en la organización que no soporte IPv6.

Para empresas de gran tamaño todo este proyecto puede llevar tiempo y ser costoso. Parece, en ese caso, razonable abordarlo en 2 fases: primero asegurarme de que mis clientes y proveedores puedan acceder a mis servicios y aplicaciones y después conseguir que mis usuarios puedan acceder a internet con IPv6.

La estrategia de transición a IPv6 de mis ISP

¿Cómo nos afectará la estrategia de transición de nuestros proveedores de internet? Pues mucho. Los ISP españoles se van a quedar sin direcciones IPv4 a lo largo de los próximos meses (de hecho, Jordi Palet nos comentó que alguno de ellos ya las habría agotado) y han empezado a gestionar la solicitud de direcciones IPv6 a RIPE NCC.

Pero no van a dar soporte IPv6 de la noche a la mañana. Eso significa que utilizarán mecanismos de transición (generalmente basados en túneles) como NAT444 o Dual Stack Lite. Son mecanismos que, en general, trasladan el NAT del CPE a la propia red del operador, lo que se conoce como Carrier Grade-NAT (CGN).

Como consecuencia, las mismas direcciones ip son compartidas entre varios usuarios del ISP repartiendo el conjunto de puertos entre ellos (a razón de 2000 puertos por cliente). En este escenario muchas aplicaciones dejan de funcionar, no es posible hospedar servidores en “puertos conocidos” y es preciso utilizar complejos mecanismos como ALG para traspasar el NAT del ISP y lograr que algunas cosas funcionen.


1. No podemos esperar más. Hay que planificar y ejecutar la transición a IPv6 en nuestras organizaciones.

2. Debemos informarnos detalladamente de los planes de transición de nuestros ISP para ver cómo nos van a afectar y decidir si nos conviene su estrategia o si será necesario un cambio de proveedor.

Para acabar esta entrada, os dejo un enlace hacia un buen libro introductorio a IPv6 que se puede descargar de forma gratuita; “IPv6 para todos“.

Planificando la transición a IPv6

Conociendo la nueva ISO 20000

El pasado 3 de marzo de 2011 tuve la oportunidad de asistir al I Forum Internacional ISO 20000 en Barcelona.

Mi objetivo era conocer la norma ISO 20000, a la que me acercaba por primera vez, con las novedades que aporta la nueva versión . La oportunidad era muy interesante, dado el nivel de los ponentes: Lynda CooperITIL Master -una de las pocas personas en el mundo con esa titulación- y redactora de la parte 1 de la norma y Diego Berea, Director de Ozona Consulting y co-redactor de la parte 2 de la norma ISO 20000.

La norma ISO 20000 certifica los servicios prestados por el área de TI de una organización a sus usuarios, ya sean éstos internos o externos. Diego Berea lo explica muy bien en esta entrevista.

Hay varios aspectos que me han interesado de la nueva versión de la norma; su mejor alineamiento con ITIL y su nueva organización que facilita su incorporación en un sistema de gestión unificado con otros estándares como ISO 9001 o ISO 14001.

Fotografía cortesía de John Lutz (http://www.flickr.com/photos/24585765@N00/2242183284) bajo licencia CC


No obstante, mi impresión es que es una norma más pensada para ser aplicada en organizaciones con departamentos de TI de cierto tamaño, cosa que excluye a muchas de las pymes de nuestro país. Ésto se debe a que la norma incorpora 13 procesos certificables y deben implantarse todos ellos. En empresas con departamentos TI reducidos no parece razonable que tengan que haber algunas personas siendo responsables de muchos de estos procesos a la vez. En estos casos, mi opinión es que parece más conveniente la aplicación de algunas de las buenas prácticas de ITIL, sin ánimo de certificar la organización (ITIL sólo certifica a personas).

Sin embargo, como se explica en  ésta otra entrevista España cuenta con cerca de 100 empresas certificadas desde el año 2006 a marzo de 2011 y está muy destacada en este aspecto a nivel internacional. No es normal. La explicación, como se ha indicado en las conferencias del Forum, viene dada por las subvenciones del Plan Avanza.

Mi impresión final es que, si bien a empresas con departamentos de TIC de tamaño reducido la ISO 20000 les viene grande y probablemente les resulte más adecuado adoptar selectivamente algunas buenas prácticas ITIL, en el caso de subcontratar servicios de TI a empresas especializadas del sector sí que será recomendable pedir que éstas estén organizadas (y certificadas) internamente según la ISO 20000. Es un elemento diferenciador y garantiza un cierto nivel organizativo y de calidad.

Esta exigencia a nuestros proveedores puede tener todavía mayor sentido cuando los servicios ofrecidos por éstos sean entregados en la modalidad de cloud computing. La certificación ISO 20000 además de ser un elemento diferenciador puede contribuir a ayudar a homologar (y facilitar la comparación de) los servicios de TI ofrecidos por organizaciones desde paises diferentes del nuestro.

Conociendo la nueva ISO 20000