proyecto

Gestionar la incertidumbre

jmartinmateo, , , Leave a comment

Cambios y más cambios

Vivimos tiempos de profundos cambios. Posiblemente por el hecho de estar en pleno ojo del huracán no seamos conscientes de lo mucho que está cambiando nuestra vida en los últimos años. Y lo que queda.

Los cambios generan incertidumbre y la incertidumbre da paso al estrés. ¿Estamos preparados para gestionarlo? La situación es complicada porque es importante tener autocontrol y gestionar correctamente nuestras emociones en casa con la familia, en la oficina con nuestros compañeros de trabajo, jefes o clientes. Y lo cierto es que las tensiones se observan a cada paso que das.

He leído bastante sobre el tema y he practicado algunas técnicas. No me considero un experto ni mucho menos pero sí que me gustaría compartir (siguiendo la filosofía básica de este blog) algunas ideas con vosotros, por si os pueden ser de utilidad.

Incertidumbre

Incertidumbre, por Manon71. Licencia Creative Commons.

No tenemos el control de nuestros proyectos

Hay técnicas aplicables a la gestión de proyectos y técnicas aplicables a nuestra forma de actuar personal, como jefes de proyecto.

En mi opinión un concepto fundamental es asumir que no tenemos el control. Con frecuencia pensamos ésto pero nuestra mente se empeña en mantenernos en una especie de falsa ilusión de que tenemos el control de nuestra vida, de nuestros proyectos. Sin embargo, momentos clave como la muerte repentina de un ser querido o las drásticas decisiones empresariales que están a la orden del día y que cambian de un plumazo la vida de muchos trabajadores o el rumbo de muchos proyectos nos vuelven a poner en nuestro sitio y nos sirven para recordar que somos muy pequeños y que sería muy osado creer que lo controlamos todo.

Es inútil preocuparse, y mucho menos enfadarse, por aquellas cosas que no podemos controlar. Debemos centrarnos en hacer bien todo aquello que depende de nosotros y olvidarnos de todo lo demás. En el ámbito de la gestión de proyectos, a mi me ayuda mucho una buena gestión de los riesgos del proyecto: no podemos evitar que algunas cosas pasen pero sí que podemos preverlas, analizar cual debe ser nuestra respuesta (si es que debe haber respuesta) y prepararnos para poder actuar cuando sea preciso.

No todo es previsible y solucionable pero saber que has previsto respuestas frente a los principales riesgos de tu proyecto te da tranquilidad. Una vez hecho ésto, relájate y disfruta. Y periódicamente, dentro de la vida de tu proyecto, vuelve a revisar riesgos. Algunos de los anteriormente identificados se podrán descartar ya y probablemente aparecerán otros nuevos que habrá que gestionar.

No tenemos el control de nuestra vida

A nivel más personal, lo que nos hace daño no es lo que nos sucede sino la forma como reaccionamos ante lo que nos sucede.

No podemos controlar todo lo que nos puede llegar a suceder pero sí que podemos controlar la forma como vamos a reaccionar ante lo que nos sucede. Sé que es más fácil decirlo que hacerlo y que se necesita una fuerte disciplina mental para actuar de esta forma pero yo lo he intentado hacer en algunas situaciones críticas y me ha servido.

Otro concepto importante. Debemos vivir el ahora, no el pasado (que ya no está) ni el futuro (que puede no ser como esperamos). No debemos pasarnos la vida, perdiendo el tiempo con nuestra mente siempre viviendo en un momento que no es el presente, el único que es real. Hay que tratar de olvidarse del futuro y de las consecuencias de nuestros actos del presente. La mente debe estar centrada en el ahora y lo que deba venir ya vendrá. Sobretodo, y vlviendo sobre un concepto anterior,  si no depende de mi lo que suceda en el futuro no vale la pena preocuparse por ello. En inglés, esta actitud se describe como “mindfulness“, que en español podríamos traducir como “conciencia plena”. No quiero extenderme en ello porque hay muchos recursos  sobre el tema en internet y es algo que va más allá del propósito de este blog.

Conclusiones

No te obsesiones por tener el control. No es posible.

Ten una actitud flexible, previendo posibles eventualidades y preparándote para ellas.  Una vez hecho ésto, olvídate de los riesgos que corres hasta que un desencadenante haga que se materialicen y, con ellos, tu respuesta. Mientras ésto no se produzca, estate tranquilo y céntrate en el ahora, no en el futuro ni en el pasado.  Haz bien tu trabajo.

