En mi experiencia personal, existen algunas barreras institucionales para la ejecución efectiva y exitosa de grandes proyectos gubernamentales. De hecho, puede ser que los procesos implementados para reducir el riesgo de fallas en la entrega y el desperdicio de dinero sean, en muchos casos, los mismos factores que aumentan significativamente el riesgo de esa falla.
Una desconexión fundamental entre el enfoque ágil ascendente fomentado por los Servicios Digitales Gubernamentales (GDS) y la naturaleza descendente de la mayoría de los procesos de aprobación, financiación y supervisión de programas y proyectos de TI.
Este enfoque a menudo exige establecer un caso de negocio que detalla un diseño inicial acordado, un conjunto completamente definido de resultados y beneficios al inicio del proyecto y el presupuesto necesario para su ejecución. Todos ellos se basan fundamentalmente en la planificación de proyectos tipo cascada.
Como exfuncionario del Tesoro, entiendo perfectamente la necesidad de racionar el gasto y asignarlo donde sea más útil, pero la forma en que está configurado actualmente no es compatible con la ejecución de proyectos ágiles.
En el mejor de los casos, estas son sólo formalidades menores que los proyectos deben cumplir antes de embarcarse en un enfoque ágil de entrega. En el peor de los casos, socavan el proceso de entrega requerido y distraen al equipo del proyecto del enfoque iterativo, rápido y flexible necesario para una entrega exitosa. Esto debe cambiarse en el enfoque actual del gobierno para simular un experimento de puesta en marcha y aprender el mantra.
Desconectado por personal de TI y de negocios
Pero este enfoque también se verá socavado si se da prioridad a otra tendencia en TI gubernamental. Muchos departamentos se centran casi exclusivamente en ejecutar todos, o incluso la mayoría, de los proyectos internamente, utilizando código personalizado para crear las soluciones necesarias. Esto se hace a menudo debido a la complejidad, o al menos la complejidad percibida, de los procesos gubernamentales y lo diferentes que son de los de las organizaciones del sector privado.
Sin embargo, centrarse en construir sistemas utilizando código personalizado requiere mucho tiempo, es costoso y difícil de gestionar, y aún así a menudo no se cumple. Esto a menudo da como resultado una desconexión entre el gran equipo de TI y el personal de la empresa que, en última instancia, poseerá y utilizará el sistema, y se transmiten grandes cantidades de documentación de diseño entre ellos.
Los proyectos pequeños y ágiles son importantes
Para hacer realidad la visión de Keir Starmer de volver a cablear Whitehall, se necesita un enfoque que muestre cómo el gobierno puede aplicar el desarrollo de software de código bajo de manera inteligente y en las áreas correctas. Podría revolucionar la forma en que se diseña y construye la TI gubernamental al reducir significativamente la cantidad de desarrollo de código personalizado requerido y transformar la forma en que los empresarios participan en el proceso.
El nuevo gobierno tiene razón al elegir pequeños proyectos aislados. La transformación del gobierno debería adoptar un enfoque más iterativo y menos “big bang”. Comenzar poco a poco y elegir uno o dos procesos clave en cualquier área determinada, para empezar, y adoptar un enfoque como el desarrollo ágil de código bajo que reduzca la dependencia de experiencia técnica escasa y costosa, al tiempo que obliga a los equipos de negocios y de TI a trabajar juntos haciendo el camino
Esto le permite llegar al punto en el que los resultados se pueden evaluar mucho antes, en función del cual pasar al siguiente miniproyecto. Al final se pueden pasar muchas etapas y lograr transformaciones claras pero sostenibles pero minimizando los problemas de los métodos más tradicionales.
Alex Case, ex alto funcionario de Downing Street y ahora director de la industria gubernamental en Pegasystems, que desarrolló una plataforma de bajo código para crear aplicaciones.