Ajedrez - antoniomartel.com

Archivos por Etiqueta: Administración Pública

Cómo ser ágiles en proyectos para la administración pública o a precio cerrado

La mayor parte de mi vida profesional, como muchos otros, la he vivido trabajando en proyectos a precio cerrado (fixed price) en concreto trabajando para administraciones públicas en las que el alcance del proyecto venía prefijado de antemano en pliegos de condiciones administrativas y claúsulas técnicas.

En este tipo de proyectos tienes que presentar una propuesta económica, de recursos y de tiempo a la administración pública que valorará cuál es la mejor de las ofertas presentadas, normalmente la de presupuesto económico más bajo, decidiendo luego qué proveedor será el adjudicatario. Por tanto, desde antes de iniciar el proyecto, tendrás que estudiar las condiciones y el alcance fijados en los pliegos y hacer una arriesgada estimación de cada una de las tareas o módulos que se requiere desarrollar y lanzar tu oferta.

¿Se puede ser ágil en proyectos en los que el costo, el alcance y a veces la fecha de entrega están cerrados desde el inicio? Yo pienso que sí, veamos cómo.

¿Qué hacer con el coste?

Este es el lado más arriesgado de este triángulo de hierro. Hemos hecho una estimación basada en lo que ponía en los pliegos de contratación pero estos contienen en la mayor parte de las ocasiones una descripción genérica de las tareas a realizar que luego se concretará a medida que se avanza en el proyecto o se analiza con las partes interesadas. Más que una oferta hemos hecho una apuesta que no sabemos si nos saldrá bien.

Tendremos que confiar en haber hecho una buena estimación. Por naturaleza todos tendemos a ser demasiado optimistas teniendo en cuenta sólo los escenarios en los que todo marcha bien. Sólo cuando usamos estimaciones tipo PERT en la que se nos obliga a ponernos también en el peor caso nos paramos a pensar en esos grandes imprevistos que siempre pueden pasar (como se dice en inglés, shit happens). A partir de aquí nos basaremos en las mejoras de eficacia que proporciona la agilidad.

En Scrum y otros frameworks iremos entregando cada poco tiempo una parte del alcance prometido lo que permitirá ir enseñando nuestros trabajo, haciendo correcciones y aprendiendo de lo que ya hemos hecho. En los proyectos en cascada también hay fases: Análisis, Diseño, Construcción y Testeo pero al final de las primeras sólo entregamos unos documentos sobre lo que se va a construir. Sería como analizar, diseñar un nuevo prototipo de móvil y esperar a construir 10.000 unidades para luego comenzar a venderlo y ver si le gusta a los usuarios que lo han comprado o no.

Incluir los tests y planes de aseguramiento de la calidad en cada sprint nos permitirá construir bien desde el inicio y con menos costes. Es mucho más fácil corregir los problemas de cobertura de un móvil cuando se está desarrollando y diseñando la antena en los primeros modelos que cuando ésta ya ha llegado a la línea de ensamblaje para la producción en masa.

¿Qué hacer con el alcance?

A medida que avanza el proyecto es habitual que el cliente se dé cuenta de que necesita cosas que no están incluidas en el contrato inicial. Elaboró los pliegos con el conocimiento que tenía en ese momento pero según se adquiere más experiencia en el proyecto y se va usando la aplicación (recordemos que la vamos entregando poco a poco para que la comiencen a utilizar) se va dando cuenta de que hay partes sin las que el software sería mucho menos provechoso.

En los proyectos ágiles en los que he trabajado admito modificaciones negociadas al alcance. Si se quieren incluir cinco informes nuevos a la aplicación que la harían mucho más útil deberemos acordar qué otras tareas de igual o similar estimación quitamos del alcance del proyecto. Normalmente está tan interesado en incluir las nuevas funcionalidades que no le importa sacar del proyecto otras tareas que ahora no ve tan importantes o que incluso considera que no deben hacerse.

Para la negociación habré presentado al cliente desde el arranque del proyecto una estimación de cada una de las funcionalidades a entregar de forma que sabe cuánto valen para él cada uno de estos puntos si decide quitarlos del alcance. Esta estimación fue realizada al inicio del proyecto y puede que ahora sepamos que hay cosas que son mucho más costosas de realizar de lo que estimamos al inicio, sin embargo, no cambio esta estimación inicial para que el cliente no se sienta engañado. Normalmente las estimaciones que ahora son más costosas son compensadas con otras que ahora sabemos que no lo son tanto y que también quiere que quitemos del proyecto. En cualquier caso, si hemos conseguido que el cliente esté satisfecho con el trabajo que le hemos ido entregando poco a poco y además está contento por las nuevas funcionalidades que va a conseguir, la negociación no debería ser muy dura.