Periódicamente revisa de nuevo los riesgos de tu proyecto, para adaptarte a los cambios.

¿Qué opinas de estos planteamientos? ¿crees que te pueden servir? ¿qué técnicas utilizas para gestionar la incertidumbre en tu vida personal o en tus proyectos?

Gestionar la incertidumbre

Green Project Management

jmartinmateo, , Leave a comment

Hace unas semanas tuve la oportunidad de asistir a una sesión sobre Green Project Management, organizada por el Capítulo de Barcelona del PMI, del que soy miembro y voluntario. A pesar de tener un cierto bagaje en gestión de proyectos y conocimientos y experiencia en la norma ISO 14001 debo confesar que esta certificación es para mi una total novedad.

La sesión resultó muy interesante. Conocimos los fundamentos de la metodología PRISM y también sus objetivos, de entre los cuales destacaría el compromiso de hacer que las actividades asociadas a los proyectos que llevamos a cabo dentro de nuestras organizaciones sean sostenibles y se limite y controle el impacto que tienen en el entorno en el que se realizan. Todo muy en línea con conceptos como responsabilidad social corporativa y sostenibilidad.

Algunos de los momentos más interesantes de la sesión se dieron al final, en la tanda de preguntas.

Project sustainability
Waste neutral

Imagen via Samuel Mann bajo licencia Creative Commons

Muchos de los compañeros del capítulo expresaron algunas dudas sobre la viabilidad de esta certificación en el contexto económico en el que nos encontramos. Seamos realistas, el criterio número uno (y con diferencia) que siguen las empresas a día de hoy en la gestión de sus proyectos es la rentabilidad y el control de los costes. La ponente, Lorena Perdomo, de avanzaproyectos, se esforzó en convencernos de que el reto está en conseguir ser sostenibles sin incrementar por ello los costes de los proyectos; ahí es nada.

Sin embargo, mi opinión es que si en el futuro un país quiere mantener ciertos niveles de bienestar debe aspirar a gestionar sus empresas y proyectos teniendo muy presentes los criterios económicos pero midiendo también muy bien su impacto en el entorno; la afectación medioambiental y social.

Desconozco, y no me atrevo a aventurar, qué recorrido tendrá esta certificación entre los profesionales de la gestión de proyectos pero, de entrada, es de agradecer que ponga sobre la mesa nuestra responsabilidad sobre la afectación que nuestros proyectos tienen en el entorno tanto durante como después de su ejecución.

¿Qué opinión tenéis sobre el tema? ¿qué pensáis de esta nueva certificación? ¿os planteáis habitualmente cómo afectan vuestros proyectos al entorno en el que se desarrollan o os limitáis a ejecutarlos? ¿qué grado de influencia pueden tener los project managers sobre las empresas en que trabajan para que se tengan más en cuenta los criterios de sostenibilidad en la gestión de proyectos?

Green Project Management

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

El proceso de test en el desarrollo de software

jmartinmateo, , , , , Leave a comment

La calidad del software que generamos para nuestras organizaciones es muy dependiente del esfuerzo y tiempo dedicados a su testeo.

No obstante, ese esfuerzo debe ser objeto de un análisis crítico que asegure que los resultados obtenidos compensan el coste dedicado. Por otra parte se debe ser consciente de los riesgos asumidos al limitar el esfuerzo de test. Como en muchas otras situaciones de la vida, se trata de buscar el equilibrio.

De acuerdo con el ISTQB el proceso de test debe seguir las siguientes fases:

  • Planificación y control
  • Análisis y diseño
  • Implementación y ejecución
  • Evaluación y reporte
  • Cierre

 

Estas fases se suceden secuencialmente, si bien el control debe seguirse durante todas las fases del proceso, no sólo en la planificación inicial.

1. Planificación y control

Debe iniciarse, idealmente, lo antes posible dentro del ciclo de desarrollo del software. Es preciso completar un plan de test que incluya:

  • recursos necesarios,
  • tiempo estimado,
  • servicios, medios adicionales,
  • herramientas, …

El testeo exhaustivo es, por lo general, imposible. Es preciso, por tanto, definir prioridades y analizar los riesgos de omitir determinados tests o de limitar su intensidad o alcance.

2. Análisis y diseño

En esta fase se determinan las técnicas de test a seguir, alineadas con la estrategia definida en el paso anterior, se definen los casos de test y el calendario o secuencia. En paralelo se deberá poner en marcha la infraestructura necesaria para realizar los tests.

