5 pasos para gestionar un proyecto de una licitación o RFP.

Cuando nos enfrentamos a una licitación o RFP (Request for Proposals) con costes y tiempo limitados, lo que se conoce como un proyecto cerrado, existe siempre la controversia de si la metodología Agile encaja o no en este tipo de proyectos.

Independientemente de que venga con un listado de funcionalidades cerradas, seguiremos encontrando mucha incertidumbre y deberemos trabajar el producto cuestionando si el listado de funcionalidades original es lo que necesitará el usuario final realmente.

En esta guía vamos a contar cómo gestionar correctamente la elaboración de estos proyectos con nuestra fórmula Polaris, siendo extremadamente ágiles y adaptativos para obtener un resultado que cumpla con las necesidades del cliente y del negocio.

Los 5 pasos a seguir

Cuando se realiza la lectura de la licitación o RFP seguramente nos encontramos con numerosas ambigüedades que pongan en riesgo las expectativas del producto que se va a realizar.

Siguiendo estos 5 pasos podremos elaborar un producto mínimo viable (MVP) que cumpla las expectativas citadas en la licitación, sin perder de vista la adaptabilidad, sostenibilidad y continuidad del ratio del valor incremental, aspecto muy importante que nos garantizará el control de la deuda técnica de forma constante.

1 Acuerdos de equipo y WIKI del proyecto

Antes de comenzar a elaborar el proyecto, se debe concretar quién es quién, fijar las responsabilidades de cada miembro y cómo se va a interactuar entre los diferentes componentes del equipo.

Los acuerdos de equipo más comunes son:

• Duración de cada Sprint.
• Fijar las fechas, horas y duración de las ceremonias (Daily, Planning, Refinamiento, Review y Retrospectiva).
• Software para la gestión del producto, como por ejemplo Jira, Confluence, etc.
• Creación de los tableros, dependiendo de los tracks de trabajo.
• Tipificación de las tareas y cómo iterar con ellas sobre los tableros.
• Definir las herramientas de comunicación.
• Determinar el resto de acuerdos, como la puntualidad, las reuniones presenciales, la comunicación...

A lo largo del proyecto es posible que aparezcan nuevos escenarios que deban adaptarse a estos acuerdos, por lo que es recomendable tenerlos siempre a mano en una herramienta como Confluence para poderlos actualizar y la coordinación sea absoluta.

Por otro lado, en este tipo de proyectos en el que también se va a realizar una función de descubrimiento es necesario tener una wiki del proyecto debidamente documentada, para tener localizable la gestión del cambio, entre otros aspectos importantes.

Recomendamos que esta documentación se aloje en la misma plataforma donde se gestionan los tableros y el backlog, para crear relaciones cruzadas.

Esta wiki debe tener fácilmente accesible al menos:

• Un calendario de sprints.
• Una tabla de los componentes del equipo y stakeholders con sus datos (email, teléfono, cargo).
• Una tabla con los datos necesarios para acceder a los diferentes entornos (PRE-producción y PRO).
• Un repositorio de las actas de reunión y de las ceremonias Review, Planning y Retrospectiva, esta última con los correspondientes planes de acción de mejora continua. ¡OJO! Estas actas deben ser un breve resumen con los acuerdos alcanzados para compartirlo entre todos de manera fácil.
• Un espacio de documentación del track de UX-UI, con acceso a la guía de estilo y a la de uso correcto de los componentes que se han diseñado.
• Otro espacio de documentación del track de Desarrollo, con acceso a los modelos de datos, de arquitectura, etc…
• Un onboarding del proyecto para nuevas incorporaciones.

2 Definir el alcance funcional con fecha fin del proyecto

Hasta aquí todo nos resultará familiar, pero este segundo paso es de crucial importancia para garantizar una primera versión del producto con el que los usuarios finales puedan interactuar y, en consecuencia, ofrecernos un valioso feedback con el que seguir evolucionando el producto adecuadamente.

En estos casos, el inicio del Sprint 0 debe basarse en todo momento en el cumplimiento de las funcionalidades citadas en la licitación o RFP y reflejarse posteriormente en un documento funcional que mitigue todas las ambigüedades y sirva para elaborar un documento de alcance de proyecto cerrado que validaremos con el cliente.

