Los gobiernos han estado a la vanguardia de la innovación en gestión de proyectos, como muestra esta infografía del Día D de Estrellas y barras. Y, sin embargo, hay muchos fracasos en la implantación de software empresarial en la administración pública.
Fracasos de los proyectos gubernamentales
La mayoría de los gobiernos exigen que los proveedores utilicen las mejores prácticas de gestión de proyectos, en consonancia con la Conocimientos básicos de gestión de proyectos (PMBOK) del Instituto de Gestión de Proyectos. Las empresas de integración de sistemas aplican prácticas estrictas de gestión de proyectos. Los gobiernos suelen emplear gestores de proyectos certificados.
Pensaba que habíamos visto el cenit de los fracasos del software empresarial y ERP del Departamento de Defensa de EE.UU., con 4 de 13 proyectos que costaron entre 200% y 1050% de los presupuestos originales. Eso hasta que el "Sistema de retribución Phoenix" en el Gobierno de Canadáuna versión personalizada de Oracle PeopleSoft, implantada por IBM. Macleans explica el estado actual en el siguiente vídeo:
La paradoja de la gestión de proyectos
¿Por qué las "mejores prácticas" de gestión de proyectos funcionan en algunos contextos y no en otros? ¿Por qué los gigantes de Internet utilizan metodologías ágiles?
La gestión de proyectos tradicional parte de la base de que los proyectos son complicados, pero predecibles. La construcción de un puente, por ejemplo, puede ser complicada y requerir conocimientos técnicos de ingeniería. Los ingenieros comprenden la resistencia de los materiales, cómo construir en distintas condiciones del terreno y cómo hacer frente a los cambios de temperatura. El progreso del proyecto puede predecirse basándose en proyectos similares. Por supuesto, el progreso real es muy fácil de ver.
Las implantaciones de software empresarial son complejas. Los proyectos de planificación de recursos gubernamentales (GRP) son transformacionales. Se necesitan expertos en finanzas, recursos humanos o contratación pública. Y también expertos en TI. Los usuarios necesitan formación especial. (Los usuarios puente no necesitan formación nueva). Y lo que es más importante, los proyectos GRP transformar y automatizar procesos causando una resistencia significativa al cambio.
Lo que podemos predecir de los proyectos de software para empresas públicas es que son muy impredecibles. Los proveedores suelen cumplir 100% los requisitos documentados del gobierno, como ha hecho IBM con el sistema de pago Phoenix. Sin embargo, los sistemas no cumplen los requisitos originales. En cierto modo, esto se debe a que la gestión tradicional de proyectos en la Administración se centra en la documentación como sustituto de los requisitos reales. Y lo más importante son los contratos, no los requisitos del usuario.
Patrones de paradoja
Muchos clientes gubernamentales insisten en seguir procesos en cascada muy estructurados. FreeBalance, uno de los pocos fabricantes de software empresarial que realmente implementa software para clientes, ha descubierto muchos patrones que conducen al riesgo:
- Anclaje: Las implantaciones de software suelen estar ancladas a la solución existente en el lugar. Los usuarios quieren algo familiar. Sin embargo, los sistemas existentes suelen estar plagados de ineficiencias y errores. A menudo, el software se personaliza para seguir procesos anticuados. Los responsables del proyecto se anclan a los procesos "tal cual". Se crean informes innecesarios. La calidad de la información no suele mejorar. Las personalizaciones conducen a más errores. Por supuesto, todo esto resulta un poco extraño si se tiene en cuenta que el objetivo de adquirir un nuevo sistema es debido a las deficiencias del antiguo.
- Documentación: En la gestión de proyectos tradicional se crean páginas y páginas de documentación detallada. Cada etapa requiere documentación para que la firmen los responsables de la toma de decisiones. Cuanta más documentación, más difícil les resulta a los responsables visualizar cómo será el sistema final. Por ejemplo, la mayoría de los métodos para articular especificaciones son muy difíciles de entender para la mayoría de la gente. Son fáciles para los ingenieros de software. Esto provoca retrasos. Muchos retrasos.
- Contratos: El resultado deseado por las empresas de integración de sistemas es cumplir las obligaciones contractuales. Los sobrecostes y los cambios de calendario están bien siempre que el gobierno pague. La documentación, los contratos y las modificaciones contractuales redefinen el éxito desde los objetivos originales del gobierno hasta el cumplimiento del contrato. Por eso las empresas de integración de sistemas cobran aunque los usuarios no estén satisfechos.
- Resistencia al cambio: La gente ve la construcción de un puente en marcha. El software es otra historia. Muchos proyectos esperan a que se apruebe toda la documentación antes de proceder a la personalización y configuración. Esto provoca una mayor resistencia al cambio. Los usuarios, los miembros del equipo gubernamental del proyecto y los responsables de la toma de decisiones se desconectan de la aplicación. Se asume que el proyecto no va bien porque no hay nada que mostrar.
- Equipo Bloat: La necesidad de negociadores de contratos, redactores de documentación y explicadores hace que los equipos sean más numerosos. Esto puede parecer algo bueno a quienes no hayan leído el Mes del Hombre Míticopublicado por primera vez en los años setenta. Los problemas de coordinación y comunicación se vuelven exponenciales.
Hemos completado una evaluación de proyectos de implantación de FreeBalance, ERP en proyectos gubernamentales y buenas prácticas ágiles. Nuestra metodología se ha actualizado a A-i3+qM (acelerado, integrado, iterativo, centrado en la aplicación, gestión de la calidad):
- Acelerado eliminando el mayor número posible de procesos heredados en cascada que provocan problemas en los proyectos. Esto incluye documentación innecesaria y planes de proyecto detallados, en favor de talleres y pasos de proceso cortos. Los equipos son pequeños para facilitar la comunicación con el cliente y reducir los gastos de coordinación.
- Integrado a través de una metodología única para apoyar el desarrollo y la implantación de servicios. Esto se integra con los requisitos del cliente a través de los procesos centrados en el cliente. Esto proporciona transparencia entre el personal del cliente, los implementadores y el equipo de desarrollo. Los equipos de implantación y desarrollo de productos se integran siguiendo prácticas DevOps.
- Iterativo responder a los cambios del cliente y de la aplicación mediante fases. La metodología aprovecha lo mejor de las metodologías "lean" de desarrollo de software y servicios, con talleres, iteraciones cortas, historias de usuario, hitos y la capacidad de mostrar el progreso. Estas técnicas se extienden más allá de la organización de desarrollo a los servicios de implantación, aprovechando las ganancias de productividad y la capacidad de reaccionar a las necesidades del cliente.
- Centrado en la aplicación con plantillas de buenas prácticas y procesos probados de gestión de programas. Esta metodología se centra en el éxito de la implantación por parte del cliente, más que en un lanzamiento de software que alcance objetivos internos o arbitrarios. La implantación y el desarrollo del producto se gestionan a través de una Oficina de Gestión de Programas.
- Calidad garantiza que el software se publique y reciba soporte cumpliendo las buenas prácticas de Commercial Off-the-Shelf (COTS) con pruebas unitarias, de sistema, de estrés y de regresión. La calidad se integra con la implementación, en la que FreeBalance realiza pruebas basadas en los entornos de los clientes.
A-i3+qM reconoce las deficiencias de los procesos tradicionales de gestión de proyectos en las implantaciones de GRP. Y, los patrones del fracaso.
- Anclaje: Las aspiraciones se convierten en el ancla. Se organizan talleres tras el inicio del proyecto. Los equipos de los proyectos gubernamentales reciben formación sobre el software FreeBalance para mostrar lo que podría ser. Nuestro personal es experto en gestión de las finanzas públicas, gestión de la función pública, planificación del presupuesto público, contratación pública, etc. Lo sabemos todo sobre cómo funcionan, y deben funcionar, las finanzas públicas. Nos centramos en cómo puede configurarse nuestro software para dar respuesta a los problemas que hay que resolver.
- Documentación: La FreeBalance Accountability Suite es masivamente configurable. Esto significa que podemos realizar cambios en las reglas de negocio, el flujo de trabajo, el lenguaje y los datos rápidamente sin codificar. Es un enfoque masivo sin código. Los usuarios pueden ver si se satisfacen los requisitos. No se necesitan grandes cantidades de documentación.
- Contratos: Los contratos son importantes para FreeBalance. Como empresa social, nos centramos en que las administraciones públicas puedan financiar las implantaciones. Y tenemos un incentivo para entregar lo que se requiere, lo más rápido posible, para que nos paguen lo más rápido posible.
- Resistencia al cambio: La resistencia al cambio empieza a disiparse demostrando los avances en la mejora de las configuraciones de software. Esto no quiere decir que los talleres y las demostraciones eliminen toda resistencia al cambio. La metodología se centra más en la gestión del cambio que en la gestión genérica de proyectos.
- Equipo Bloat: Nuestro enfoque mantiene el tamaño óptimo de los equipos. A menudo nos encontramos con profesionales de la administración pública o de la integración de sistemas familiarizados con el tamaño de los equipos para proyectos ERP o desarrollados a medida. La huella de personalización es mucho menor en los proyectos de FreeBalance.