3. Implementación y ejecución

A partir de los casos de test definidos de forma lógica en la fase anterior se derivarán y ejecutarán casos de test concretos.

En esta fase es preciso seguir un protocolo de test que incluya las partes a testear, las personas asignadas, los tiempos y calendarios, la extensión de cada test a realizar y los resultados esperados.

Además, es fundamental realizar un registro de los resultados.  Éstos nos pueden llevar a plantearnos si los posibles errores encontrados están dentro o fuera del objeto del test y, consecuentemente, a replantearnos el protocolo diseñado y seguido.

Al mismo tiempo, los errores encontrados deben ser documentados, priorizados y asignados a los desarrolladores para solucionarlos.

En otra entrada entraré en mayor detalle pero aquí quiero comentar la importancia de agrupar los casos de test en secuencias y/o escenarios y de realizar primero los llamados “smoke tests” que permitan verificar la bondad de las funciones principales antes de entrar en  casos más detallados y completos (que no tienen sentido si los tests básicos no han sido superados).

4. Evaluación y reporte

En esta fase empezaremos por evaluar si los criterios de finalización de los tests han sido alcanzados.

En caso negativo será preciso analizar si se ha debido a que algunos casos de tests han tenido que ser bloqueados o si es preciso añadir más casos de test.

Para tomar una decisión razonada, como siempre, habrá que tener en cuenta tanto los riesgos asociados con no añadir más casos de test como los costes (dinero y tiempo) de hacerlo.

En cualquier caso, finalizaremos esta fase con un informe que incluya todos los resultados y las conclusiones y decisiones tomadas.

5. Cierre

Esta fase, desgraciadamente, suele ser olvidada en, muchos proyectos.

La experiencia obtenida durante el proceso de test debe ser analizada y puesta a disposición de otros proyectos. En otro post de este mismo blog ya he hablado sobre ello dentro del contexto de la gestión de proyectos en general.

La documentación y aplicación de los resultados de una evaluación crítica de las actividades realizadas durante el proceso de test, considerando esfuerzo en relación a resultados, nos llevará a la mejora continua.

Para acabar, otro punto a tener en cuenta en esta fase final es la necesaria conservación del “testware” (casos de test, protocolos, infraestructura, herramientas) para su uso posterior cuando nuestro cliente nos pida cambios o cuando encontremos nuevos errores ocultos en nuestra aplicación.

El proceso de test en el desarrollo de software

The importance of the lessons learnt

jmartinmateo, 2 Comments

During this month (july 2012) I am going to finish a software development project that I have been leading as a project manager since its beginning in february. It has been hard, physically and mentally, and with very challenging deadlines.

Also in these weeks I am reading an interesting book from Peter Taylor, “The lazy project manager”. I have taken notes of two important ideas from the book that I can apply in this final phase of my project:

The shape of the projects.

Projects are thick in the beginning, thinner in the middle and thick again in the end.

It means that we must dedicate a lot of time and effort to bring the project inside the road at its initial phase (planning) in order to be able to “rest” a little bit during its execution and  monitoring phases. Finally we have to notice the importance of the closing phase and dedicate the necessary time and effort to finish our projects properly.

This final effort must be shared with the rest of the team, the sponsor, the client and also the other stakeholders. A part from obtaining acceptance of all the deliverables and closing contracts a very important activity in this phase is to register the lessons learnt during the project.

This is something that many times is forgotten or understimated.

What we know we know, what we know we don’t know  and what we don’t know we don’t know.

At the end of the book Peter Taylor quotes Mr. Donald Rumsfeld (12 February, 2002, US Dept. of Defense news briefing): ‘As we know, there are known knows. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know‘.

I have enjoyed specially this part of the book.

When we work on the registry of the lessons learnt during the chapter we must consider:

  1. What we didn’t know at the beginning of the project and we have learnt during its development. That is to know what we know.
  2. To know what we don’t know. The gaps in our experience of the project that we can fill up by asking our team.
  3. The unknown unknowns. This must be unveiled through a project retrospective where all the stakeholders should participate. It is a healthy habbit to plan for this in the final phase of the project.
Would he repeat it ?
Horse stumbles after the jump, would he repeat it ?

And why do we have to dedicate so many time and effort to all these lessons learnt if our project is almost closed and the deliverables have already been accepted?