Después, tendremos que trasladar todas las funcionalidades, definidas en el documento funcional, a un backlog con el formato de historias de usuario (HU), con una definición suficiente para comenzar a trabajar en el refinamiento de las mismas y su desarrollo sprint tras sprint.

Hecho este último punto, ahora sí, tendremos un punto de partida con el que trabajar de forma iterativa-incremental el backlog, por ejemplo, con un dual track (track de descubrimiento y track de implementación) para que el track de descubrimiento pueda realizar su magia en base, no solo a diseñar las funcionalidades citadas en el alcance del proyecto cerrado, sino también a realizar propuestas estratégicas de mejora basadas en dinámicas de co-creación y conceptualización (Continuous Discovery), sin olvidar lo detectado en las sesiones de refinamiento y en el feedback del cliente después de cada entregable.

Estas nuevas funcionalidades descubiertas y validadas con el cliente deben ir correctamente tipificadas en el backlog para realizar una buena gestión del cambio y no incurrir en desvíos del proyecto.

Como veremos más adelante, durante las sesiones de Refinamiento se priorizarán las nuevas funcionalidades con respecto a las definidas en el alcance del proyecto y que en esfuerzo sean similares. Lo más importante de todo este proceso es entender bien qué es lo que necesita de verdad el producto.

3 Ceremonias

No vamos a entrar en el detalle de cómo gestionar las ceremonias tipo Daily, Planning, Review y Retrospectiva, pero si en simplificar los tiempos para hacerlas más efectivas.

La clave está en los refinamientos: es necesario realizar al menos una sesión de Refinamiento a la semana, de una hora de duración, junto al equipo de desarrollo y el Product Owner, de esta manera tendremos siempre una planificación clara a dos Sprints vista y permitirá una mejor priorización de las HU y de las entregas de producto que vayamos a realizar en los próximos sprints review.

4 Sistema de métricas de control

Tener todo un sistema de métricas en un solo dashboard (Data Studio, Jira, Azure DevOps) favorece reflejar de un vistazo el estado del proyecto en tiempo real.

Plasmar el estado del Sprint Backlog, roadmap del producto basado en el avance de releases, product burndown, salud del proyecto, del equipo y estado de los riesgos, es muy representativo para que tanto los componentes del equipo como los stakeholders tengan visibilidad y transparencia de la situación del proyecto.

Las métricas que no aporten ¡elimínalas! y si quieres dar profundidad a la lectura de tus métricas ¡adelante! Lo más importante es que todas las personas lo entiendan y una buena práctica es repasar este dashboard cada x tiempo en reuniones tipo steering o Sprint Review, de esta forma nos aseguraremos que se comprenda a la perfección.

5 Gestión constante de los riesgos

Hemos dejado este último punto para el final, porque este tipo de proyectos son de alto riesgo y debemos ser muy proactivos en la identificación y comunicación de todos los problemas que vayamos detectando a lo largo del proyecto.

Una manera que nos ha funcionado de gestionar los riesgos ha sido incluirlos como tablero Kanban dentro la herramienta de gestión del proyecto. De esta manera los riesgos se pueden asignar de manera nominal, también realizar relaciones cruzadas con otras tareas dispuestas en el backlog, documentación anexa o actas con el fin de tener una bitácora completa y bien detallada para que todo el mundo esté en la misma página, sea o no una nueva incorporación al proyecto.

Otra buena práctica es la de gestionar los Planes de Acción (PA) de mejora que resultan de las dinámicas de retrospectiva en este mismo tablero, tipificadas como tal para diferenciarlas de los riesgos.

Esta acción nos ha permitido aplicar las mismas virtudes que antes comentábamos de tenerlo en la misma herramienta e incluso tener la trazabilidad de evolución de ese PA que, a veces, se puede transformar en un riesgo.

Por último, debemos emplear coraje y creatividad en las acciones de mitigación de los riesgos y, lo más importante, mucha constancia en su seguimiento con todas las partes implicadas.

Conclusión

Con esta breve guía buscamos ayudar a crear una buena organización desde el principio de este tipo de proyectos, sin perder de vista el agilismo y con el objetivo de proporcionar un método de inspección, adaptación y refinamiento de un producto, aunque partamos de un contexto cerrado como puede ser una RFP.

Lo más valioso a tener en cuenta es la actitud con “C” y la aptitud con “P” porque siempre es lo que va a marcar la diferencia entre el éxito y el fracaso.