¿Que hacer con el tiempo?

A veces, además de tener un importe económico y un alcance fijos tenemos que cumplir también con unas fechas de entregas inalterables que nos obligarían a aumentar las horas extras, los tiempos dedicados durante el fin de semana y el número de desarrolladores implicados en el proyecto aumentando considerablemente nuestro coste del proyecto.

Si hemos sido ágiles en el proyecto y hemos ido poniendo en producción cada poco tiempo lo que hemos ido desarrollando, el cliente podrá tener ya en uso el día de la fecha de entrega un porcentaje alto de lo que se necesita entregar. Si además hemos priorizado correctamente, desarrollando en primer lugar aquellas funcionalidades que más valor aportan, sólo quedarán fuera aquellas de menor importancia por lo que normalmente pueden entregarse en una segunda fase sin que se altere demasiado el valor del sistema.

Si hubiésemos realizado un desarrollo en cascada y estuviésemos retrasados, en la fecha de entrega no tendríamos nada que subir a producción a pesar de que podríamos tener un 80% del trabajo realizado. Durante las últimas semanas del proyecto tendríamos que abusar de las horas extras y del estrés para entregar ese 20% que nos falta pero probablemente sólo consigamos que sufra la calidad del software que entregamos y que se se ignore la fase de tests del desarrollo apareciendo un montón de bugs después de la entrega.

Administración Pública y las nuevas prácticas de gestión

Somos muchos los que de una manera u otra trabajamos para la Administración Pública, algunos directamente pero otros muchos indirectamente, como proveedores de servicios o productos pero trabajando en este sector al fin y al cabo.

Muchos tratamos de realizar estos servicios o entregar esos productos aplicando técnicas de gestión ágiles como Scrum o Lean Management pero solemos encontrarnos con cierta rigidez en la formalización de los contratos o en los pliegos de contratación de los concursos públicos.

Alguien preguntaba recientemente en un debate del grupo PMP Canarias en LinkedIn si las administraciones públicas estaban preparadas para la gestión de este nuevo tipo de proyectos. En mi opinión, a la Administración Pública Española aún le queda un buen trecho pero creo que ya se comienzan a ver ciertos avances en la aplicación de nuevas formas de gestión como Lean Government, especialmente en otros países.

En el NHS, el sistema de seguridad social británico, con la aplicación de técnicas Lean para eliminar retrasos innecesarios, reducir el papeleo y aprovechar los tiempos muertos de espera para realizar ‘actividades útiles’ se consiguió reducir la mortalidad en dos tipos graves de fractura de un 22,9% a un 14,6% en solo seis meses. Eso significa que en ese periodo, de media, unos 14 pacientes más lograrían sobrevivir a la operación.

Otro ejemplo de Lean Healthcare se encuentra en un hospital de distrito del NHS. La clasificación de las pruebas de ultrasonido en ‘verdes’ para las más simples y ‘rojas’ para las más complejas permitió reducir la lista de espera para estas pruebas de 12 semanas a tan solo 2. Se asignó el tiempo justo para la complejidad de cada prueba y se redujeron los trámites y el papeleo al mínimo para las pruebas más simples con lo que además de la reducción en los tiempos de espera se logró que quedasen más huecos en el calendario para tratar adecuadamente las posibles urgencias.

Mucho más reciente es la actualización de las normas de contratación del Departamento de Defensa de Estados Unidos para declarar ‘ilegales’ los proyectos en cascada. Parece ser que uno de los proyectos que ha disparado esta decisión fue el proyecto Sentinel en el que después de un proyecto fallido inicial de 170 millones de dólares, retrasos considerables, 6 años de trabajo y 451 millones de presupuesto se consiguió finalmente poner en marcha el nuevo sistema, gracias entre otras cosas, a la aplicación de técnicas ágiles de desarrollo para reducir los tiempos de entrega y los costos de cada funcionalidad entregada.

También en España parece haber un creciente número de instituciones públicas como el Museo Thyssen, el Hospital Clínico de San Carlos en Madrid y su Smart Health Lab o la Agencia Tributaria que están comenzando a usar y aplicar técnicas ágiles como Lean Government en sus negocios. Espero que estas instituciones sean solo la punta de lanza para lograr una Administración Pública más eficiente en estos ‘lean times’

Referencias:

Suscríbete