In order to avoid that the sentece that says that ‘the man is the only animal capable to trip twice over the same stone‘ continues being true in the future. At least I think we should try it. Don’t you?

The importance of the lessons learnt

Leading with our example

jmartinmateo, , Leave a comment

Some days ago I read an interesting post from Voices on Project Management. It made me think about the way our behavior can influence our team in a project, especially its young members, that can be prompted to imitate our conduct.

The way we deal with the project stakeholders or even the way we manage our relationship with managers and people from other functional areas, even if they are  unrelated with the project, are telling our team mates how we expect them to deal with these people too.

Desert leader
Image by Hamed Saber (CC BY 2.0)

For instance, if we do not control ourselves and criticize without compassion the manager from a functional area because we are having problems to obtain the resources she had committed to provide to our project we are also telling (consciously or not) our team that this behavior against some project stakeholders is accepted (or acceptable).

On a positive situation, a smart negotiation (win-win) with a project vendor can show our team that we expect them to keep a good relationship with the sellers involved in the project, we want our vendors to grow with us and we want the relationship with them to last further than the project.

Many different situations come to my mind when I think about the way that our actions or communications show our team mates what we consider an appropriate behavior:

  • the way we answer emails,
  • the way we manage meetings, especially difficult meetings,
  • the way we manage arguments between members of the team,
  • the way we react when a job mate comes to see us with a problem,
  • the way we follow the ground rules established for the project,
  • the way we act when somebody comes late to a meeting,
  • the way we accomplish our commitments,
  • the way we react when others make mistakes,
  • the actions we take when the team misses a milestone,
  • our conduct when we, or someone else from the team, receive a present from a vendor,
  • …

There are many situations during the life of a project that allow us to point out, implicitly or explicitly, the way to be followed by the team.

What other situations do you think that can help us indirectly coach a project team?

Leading with our example

Ya soy PMP. Valoración, agradecimientos y consejos

jmartinmateo, , Leave a comment

Después de 3 meses vuelvo a tener tiempo para escribir en este blog. Creo que esta entrada va a ser la más personal que he escrito hasta ahora.

Llevaba un año y medio preparándome para obtener la certificación PMP pero estos últimos meses han sido los más intensos, estudiando y preparándome en “modo test” para el examen. Finalmente me presenté el pasado jueves 19 de abril (de 2012) y aprobé.

Pero, ¿qué significa tener la certificación PMP? ¿se es mejor project manager por disponer de esta certificación? No es fácil de responder.

Lo que me ha aportado hasta ahora el PMP no es tanto el propio certificado como todo lo que he aprendido a lo largo del proceso de preparación.  Técnicas, buenas prácticas, metodologías, conocimiento de buenos profesionales y formadores en gestión de proyectos y también el hecho de demostrarme a mi mismo que sigo en condiciones de marcarme un objetivo ambicioso y esforzarme al máximo hasta conseguirlo.

Prepararse para el PMP requiere tiempo y esfuerzo y no es fácil hacerlo en el actual contexto de crisis en el que en el trabajo debes hacer cada día más con menos y al llegar a casa te esperan tus obligaciones familiares. Los ratos que se pueden dedicar a la preparación no siempre son los más productivos del día.

En todo este proceso he tenido algunas ayudas que ahora me gustaría compartir (siguiendo la filosofía de este blog) porque creo que pueden ser útiles para quien se quiera presentar al examen:

  • Libros: recomiendo 2 lecturas,
  • Herramientas complementarias: en la parte final de la preparación para el examen me ha ido bien utilizar
    • PM Flashcards, ayudan mucho al hacer un repaso final por áreas de conocimiento.
    • PM Formulas, permite entender bien todas las fórmulas susceptibles de aparecer en el examen y asegurarte de que no se te escapa ninguna. Además viene con 105 preguntas de examen sobre fórmulas. Muy práctico.
  • El blog de Josh Mankivel (en inglés) es muy interesante y proporciona consejos útiles basados en su experiencia con muchos aspirantes a PMP.

Quiero agradecer a Angel Águeda Barrero toda la información que habitualmente publica en su blog y especialmente la recopilación de exámenes gratuitos. Me ha resultado muy útil. 

Para acabar, mi agradecimiento también a otro PMP y compañero en el MGTI, Victor Carazo. Sus consejos y la información que ha compartido conmigo no tienen precio.

Acabo repitiendo el mensaje fundamental de esta entrada; si te estás preparando para el PMP no te limites sólo al resultado final, procura disfrutar y aprender al máximo durante todo el proceso.

