• El 90% de las empresas españolas es reticente a participar en licitaciones por la falta de agilidad y la complejidad que supone gestionar este tipo de proyectos.
• Las empresas están perdiendo una oportunidad de negocio que solo en el ámbito TIC supera los 3.000 millones de euros.

Según datos de AdjudicacionesTIC, consultora especializada en información sobre contratación con las AAPP, la inversión del estado, solo en tecnología, superará los 3.000 millones de euros. Sin embargo, a pesar de la gran oportunidad de negocio el 90% de las empresas españolas es reticente a participar en procesos de licitación o RFP por la dificultad que encuentran para ser ágiles y gestionar la ambigüedad e incertidumbres que perciben en este tipo de proyectos.

Y es que la Licitación o RFP viene delimitado por dos factores fundamentales: costes y tiempo. En lo que se conoce como un proyecto cerrado, ¿es posible aplicar metodología Agile en este tipo de proyectos?, ¿qué método es el idóneo para “vender’’ a las administraciones públicas?, ¿por qué unas empresas tienen más éxito en las licitaciones que otras? Estas son algunas de las preguntas que se plantea el equipo Agile de Paradigma Digital fruto de su experiencia tras años desarrollando software para grandes empresas.

Si solo el 1% de las empresas españolas obtienen contratación pública ¿cuál es la clave del éxito de estas empresas? Desde Paradigma consideran que aplicar metodología Agile en licitaciones o RFPs es posible y esencial para afrontar con éxito estos proyectos. Y ponen el foco en lo que han definido como metodología Polaris con los cinco pasos a seguir:

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. 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 que 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.

Definir el alcance funcional con fecha fin del proyecto. Este segundo paso es crucial para garantizar una primera versión del producto con el que los usuarios finales puedan interactuar y en consecuencia ofrecer un valioso feedback con el que seguir evolucionando el producto adecuadamente. El cumplimiento de las funcionalidades citadas en la Licitación o RFP debe reflejarse 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. Ceremonias. No se trata de entrar al 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.

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. 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.

Gestión constante de los Riesgos. 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. Incluirlo como tablero Kanban dentro la herramienta de gestión del proyecto es una buena práctica. 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, actas, etc… 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.

En conclusión, según indica Gabriel Salafranca de Paradigma Digital “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.”