Uncategorized

Troubleshooting benefits management in projects

jmartinmateo, , , , Leave a comment
Image courtesy of StockAI

The wake up call

Some time ago I had a personal learning experience around the management of the benefits in a project.

The project was going well considering that the product was being developed and deployed on time, with the required quality and within the approved budget. Of course we had experienced difficulties during the project but the team and the product manager had the impression that we were achieving our objectives. And then, suddenly, we received a challenge from our business sponsor: he did not agree with our view of the project being a success and considered that we should reduce our satisfaction level as he challenged the business benefits we were delivering.

What had happened?

On the technical and operational level the project team had been working with a prioritized backlog that was supposed to be aligned with the business objectives. On the strategic level it looked like we had some Key Success Factors defined and agreed but when we looked at them closely with our sponosr we saw that they were described in an ambiguous way. And apparently they were being interpreted differently by the sponsor and the project team.

I have recently read the Strategy Implementation Playbook and according to this guide it seems that we had missed some key aspects in the Benefits Management Process:

  1. Identifiying and structuring benefits (done)
  2. Planning benefits realization (partially done)
  3. Realizing and tracking benefits (failed)
  4. Evaluation of benefits (failed)

Accountability for benefits management rests on the project sponsor. The fact that in many cases all or part of the benefits are non cashable makes it difficult to make them tangible and quantifiable in an objective way as they cannot be expressed in monetary terms. In addition, as benefits realization happens some time after transition into use, a delay is generated in the feedback loop towards the project team that does not help to ensure they are following the right roadmap.

For the planned continuation of the next phase of the project we needed to put in place a framework to manage and realize benefits. A good framework I have identified in the mentioned book is this one from APM.

Benefits realization management is not a simple thing. It requires a mature organization with project and program sponsors committed to devote time and resources to follow a benefits management lifecycle as the one presented in the link above. But if we have discipline to apply such a framework we can enter into a virtuous circle as the projects that will be presented for approval will have stronger business cases to support them since benefits realization will be properly tracked. The more accountability on benefits realization the stronger and well defined business cases will be approved by the organization.

A Benefits Realization Plan is a must have

A Benefits Realization Plan (as stated by PMI) is a document outlining the activities necessary for achieving the planned benefits. It identifies a timeline and the tools and resources necessary to ensure the benefits are fully realized over time. It defines:

  • Benefits and associated assumptions, and how each benefit will be achieved.
  • Metrics, including KPIs, and procedures to measure progress against benefits.
  • Roles and responsibilities required to manage benefits.
  • How the resulting benefits and capabilities will be transitioned into an operational state to achieve benefits.
  • How the resulting capabilities will be transitioned to the individuals, groups, or organizations responsible for sustaining the benefits.
  • Processes for determining the extent to which each project or program benefit is achieved prior to formal closure.

An improvement approach

In the case of the project presented previously my improvement approach is:

  1. Prioritized backlog but open for changes during the life of the project as long as the items coming represent a similar level of effort as the items discarded from the backlog.
  2. What remains fixed is the budget available to make it all happen. It must be aligned with the business case that justifies the creation of the project.
  3. As part of the business case we need to have:
    • Key success factors to help us understand what we want to achieve and how we will recognize that we have achieved it. They must use a language understood by every member of the team (technical and business).
    • Business KPIs that guide us to measure if we are moving in the direction defined by the key success factors. However, the map is not the reality. KPIs must be carefully chosen and challenged as the better they represent what we want to achieve the better they will help us to succeed if we hit our KPI targets.
  4. We must link components outputs to the planned project outcomes. Each time we include an item in our backlog we must ask ourselves:
    • How does this item help me to achieve any of the business goals? That is, what is the value added by this item?
    • To which key success factors is this item contributing?
    • Do we have valid business KPIs to measure its success?
  5. In parallel we need to keep the traditional operational KPIs that measure if we are on time, on budget or which percent of the scope we have already delivered.

Operational KPIs are useful for the tecnical team and the project manager but hiting their targets does not necessarily mean that the project will be a success. We could just be moving very accurately in the wrong direction.

These 5 points being part of a consolidated Benefits Realization Plan should help us increase our chances to realize the planned value of the project and make appropriate decisions if we are missing our targets.

Is your organization mature tracking and realizing benefits from its initiatives? What kind of framework do you use?

Please, add your comments as I am eager to learn from other experiences.

Troubleshooting benefits management in projects

3 ways to manage difficult Project Sponsors

jmartinmateo, Leave a comment

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

jmartinmateoLeave a comment

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.

jmartinmateoLeave a comment

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

jmartinmateo, , , Leave a comment

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

jmartinmateo, , , Leave a comment

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

jmartinmateo, , , Leave a comment

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.

Conclusiones

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

jmartinmateoLeave a comment

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 Cooper, ITIL 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

La utilidad del Earned Value (EV)

jmartinmateo, , , , 2 Comments

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)