Ya soy PMP. Valoración, agradecimientos y consejos

Presupuestar la gestión de los riesgos

jmartinmateo, , Leave a comment

Hace unos días asistí a un interesante encuentro de speednetworking junto a otros socios del Capítulo de Barcelona del PMI. El evento estuvo muy bien. Era mi primera experiencia de este tipo y conocí a algunos socios del capítulo con actividades interesantes.

Una de las personas con las que tuve oportunidad de charlar me explicó que en la anterior empresa para la que había trabajado, en el sector de la construcción, no le permitía incorporar en el presupuesto las actividades relacionadas con la gestión de los riesgos. Estaba indignado.

Un riesgo en un proyecto es un evento incierto que puede afectar (positiva o negativamente) al coste, el plazo, el alcance o la calidad.

Según las buenas prácticas del PMBOK, es necesario gestionar los riesgos del proyecto. De forma muy breve; hay que identificarlos, priorizarlos, decidir qué se va a hacer con cada uno de ellos, hacerlo y seguir su evolución a lo largo del proyecto.

Se trata de un proceso iterativo porque las acciones realizadas para mitigar, eliminar, o transferir los riesgos afectan a la gestión del alcance, los costes, los plazos o la calidad del proyecto y, además, pueden dar lugar a nuevos riesgos previamente no identificados.

Gestionar los riesgos tiene costes; costes de gestión, de aplicación de las medidas y planes de contingencia, de control y seguimiento de los riesgos, … El hecho de no incorporar estas actividades en el presupuesto del proyecto, como una supuesta medida para mejorar la competitividad en costes frente a la competencia, creo que sólo puede deberse a que, o bien no se gestionan los riesgos en el proyecto, o bien se identifican y registran pero no se realiza ninguna actividad para mitigarlos o eliminarlos. Simplemente se aceptan.

No sé cual de las dos opciones me parece peor. Si realmente queremos mejorar nuestra competitividad no puede ser en base a gestionar mal. Si ignoramos los riesgos de un proyecto estamos jugando a la lotería; puede que no se materialicen y gano o puede que lo hagan y pierdo.

Ese no es el camino.

Presupuestar la gestión de los riesgos

Aseguramiento de la calidad

jmartinmateo, , Leave a comment

En las últimas dos semanas me he visto involucrado en una nueva actividad, añadida a las que desarrollo habitualmente.  Como responsable de calidad de la empresa debo encargarme del aseguramiento de la calidad en un proyecto dirigido por otros gestores de proyectos.

Se trata de un proyecto complejo, distribuido en varias regiones (de ahí que haya varios gestores) y que se apoya en otras empresas para la ejecución de algunas de las actividades. Para acabarlo de arreglar, nuestro cliente es una empresa extranjera, de reciente implantación en España y con una cultura muy distinta a la nuestra.

Aseguramiento de la calidad vs. control de calidad

En los procesos de control de calidad se utilizan diversas técnicas para medir determinadas variables que permitan conocer si un proceso o un entregable disponen del nivel de calidad requerido.

Por el contrario, el aseguramiento de la calidad se centra en verificar que se siguen los procedimientos internos (y en nuestro caso también del cliente), las normativas legales, etc. que se habrán identificado previamente en el Plan de Calidad del proyecto.

El otro gran objetivo del aseguramiento de la calidad es intentar mejorar los procesos que se estén utilizando.

Herramientas

¿De qué armas disponemos para enfrentarnos con este reto?

  • revisar el Plan de Calidad y utilizar los resultados de las medidas tomadas en los controles de calidad
  • auditorías de calidad (internas y/o externas)
  • análisis de procesos: en el caso de este proyecto hay determinados paquetes de trabajo que se repiten en el tiempo. Las lecciones aprendidas tras la revisión del proceso de ejecución de los primeros paquetes de trabajo nos pueden dar una información muy valiosa.

Resultados

¿Qué resultados esperan obtener mi empresa y el cliente de este proceso de aseguramiento de la calidad?

Calidad asegurada
Sellando la calidad

Básicamente, podríamos decir que los resultados serían solicitudes de cambio, acciones correctivas y preventivas, mejoras y actualizaciones de los procesos, … que deberían derivar en entregables que cubran las necesidades y expectativas de nuestro cliente y, por supuesto,  estén libres de defectos.


Aseguramiento de la calidad

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)