descarga la versión pdf de este artículo
Y por último presentamos el gran olvidado en la gestión de proyectos: La satisfacción. Los factores clave para habilitar canales de evaluación de la satisfacción son:
La satisfacción es tan importante como el proceso mismo de creación que protagoniza cualquier proyecto. Hay que establecer canales de comunicación durante y después del proyecto para evaluar la satisfacción. Canales de comunicación dentro de los flujos de gobierno del proyecto pueden ser:
Aparte de estos canales se debe hacer un fomento activo y constante de la transparencia. Y hay que habilitar los canales de comunicación bidireccionales adecuados que permitan, por un lado al equipo del proyecto explicar la situación de las acciones y los resultados; y por otro lado obtener información sobre la satisfacción
A menudo entendemos la satisfacción como la complacencia de la organización con el resultado del proyecto y, en última instancia, la satisfacción del usuario en la explotación del producto. Pero la satisfacción es más que eso y afecta equipos y personas de todos los ámbitos. Tan importante como evaluar la satisfacción del destinatario del producto, es evaluar la satisfacción de todos los participantes en el proyecto. Esto incluye a los constructores, desarrolladores y proveedores que han intervenido. De esta forma podemos tener dimensiones en cuanto a la evaluación de la satisfacción respecto al proceso de ejecución del proyecto, la coordinación de las personas, y la relación con equipos y personas externas que colaboran.
La satisfacción también involucra a:
La satisfacción está directamente relacionada con la gestión de los riesgos del proyecto y de los conflictos o incidencias que se generen a lo largo de éste y posteriormente. Esta responsabilidad recae directamente sobre el equipo del proyecto. Del éxito en el tratamiento de estos riesgos y problemas dependerá en gran parte la satisfacción.
Un proyecto sencillo con muy pocas incidencias, gestionadas de forma inapropiada probablemente al final tenga una sensación de satisfacción superior que el caso de un proyecto complejo con incidencias gestionadas de forma muy eficiente. La sensación de satisfacción es un concepto subjetivo, que requiere complementos objetivos, tales como el número de incidencias y el porcentaje de resolución eficiente, los SLA, el grado de complejidad del proyecto, etc.
Una vez finalizado el proyecto, la gestión de los incidentes y problemas recae sobre varios actores, principalmente los equipos de apoyo al usuario y los equipos de mantenimiento del producto. La comunicación entre ambos equipos es vital para la eficiencia del proceso de apoyo al usuario. Y como objetivo principal del proceso, la comunicación al usuario sobre la situación de la acción de apoyo es vital para la satisfacción de este
Un elemento clave en la evaluación continua de la satisfacción, hace énfasis en la gestión eficiente y en tiempo real de los riesgos y los problemas. El equipo trabaja de forma constante en alcanzar los objetivos del proyecto, teniendo como foco principal la situación de los riesgos; y reacciona ante los problemas tan pronto como aparecen. Si hay un elemento que tiene una incidencia directa sobre la percepción de la satisfacción, es la gestión ordenada y eficiente de los riesgos, y de cómo se comunican.
PRINCE2 define el riesgo como: “Un riesgo es un evento que, en caso de producirse, tendrá un efecto en la consecución de uno o más objetivos del proyecto”. PMBOK define el riesgo como: “Un evento o condición incierta, que, si se produce, tiene un efecto positivo o negativo sobre el objetivo de un proyecto.” SCRUM define el riesgo como: “Un evento incierto o conjunto de eventos que puedan afectar a los objetivos de un proyecto y puedan contribuir a su éxito o fracaso.”
Un riesgo puede ser positivo o negativo para el proyecto. Un riesgo positivo es una oportunidad, y hay que procurar que se produzca si se tienen los factores adecuados para provocar su aparición. Un riesgo negativo es una amenaza para el proyecto. Requiere trabajo del equipo para definir un plan que la mitigue o la anule.
Un riesgo es un elemento incierto, es decir:
Un riesgo es tal que, en caso de producirse, tiene una afectación sobre uno o más objetivos del proyecto. La alteración de objetivos del proyecto pone en peligro el alcance del mismo, e incluso, si la afectación es grave, su conveniencia. Para que el equipo del proyecto pueda distinguir entre el grado de impacto de un riesgo, este debe estar catalogado:
La severidad de un riesgo es un baremo que ayuda al equipo del proyecto a determinar sobre qué riesgos detectados hay que estar más atento. La severidad corresponde a:
Severidad = probabilidad * impacto
Por ejemplo, un riesgo con probabilidad alta e impacto bloqueando, tiene una severidad de 12 en la escala que hemos mostrado anteriormente. El equipo puede entender que riesgos con mayor severidad de 6 (probabilidad o impacto altos) requieren una atención especial durante toda la ejecución del proyecto, y probablemente la definición de un plan de mitigación muy cuidadoso.
Un problema es un incidente, generalmente sorpresivo, que tiene un impacto inmediato sobre algún aspecto del proyecto o del equipo, pero no tiene por qué afectar a los objetivos del proyecto, aunque altera el normal funcionamiento de la ejecución o del equipo.
Algunos problemas, al aparecer pueden transformarse en riesgos del proyecto. Y algunos riesgos, o exactamente los planes de mitigación de estos riesgos, pueden generar problemas en el proyecto. Algunos ejemplos de riesgos y problemas pueden ser:
| Riesgo | Problema |
|---|---|
| Un miembro crítico del equipo podría dejar el proyecto antes de su finalización | Un miembro del equipo ha comunicado que abandona el proyecto a corto plazo |
| Pueden aparecer nuevos requerimientos que afectarían el alcance del proyecto | Ha aparecido una nueva funcionalidad que hay que añadir al alcance del proyecto |
| Podría producirse un cambio tecnológico a medio plazo que obligue al rediseño de algunas interfaces | En el rediseño de algunas interfaces del usuario se han comunicado problemas de compatibilidad con algunos modelos de hardware |
La identificación de riesgos de un proyecto es una responsabilidad del equipo del proyecto y de todos los interesados. Esta acción se lleva a cabo en cada momento. Nunca es mal momento para detectar un riesgo, comunicarse y trabajar en su mitigación. Si bien es cierto que la definición del grueso de los riesgos suele realizar al inicio del proyecto, y al inicio de cada iteración prevista.
La monitorización de un riesgo contempla varias etapas en las que se realiza un análisis periódico de su situación y, en caso de identificar que el riesgo se ha producido o se está produciendo, pasa a gestionarse la ejecución del plan de mitigación correspondiente.
Como hemos dicho antes, el seguimiento de los riesgos no debe ser sólo una tarea periódica, sino que se evalúa cada riesgo en función de información o eventos que potencialmente pueden alterar la situación de uno o varios riesgos. La reacción ante ello debería ser inmediata, e involucra a todo el equipo del proyecto.
Durante el curso del proyecto es posible detectar que un riesgo definitivamente no se producirá. El equipo del proyecto puede entonces descartarlo para centrar su atención sobre el resto de riesgos.
En cualquier momento se puede determinar que un riesgo efectivamente se está produciendo. Es el momento de activar el plan de mitigación que hemos ideado para el riesgo. Una información importante en el plan de mitigación corresponde a la identificación de los responsables del plan. Los que, aprovechando las sesiones de seguimiento, o bien en reuniones específicas, informarán al equipo sobre el curso de del plan de mitigación, y de si este consigue mitigar el riesgo, y en qué grado lo hace.
El plan de mitigación puede terminar con la resolución definitiva del riesgo. Al igual que en la acción de descartar, el equipo del proyecto archivará el riesgo para centrar la atención en los riesgos activos
El cierre de un riesgo es más bien un archivo. Se explica la situación del riesgo a fecha del cierre. El resultado del plan de mitigación en caso de haberse llevado a cabo, y cualquier información que el equipo encuentre útil, como por ejemplo lecciones aprendidas respecto al riesgo y sus impactos.
De todas formas, tener metas en la ejecución del proyecto en el que se hace un seguimiento de los riesgos siempre es buena idea. En el flujo de hitos del proyecto que hemos visto anteriormente, el hito de Reunión de planificación del ciclo es un buen momento para explorar la situación de los riesgos
Por otra parte las Reuniones de resultados y aceptación y, en especial, las Reuniones de seguimiento, son buenos momentos para exponer la situación de los riesgos, por lo que tendremos que haber hecho un trabajo previo de exploración
La revisión continua de los riesgos debe contemplar:
Los canales de comunicación son una buena herramienta para establecer un contacto constante con todos los interesados en el proyecto. Son la mejor forma para evitar el aislamiento. Pueden ser una línea de teléfono, una dirección de correo, o una persona concreta. Sean los que sean, son estos y no otros. Los canales de comunicación establecidos en el proyecte deben ser conocidos por todas las partes, y se han de fomentar a lo largo del proyecto para que se utilicen de forma adecuada y proporcionada.
Los canales de comunicación deben servir para establecer un contacto continuado y cercano con todos los interesados del proyecto, tomar el pulso de las personas y los equipos con el producto del proyecto, recibir posibles alarmas y problemas de forma temprana, y comunicar cuestiones relevantes de forma segura. Pero no son la vía para tomar decisiones. Las decisiones las toma el equipo, y no los canales.
Como parte del proyecto, el equipo, y en especial el jefe de proyecto, debe proporcionar canales por los que cualquier interesado pueda dirigirse para tratar una cuestión importante. Un aspecto que a menudo genera tensión entre las personas del proyecto, es la imposibilidad de aclarar una duda de forma ágil. La duda acaba convirtiéndose en problema si no somos capaces de dar un soporte de forma temprana.
Los canales de comunicación deben ser bidireccionales. Por un lado el equipo de proyecto necesita comunicar los avances y las decisiones a todas las partes afectadas y participantes. Y por otro lado el equipo de proyecto necesita recibir feedback que le aportará mucho valor a la hora de tomar decisiones o llevar a cabo ciertas acciones.
Esto no quiere decir que una persona pueda interrumpir a un miembro del equipo en cualquier momento. Hay tiempo para todo. Las reuniones y sesiones previstas en el proyecto, son un buen momento para tener feedback mutuo. La habilitación de ciertos canales de comunicación fuera de estas sesiones, y con ciertas personas son otra herramienta útil. El mismo jefe de proyecto y los facilitadores son las personas más adecuadas para canalizar estas comunicaciones.
Durante el proyecto se llevan a cabo multitud de reuniones, con objetivos diferentes. Todas ellas son un buen momento para captar o bien interrogar sobre el nivel de satisfacción general de todas las partes. Evaluar la satisfacción en estos momentos nos permite tomar el pulso sobre el estado anímico general de las personas que participan en el proyecto. Y nos permite poner foco a resolver conflictos cuando estos aún están bajo control.
La reunión de cierre de proyecto es el punto donde habitualmente figura la evaluación de la satisfacción como orden del día en la reunión. Previamente se ha hecho un trabajo conjunto para evaluar cuantitativa y cualitativamente los ítems sobre los que se realizará una evaluación de la satisfacción. Es importante que la acción de evaluar la satisfacción no sea única y exclusivamente una acción subjetiva y/u opinativa; sino que esté soportada por un catálogo de acciones o momentos del proyecto concretos que se someten a evaluación.
En este sentido, el mantenimiento de un archivo diario del proyecto (ARD) es una buena estrategia para visualizar adecuadamente:
También es un buen material de cara a la evaluación de la satisfacción el contraste entre el alcance inicialmente establecido al inicio del proyecto, y el resultado final, y de cómo este resultado cumple o no con este alcance.
