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.
– 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?
La rentabilidad de los proyectos es fundamental para la supervivencia del negocio. Un elemento clave en este sentido es el control de los costes.
En la fase de venta el equipo que luego deberá desarrollar el proyecto debería intervenir ya en las estimaciones, sin embargo en esa fase en muchas ocasiones se carece de una información completa y también del tiempo necesario para desmenuzar el proyecto en tareas suficientemente pequeñas como para ser estimadas con facilidad antes de presentarle la propuesta al cliente.
Por otra parte, después, aunque en muchos casos se trabaje con prácticas ágiles los contratos no suelen serlo. En un contrato FP (Fixed Price) el proveedor asume el riesgo en relación a los costes. ¿Cómo podemos mitigar ese riesgo de la mejor manera posible?
Identificación y análisis de riesgos
Idealmente, el equipo que luego llevará a cabo el proyecto debe realizar las estimaciones pero el project mánager debe supervisar estas estimaciones y detectar posibles riesgos; ya sean debidos a la incertidumbre sobre posibles tareas que se van a hacer por primera vez en ese proyecto, a la inexperiencia de parte del equipo, a la falta de definición por parte del cliente (que a menudo empieza a saber lo que quiere conforme va viendo resultados), etc
Actualización del presupuesto en base a riesgos detectados
No es profesional hacer ‘padding’. Por el contrario, podemos hacer 3 cosas en el presupuesto en base a los riesgos:
1. Actualizar las partidas concretas en las que hemos detectado riesgos, para cubrir los costes de las actividades previstas para mitigarlos o eliminarlos.
2. Incluir una partida (contingecy reserves) para afrontar que se materialicen aquellos riesgos detectados pero que no hayamos podido ver cómo eliminar por completo en el análisis de riesgos realizado.
3. Incluir una partida final (management reserves) para cubrir posibles riesgos no detectados. Si todo va bien, no tendremos que hacer uso de esta partida y de esta forma no inflamos artificialmente partidas del presupuesto ‘por si acaso’.
Control de costes durante el proyecto
Una buena opción es usar la medición del valor ganado (Earned Value Measurement, EVM). Esta metodología permite medir la situación de un proyecto en relación a su alcance, su calendario y sus costes (que son el motivo inicial de este post).
Los resultados del EVM permiten detectar desviaciones, hacer previsiones y solicitar cambios con datos en la mano que los soporten.
¿Cómo controlas los costes en tus proyectos? ¿Has utilizado EVM?
¿Eres capaz de prever cómo acabará tu proyecto? ¿Dispones de datos suficientes para soportar tus previsiones o para fundamentar los cambios necesarios durante la vida de un proyecto?
“A tree as great as a man’s embrace springs from a small shoot; A terrace nine stories high begins with a pile of earth; A journey of a thousand miles starts under one’s feet.”
Lao-Tse – Tao Te Ching
It is a lot easier to face a problem when it is in an early stage than when it has grown too much. So, this shows us one of the most important attributes of a good project manager: proactivity.
A project manager’s work should not focus on dealing with problems, it should focus on preventing them. We must manage the risks of a project, but how can we do it more efficiently? It is not possible to preview everything.
In my opinion, we must be prepared and have:
A system
A system, for instance, like the one explained in the PMBoK. It is necessary plan to manage risks, to identify them not only in the beginning of a project but during the project too, analyze the identified risks and develop responses. And repeat this process periodically during the life of the project.
Team support
The whole team must participate in the process of identifying risks and planning responses. They are able to help us identify possible problems that the project manager couldn’t imagine.
Communication
That takes me to the third point: good and fluent communication with the team, the client (and/or the Product Owner).
The Project Manager also must contribute to create an environment of confidence amongst the project team so that ideas, problems, risks, solutions, … flow in the team.
Everybody should feel that they can share their thoughts freely and all the important information should flow easily so that the ones who must use it to make decisions have it when they need it.
Tools
And that brings me to the final point: the tools.
We need tools to support communication, plans, assessments, … I have included them in the end because I think they are necessary but they don’t make the system. They make our life easier but they are useless if we do not have a plan and processes to systematically manage risks and we have not created an environment with the team where they feel free and motivated to communicate.
What do you think is more important? What kind of processes do you use in your projects to manage risks? Does the team always help proactively?
Please, share your comments.
Los directores de proyectos con cierta experiencia tarde o temprano se habrán encontrado con un proyecto complejo o que, simplemente, se ha complicado y está resultando mucho más caro de lo previsto. Es posible que incluso antes de haber logrado desarrollar la mitad del alcance el proyecto ya haya superado el presupuesto para el total del mismo. ¿Qué hacer entonces? ¿Debemos continuar o es mejor para ahora? Al fin y al cabo la inversión realizada ya es importante…
La falacia de los costes hundidos
Para tomar la decisión sobre si continuar con el proyecto o cerrarlo tal y como está no debemos tener en cuenta lo ya gastado en el proyecto. Eso ya está gastado y no se va a recuperar, por mucho que emocionalmente nos duela.
Se trata de costes hundidos (sunked costs) .
Lo ya gastado en el proyecto es irrecuperable, sea cual sea nuestra decisión. Lo que debemos valorar es la inversión que sería necesaria en este momento para acabar el proyecto y decidir si vale la pena realizarla y si es la mejor inversión que podemos hacer (coste de oportunidad).
En base a esas premisas podemos tomar una decisión racional.
Las emociones juegan en contra
¿Por qué nos cuesta tanto entonces dejar de lado proyectos que van mal?
Uno de los motivos es que no nos gusta perder. Tenemos aversión a las pérdidas. Reconocer que hemos tirado a la basura tiempo, dinero y recursos es duro.
Otro motivo es nuestro compromiso con nuestro trabajo. Una vez que empezamos algo intentamos acabarlo a toda costa. Dejarlo a medias es visto por algunos de nosotros como un fracaso y como un incumplimiento de nuestras obligaciones con el cliente y con nuestra organización.
Tener que sentarnos ante un cliente con el que hemos negociado la realización de un proyecto por un precio fijo que hemos estimado mal es duro. Continuar con el proyecto en esas condiciones no es bueno ni para proveedor ni para cliente. Es necesario asumir la responsabilidad y afrontar la situación para evitar males mayores.
¿Qué opinas? ¿Tienes experiencia en este tipo de situaciones? ¿Cómo las has abordado?
There are many situations when creating a prototype of the final product of a project is not possible, because of the costs, the timing or just because of the nature of the product. But if you have the chance I recommend you to do it.
Prototyping in software projects
Currently I manage projects whose goal is the creation of mobile apps for different kinds of clients. The product of our projects is a software and software by its nature allows prototyping and progressive development.
There are different kinds of prototype solutions for mobile apps. Frequently we use Marvel and Flinto. They both allow to create very high fidelity prototypes that can be tested in the intended devices as if they were the real app.
Why is this so interesting inside the project of creation of an app?
1. It is very frequent that the client (and/or the product owner) doesn’t know exactly how the final product should look like, exactly what kind of functionalities should it include and how should they be presented to the app user.
The prototype allows the client to rethink the product if necessary as the result of its interaction with the prototype.
2. It is a lot cheaper and faster to introduce changes in a prototype of this kind than in the final app (product).
3. Design is fundamental in a mobile app. This allows designers to go always at least 1 sprint ahead of developers during the project. If you can create a first project just for prototyping it will be even better.
4. As the designs are realistic, all the assets created for the prototype and approved by the client can be used by the developers during the following phases of the project without any additional work from the designers.
What is your opinion?
What do you think? Do you prototype in your projects? What kind of tools do you use? Do you know any more reasons in favor of prototyping? And against?
I would like to know your comments.
Una vez realizado el diagnóstico de la situación, después de haber logrado el compromiso efectivo de la dirección y tras haber llevado a cabo una buena planificación debemos pasar a la acción. En mi opinión hay 4 ingredientes imprescindibles es esta segunda fase: información a todo el personal de la organización, formación en gestión de la calidad adaptada a las necesidades de cada grupo de empleados, desarrollo de la documentación del sistema e implantación de los diferentes procesos de la empresa en base a la documentación desarrollada. Vamos a ver cada uno de estos 4 puntos con más detalle.
Información
En cualquier proyecto, un Director de Proyectos pasa la mayor parte de su tiempo gestionando las comunicaciones del proyecto. En un proyecto de implantación de un SGC ésto también es así. En esta fase es fundamental informar a todos los miembros de la organización de:
lo que se pretende conseguir,
el nivel de implicación que se espera de ellos,
cómo les va afectar el proyecto.
La información proporcionada debe ser adaptada al puesto de cada persona en la organización y debe mostrar el compromiso de la organización con el proyecto.
Comunicación con todos los interesados en el proyecto
La formación debe tener como objeto sensibilizar sobre la calidad en el trabajo y mejorar la comprensión del sistema de gestión, para que todos los afectados puedan comprender los cambios que se van a producir y actuar de forma favorable (o al menos no contraria) a los mismos.
Al igual que la información, la formación deberá adaptarse al puesto y responsabilidades de cada miembro de la organización. Su contenido y duración dependerán del tamaño de la organización pero también de su nivel de madurez en relación a la calidad.
Documentación
Una de las bases de la calidad es la estandarización. Una herramienta fundamental para la estandarización es la documentación, que un vehículo para lograr que las tareas se realicen siempre de la misma forma.
La documentación debe ser redactada en la forma más simple y comprensible, debe describir la forma correcta la forma de realizar las tareas, debe incorporar todo el conocimiento acumulado de la organización, informando de responsabilidades y relacionando unos procesos con otros.
Conforme se vayan redactando procedimientos (que son los documentos que describen los diferentes procesos de la organización) es bueno empezar con su implantación. No obstante, es importante remarcar que lograr la implantación requiere de mucho más tiempo que el de la simple redacción de los procedimientos, especialmente si se parte de un bajo nivel de madurez en relación a la calidad en la organización.
Implantación
Conforme se finaliza la redacción de los documentos y se arranca su puesta en marcha es preciso realizar una serie de actividades con objeto de fijar los nuevos procesos y cambios introducidos:
empezar a realizar las tareas cotidianas según se describe en los procedimientos e instrucciones,
realizar un seguimiento y verificar de forma distendida el nivel de aplicación,
corregir los procedimientos en base al feedback obtenido en el seguimiento.
¿Qué opinas de este modelo de diseño? ¿qué elementos utilizáis en tu organización?¿consideras que hay algún ingrediente importante que falte?
Ya he hablado en este blog sobre la metodología y los principios a seguir en un proceso de implantación de un Sistema de Gestión de la Calidad (SGC) según ISO 9001.
Ahora me gustaría tratar con algo más de detalle las fases a seguir en un proyecto de este tipo. En concreto, me voy a centrar en la fase de Planificación (la P del ciclo PDCA).
Bajo mi punto de vista, los hitos más relevantes son:
1. Diagnóstico de la situación.
2. Obtención del compromiso de la Dirección con la implantación. Definición de la política de la calidad
3. Elaboración de un plan de actuación para la implantación y la certificación.
Vamos a verlos ahora con más detalle.
Diagnóstico
En esta fase es conveniente revisar la forma como se está (o no se está) gestionando actualmente la calidad en la organización.
Cuando actuamos como consultores externos, es importante dedicarle el tiempo necesario a esta fase. Se trata de comprender lo mejor posible la forma como actualmente está trabajando la organización. Hay que preguntar mucho y escuchar de forma activa, hacer participar al máximo de personas que vayan a estar afectadas por el proyecto y ser muy empático.
En esta fase, y de acuerdo con la Dirección, podremos definir el alcance más adecuado para el sistema, el tiempo que se le va a dedicar y los recursos necesarios.
Pero también, mediante el diálogo con todos los implicados, deberemos ser capaces de detectar posibles elementos de resistencia al cambio y también posibles riesgos que puedan dificultar la consecución de los objetivos del proyecto. Como consecuencia, uno de los resultados de esta fase será un listado de alto nivel de los riesgos del proyecto junto con posibles acciones a realizar en relación a ellos.
Compromiso de la Dirección
Para empezar, se debe obtener un compromiso formal de la Dirección en relación a la implantación. Ésto es básico y si no se logra es razón suficiente para no continuar con el proyecto. Uno de los primeros entregables debe ser la definición junto a la Dirección de una Política de Calidad.
También es necesario hacer un análisis de las necesidades de los clientes, establecer métodos para medir su nivel de satisfacción y planear cómo se va evaluar a proveedores (si no se estaba haciendo ya) y analizar cómo se tratan las incidencias y/o reclamaciones de los clientes.
Acabaremos esta fase fijando los objetivos de la calidad, de acuerdo con la Dirección y con los implicados en conseguirlos.
La implantación de un sistema de gestión de la calidad debe enfocarse como un proyecto. Debe tener un alcance definido, un presupuesto y un calendario.
Al igual que es fundamental obtener el compromiso de la Dirección, también es básico designar un responsable de dirigir este proyecto. Es conveniente que sea una persona de dentro de la organización, que sea buen conocedor de su cultura y de su estructura.
También es importante que este persona tenga un perfil que le permita liderar el proyecto y ser capaz de comunicarlo adecuadamente dentro de la organización. De hecho, probablemente la actividad a la que tenga que dedicar más tiempo dentro del proyecto sea la comunicación.
Es posible que internamente dispongamos de personas con este perfil pero que no tengan conocimientos sobre gestión de la calidad. Eso no es invalidante, bajo mi punto de vista. En caso de encontrarnos en esta situación será conveniente formar adecuadamente a la persona escogida y ayudarla con un consultor externo que aporte el conocimiento sobre la gestión de la calidad y la experiencia en su aplicación en otras organizaciones.
Doy por supuesto que la persona escogida está completamente comprometida con el proyecto y dispuesta a asumir el rol de agente de cambio en la organización, en complicidad con el consultor externo. Bajo mi punto de vista, tan importante es la aptitud como la actitud.
¿Qué opináis sobre la fase de planificación? ¿Cuál es vuestra experiencia al abordar este tipo de proyectos en vuestras organizaciones?
La Guía del PMBOK®, es un conjunto de buenas prácticas internacionalmente reconocido para la dirección y gestión de proyectos. La quinta edición se ha convertido en un estándar reconocido por ANSI (y publicado como anexo en la propia guía).
Elaboración conjunta PMI-IEEE
La “Extensión de Software de La Guía del PMBOK®” ha sido elaborada conjuntamente por el PMI y por la IEEE Computer Society. Se basa en 5ª edición de La Guía del PMBOK®, manteniendo su estructura, procesos y coherencia en el discurso pero incorpora elementos propios de los proyectos de desarrollo de software para adaptarse a sus características específicas como los métodos de desarrollo adaptativo, que permiten aprovecharse de la naturaleza específica del producto de estos proyectos: las aplicaciones. En general, se trata de productos que permiten la fácil y rápida elaboración de prototipos y el desarrollo incremental.
Público objetivo: todo el involucrado en proyectos de TI
Esta “Extensión” está escrita pensando en organizaciones y equipos que se enfrentan tanto a proyectos de desarrollo como de modificación o de implantación de software y cubre tanto proyectos llevados a cabo internamente como la gestión de proyectos externalizados.
Dado que hay aspectos que no varían en un proyecto de software respecto de uno cuyo producto sea distinto, en todos los apartados en los que no hay especificidades en un proyecto de software se deriva al lector al punto concreto de “La Guía del PMBOK®”.
Por el contrario, cuando hay técnicas o situaciones concretas y específicas de los proyectos de software éstas se mencionan o referencian en la propia “Extensión”. Como ejemplo, uno de mis intereses personales es la Calidad en los Proyectos. En el capítulo 8 del libro se trata este tema y se hace referencia a técnicas de SQA (Software Quality Assurance) y SQC (Software Quality Control) junto con estándares del IEEE aplicables a cada caso, como el IEEE Standard 829 (Software and System Test Documentation) o el IEEE 1008 (Unit Testing).
Habrá que ampliar la librería … (Fotografía de neoprolog bajo licencia CC BY 2.0)
¿Consideráis útil esta aproximación del PMI frente a los entornos ágiles alternativos?
¿Habéis tenido oportunidad de leer el libro? ¿Qué opináis? ¿Consideráis útil y acertada su publicación o bien pensáis que no tiene sentido adaptar “La Guía del PMBOK®” a proyectos de software disponiendo de entornos ágiles como Scrum o Kanban?
Hace unos días asistí a la presentación de una herramienta de gestión de riesgos, aplicable a la gestión de proyectos pero también a otros ámbitos.
La herramienta, a partir de las estimaciones realizadas por el director de proyecto y su equipo de colaboradores, realiza un elevado número de simulaciones (configurable) siguiendo el método de Montecarlo.
Qué es la simulación de Montecarlo
La simulación de Montecarlo consiste en crear un modelo matemático del sistema a analizar, identificando aquellas entradas o variables del modelo cuyo comportamiento aleatorio determina el comportamiento global del sistema.
Una vez identificadas las mencionadas variables aleatorias, se procede a generar –mediante una aplicación informática- muestras aleatorias (valores específicos) para estas variables y a analizar el comportamiento del sistema ante los resultados generados.
Repitiendo n veces este proceso, se obtienen n resultados sobre el comportamiento del sistema, permitiéndonos entender mejor el funcionamiento del mismo. A mayor número (n) de experimentos realizados, lógicamente, obtendremos más precisión en el análisis.
El Casino de Montecarlo dio nombre a la simulación
Cómo se aplica la simulación en la dirección de un proyecto
En nuestro caso, las variables de entrada al sistema serían, por ejemplo, las variaciones en el coste o en la duración de las actividades del proyecto en función de que se materialicen o no determinados riesgos. Como resultado, la aplicación proporciona, entre otros datos, una gráfica con las probabilidades de acabar el proyecto en determinada fecha o con un determinado coste.
Actualmente la tecnología nos puede ayudar mucho y, especialmente en proyectos de elevado coste y/o en los que no acabar en plazo pueda causar peligro para equipamientos o vidas humanas, este tipo de herramientas puede ser de gran ayuda.
El factor humano
Sin embargo, mi reflexión viene motivada porque toda la información de partida que utiliza la herramienta debe ser proporcionada por personas; la probabilidad y la estimación de impacto de que se materialice un determinado riesgo, la identificación exhaustiva de los riesgos que pueden afectar al proyecto, los criterios para definir la matriz de probabilidades e impactos … Si todo ésto no es acertado, todos los cálculos que muy afinadamente realicen las máquinas en base a esta información serán erróneos.
La experiencia del Director del Proyecto y de su equipo, su formación, la posibilidad de tener un equipo de proyectos multidisciplinar, que sea capaz de tener en cuenta todas las afectaciones e implicaciones del mismo, la posibilidad de disponer de una buena base corporativa de lecciones aprendidas de otros proyectos, el conocimiento de la organización en la que se desarrolla el proyecto y de su grado de aversión al riesgo…
¿Qué otros factores humanos consideras que pueden afectar a la gestión de riesgos de un proyecto? ¿utilizáis aplicaciones en vuestras organizaciones que os ayuden en este proceso?
—— ENGLISH VERSION —————
Some days ago I attended a presentation of a risk management tool, applicable to project management but also to other environments.
The tool performs a big number (configurable) of simulations based on the estimations made by the project manager and its team, according to the Montecarlo method.
What is Montecarlo simulation?
Montecarlo simulation consists on the creation of a mathematical model of the system to be analyzed and the identification of the inputs or variables whose random behavior determines the behavior of the whole system.
After that, random samples (specific values) are generated using an application. Those samples are used as inputs of the system and the outputs are used to analyze its global behavior.
Repeating n times this same process it is posible to obtain n results that allow to understand better the way it works. The bigger the number of samples the more precision in the analysis.
In our environment, the input variables would be, for instance, the variances in cost or in the duration of project activities depending on some risks that might finally materialize or not. As a result, the application provides some graphics with the probabilities to finish a project in a specific date or with a specific cost.
Nowadays technology can help us a lot, specially in projects of high cost and / or in those projects where not finishing on time may risk infrastructures or even human lifes. In these situations these kind of tools can be very helpful.
The human factor
But the reason that has motivated me to write this post is the thinking that all the information needed by the tool must be previously provided by humans; the probability and the estimation of the impact in the case that an specific risk may finally happen, the exhaustive identification of the risks that may affect to a project, the criteria to define the probabilities and impacts matrix … If there are important mistakes or gaps in this data the later calculations made by the machines will be wrong.
The experience of the project manager and its team, their training, the chance to have a multidisciplinary project team, capable to have in mind all the potential risks and the ways they would affect the whole project, the possibility to have a good base of lessons learned available for the whole organization, the knowledge of the organization that is developing the project and its risk aversion, …
What other factors do you think that may affect a proper risk management in a project? Do you use applications in your organizations that support you in this process?
¿Qué hacer si durante la fase de ejecución y seguimiento/control nos encontramos con que no hemos identificado a un interesado (stakeholder) en nuestro proyecto que, además, resulta que tiene mucho interés y/o influencia en el mismo?
La gestión de interesados es un proceso vivo durante todo el proyecto
La gestión de los interesados es, en cierto modo, como la gestión de los riesgos en nuestro proyecto; no debemos darla nunca por cerrada y hay que revisarla sistemáticamente. Periódicamente es necesario revisar el registro de interesados, el análisis de cada interesado y la estrategia utilizada con él, para introducir los cambios que sean necesarios.
Inclusión de nuevos interesados durante el proyecto
El inicio del proyecto es la fase en que menos información disponemos. Si, como planteaba la pregunta inicial, nos hemos olvidado o no conocíamos a alguien importante deberemos:
1. Añadirlo al registro de interesados.
2. Evaluar su poder dentro de la organización y su posible interés en relación al proyecto.
3. Analizar cómo puede haber afectado al proyecto su no inclusión hasta la fecha en el grupo de interesados.
4. Definir una estrategia para gestionar nuestra relación con él, partiendo del reconocimiento de que no hemos empezado con buen pie.
5. Efectuar las correcciones necesarias en nuestro Plan de Proyecto, de acuerdo con el sistema de gestión de cambios que hayamos definido, para tener en cuenta a este nuevo interesado. Ésto es especialmente importante si su nivel de influencia en el proyecto es alto.
Técnicas de identificación de interesados
Para evitar que un interesado, especialmente uno importante, se quede fuera de nuestra estrategia de comunicación del proyecto hay algunas herramientas que podemos usar:
– Nominación de interesados: a partir de una lista inicial podemos pedir a cada uno de los interesados ya identificados que nos proponga nuevos interesados en el proyecto. Es recomendable empezar por el sponsor del proyecto y continuar luego con los interesados más influyentes.
– Investigación de base: se trata de estudiar toda la documentación existente en relación a nuestro proyecto y localizar en la organización documentación análoga de proyectos similares. A partir de aquí se toma nota de todos los interesados que aparezcan en dicha documentación, para evaluar si también pueden estar involucrados en nuestro proyecto.
Esta técnica es especialmente interesante si somos directores de proyecto trabajando en una organización nueva para nosotros o que desconocemos.
– Rueda de interesados: La rueda interesados es una especie de lista de control en la que se han identificado todos los principales grupos de interesados. Se usa para comprobar la lista de grupos de interés frente a grupos de interés genéricos, con objeto de identificar los que falten.
Es bueno actualizar la documentación del proyecto (lecciones aprendidas) con nuevos grupos o roles que se hayan identificado, para que pueda ser aprovechada en futuros proyectos.
Resumen final
La no inclusión de un interesado importante dentro del Plan de Proyecto puede ser catastrófica. Para evitarlo, utiliza las tres técnicas mencionadas de identificación de interesados y revisa sistemáticamente tu registro de interesados del proyecto y tu estrategia frente a cada uno de ellos.
¿Qué otras técnicas conoces para identificar interesados? Compártelas mediante un comentario a esta entrada para que todos nos beneficiemos de su uso.
Technology at the service of humans 