Me pregunto si los expertos en gestión de proyectos piensan que una buena documentación habría evitado que Otelo matara a Desdémona. ¿Habría consultado Otelo, furioso, la gruesa carpeta que atestiguaba el amor y la fidelidad de Desdémona? Shakespeare llegó al quid de la tragedia: la comunicación informal de Iago.
Sin embargo, el alcance de la documentación se ha convertido en una "buena práctica" en las implantaciones de TI en la Administración. Las aprobaciones se retrasan porque la documentación de apoyo no es lo suficientemente completa. Me parece que muchos observadores atribuyen la falta de documentación, o la precisión de la misma, de tantas implantaciones de TI y Fallos de la ERP en la administración pública. Este post amplía una falta de documentación patrón descrito en mis posts del año pasado: La paradoja de los proyectos gubernamentales y La escandalosa fortuna de los procesos en cascada en la Administración. También introduce un enfoque ágil basado en el riesgo para la documentación de proyectos.
¿Cuál es la razón de ser de una documentación detallada del proyecto?
Existe un largo legado de documentación de proyectos para implantaciones complejas de software. A menudo se considera una solución al problema frecuente en la administración pública: el software empresarial no sigue los procesos requeridos. La idea es que una articulación en profundidad de los procesos actuales ("tal cual") garantizará que el software resultante satisfaga las necesidades operativas. Y el análisis en profundidad de estos procesos identificará lo que hay que cambiar ("fit-gap") para describir plenamente una situación mejorada ("to-be").
A menudo, esto exige que las empresas de integración de sistemas se sienten con los expertos en procesos de la Administración en complejos ejercicios de mapeo de procesos. Estas empresas suelen culpar a los expertos de la Administración de no articular plenamente los procesos cuando las implantaciones se tuercen.
¿Cuál es el contexto de la documentación como solución?
Mi sensación es que la ceremonia del cumplimiento de la documentación tiene más probabilidades de conducir al fracaso que al éxito del proyecto. La articulación detallada del "tal cual" es tan útil para que los sistemas funcionen como los muebles rotos de la sección "tal cual" de Ikea para amueblar una casa. Por algo hay que sustituir los sistemas. Por eso, los procesos empresariales "por hacer" están en el camino crítico. Se necesita un enfoque más coherente.
¿Qué ocurre durante el largo proceso de descubrimiento y documentación "tal cual"?
- Aumenta la resistencia al cambio como las partes interesadas y los usuarios no ven progresos, da tiempo a que las fuerzas contrarias al cambio saboteen el proyecto
- "As-is" impulsa "to-be" porque el primer conjunto de documentación se convierte en el anclaje conceptual, sobre todo porque la resistencia al cambio aumenta
- Código demasiado personalizado alcance, tiempo y futuros costes de actualización que aumenta porque las partes interesadas exigen que el nuevo sistema se comporte de forma muy parecida al antiguo.
- La realidad rara vez se documenta porque el personal de la Administración rara vez describe las soluciones alternativas utilizadas en los sistemas actuales, las prácticas que incumplen la normativa, como el incumplimiento de la separación de funciones, o cómo se utilizan realmente los sistemas, por ejemplo, para registrar transacciones que ya se han producido.
- Lo artificial se convierte en evangelio Debido a las limitaciones de los sistemas anteriores, los expertos gubernamentales llegan a la conclusión de que las estructuras artificiales, como la separación de las clasificaciones presupuestarias de las clasificaciones contables, o la separación de los sistemas ejecutivo y ministerial, o los métodos extraños de gestión de los compromisos o de la tesorería son de alguna manera naturales.
- Lo importante está oculto dentro de páginas de documentación y la trazabilidad entre procesos, configuraciones y personalizaciones se hace difícil
La cantidad de documentación suele prevalecer sobre la calidad de la misma porque la cantidad proporciona la primera prueba visceral de que el equipo del proyecto ha hecho algo. Pero, como respondió uno de mis profesores universitarios a la pregunta de cuánto debía durar la redacción: "20 páginas, pero si tienes tiempo, que sean 12".
¿Cómo puede mejorar la calidad de la documentación de un proyecto reduciendo su cantidad?
La transparencia de los proyectos no debe esperar a nadie. Pero me da la impresión de que la opinión es que no pasó nada hasta que se documentó. No importa si el árbol que cayó en el bosque hizo ruido o no. En el software de las empresas públicas, el árbol sólo se cayó si estaba documentado. ¿Por qué deben esperar tanto las partes interesadas para saber si ha ocurrido o está ocurriendo algo?
A basado en el riesgo de la gestión de proyectos.
Ahí es donde los procesos y técnicas ágiles son más eficaces: mostrando el estado de los proyectos casi en tiempo real. Los procesos ágiles pueden utilizar tableros kanban, scrum o scrumban para mostrar el progreso, las tareas pendientes, las prioridades y la asignación de tareas. La diferencia entre las historias de usuario reales y las estimadas permite prever la finalización de hitos mucho mejor que los tradicionales gráficos GANTT. Los equipos de proyecto no tienen que documentar el estado como para hacer fotos del tablero. Las cantidades de tareas no completadas alertan a los equipos de proyecto. Los problemas se hacen visibles.
Hay que documentar estos problemas y alertar a las partes interesadas para que puedan tomarse decisiones. Hay una razón por la que los regímenes de inteligencia empresarial se han centrado en los informes de excepciones para las principales partes interesadas. Ya es hora de tener informes de excepciones en la documentación. Y, para tener una alerta temprana. Las partes interesadas entenderán que la alerta por correo electrónico es fundamental, no sólo otro conjunto de documentación actualizada del proyecto.
¿En qué puede diferir la documentación de un proyecto en función del contexto?
La mentalidad de documentación en los proyectos gubernamentales rara vez se basa en el riesgo. Hay rendimientos decrecientes para documentarlo todo. Sin embargo, ese es el caso de muchos contratos públicos en los que la aprobación final se basa en pruebas de aceptación del usuario que incluyen la documentación del proyecto. Esto añade complejidad a los procedimientos de prueba. Hemos desarrollado un método diferente que recomendamos a cualquier gobierno que desee implantar software comercial, incluido el de FreeBalance:
- Anclar el proyecto de forma diferenteEl primer paso consiste en formar al personal del proyecto gubernamental en el nuevo software COTS, mostrando cómo se pueden alcanzar los objetivos "a-ser" del gobierno y cómo el software COTS satisface los requisitos de manera diferente a la concebida en el proyecto anterior.
- Separar la configuración de la personalizaciónTaller de cambios de configuración con el personal del proyecto gubernamental y los usuarios finales, con la aprobación de la configuración cuando se demuestre, mientras que la personalización del código sigue procesos ágiles.
- Personalización basada en el riesgo y el valorIdentificar y documentar los riesgos de coste-beneficio de cualquier iniciativa de personalización para mejorar la toma de decisiones del proyecto.
- Documentación ágilAprovechar y documentar prototipos y guiones gráficos para obtener la aprobación de la personalización, en lugar de depender de la documentación tradicional.
- Pruebas ágilesPruebas de configuración a lo largo de la implementación: reducen la carga de las pruebas de aceptación final, que se centrarán más en el riesgo: personalización, donde la calidad de la documentación es de vital importancia.
¿Cómo resuelve este enfoque ágil la tragedia de la documentación de proyectos?
- Disminuye la resistencia al cambio porque las partes interesadas y los usuarios ven los progresos de la configuración y los talleres demuestran la voluntad de tener en cuenta las aportaciones de los usuarios
- El "deber ser" impulsa el proyecto porque las iteraciones se centran en objetivos gubernamentales
- Personalización contenida porque se exploran todas las características del software COTS en relación con los objetivos "por alcanzar", y personalización como excepción está totalmente documentado
- La realidad está incrustada porque el personal de la Administración describe las prácticas durante los talleres de configuración, y los expertos del proveedor (esto presupone que el proveedor entiende el ámbito) explican las razones de los cambios de prácticas
- Lo artificial se racionaliza porque el software COTS no impone estas restricciones, suponiendo que el software se haya diseñado efectivamente
- Lo importante es lo visible menos páginas de documentación con una trazabilidad eficaz y el uso de tableros ágiles para informar sobre la marcha de los trabajos