La gestión de proyectos web en las Administraciones: cuando llegues serás viejo

Hace unas semanas hablaba con un responsable de un proyecto en una organización pública que me contaba que su proyecto de 4 años (un Cuadro de Mandos) llevaba 3 de realización y el año que viene arrancaba. Es decir, en un trabajo de 4 años que afectaba a la organización, hasta el cuarto no sabrían si se había trabajado bien todos los años anteriores. Esto me hizo reflexionar acerca de cómo se hace la gestión de proyectos web en las administraciones públicas. 

ballenas y delfines
Ballenas y delfines, una sutil metáfora

Todos hemos pasado la misma desalentadora experiencia: ir a visitar un sitio web público nuevo, recién lanzado y tener la impresión de que está ya viejo y obsoleto. Lamentablemente, es una sensación muy habitual en la que hay algo de cierto: los servicios públicos digitales, muy habitualmente, o parecen muy viejos, o realmente lo son. En esto influyen aspectos estructurales, culturales  y técnicos propios del sector público. Algunos de ellos dependen de la propia velocidad de la organización que precisa de tiempo para asimilar nuevas tecnologías; en otros casos se debe a la propia responsabilidad que supone asumir de manera temprana tecnologías que, hasta determinado grado de madurez, son apuestas y, por ello no son seguras. Hay otras, que responden al modo de trabajar de la Administración y que, si bien no totalmente erradicables si que se pueden minimizar a partir de un cambio en la gestión de proyectos web. Es de esto de lo que vamos a hablar.

Los proyectos transformadores

Por regla general la Administración cuando realiza proyectos suele tener de dos tipos: los que considera relativos a la gestión de sus tareas y los que considera realmente innovadores. A los primeros les dedica una menor cantidad de tiempo debido a que la propia dinámica de abordarlo ya es conocida por la organización. No se trata de un tema presupuestario, porque el presupuesto puede ser grande, pero si la organización sabe gestionarlo lo hará de manera eficiente. El otro tipo es el que podemos considerar de cambio que, a diferencia de los anteriores, si que tienen un presupuesto importante pero que la organzación, por su propia definición, procesa más despacio.

Los procesos de cambio, al tener un coste más elevados e implicar un gran esfuerzo técnico y político (en plano interno y externo de la organización), suelen afrontarse como un gran bloque. Esto es lógico por diferentes razones:

  • Encerrar el cambio en un solo proyecto permite distribuir el coste de oportunidad en la organización. Significa aislar los agentes implicados en ese proyecto y liberar al resto de la organización en la gestión.
  • Gestionar en un solo proyecto y contrato reduce (al menos teóricamente) los costes de transacción. Generar un solo contrato reduce el coste de convocatoria, evaluación y adjudicación, contratación y seguimiento.
  • Permite una gestión unificada del mando. Es más fácil gestionar con una sola unidad una serie de elementos que se realizan de manera simultánea.

Esto es la manera de afrontar este tipo de proyectos, sean carreteras, webs de búsqueda de autobuses, líneas de alta velocidad o trenes. Sin embargo, nos lleva  a no poder hacer pruebas de uso de desarrollos tecnológicos a corto plazo. Realmente las compañías digitales están siempre probando, antes de hacer un gran cambio de interfaz o de funcionalidades van introduciendo pequeños cambios para ver cómo operan y, finalmente, hacen accesos aleatorios a diferentes usuarios. En otros términos, en el resto del mundo tecnológico, nadie espera años para empezar a implementar medidas y hacer pruebas.

Ballenas y delfines; no siempre es posible

Culalquier persona que esté familiarizada con la gestión de proyectos TIC se ha encontrado con uno de los mantras de la disciplina: «dejar de crear ballenas para crear delfines«. En grandes líneas se trata de abordar los cambios no como un gran proyecto, sino como pequeños proyectos (especialmente en cuanto coste, esfuerzo y tiempo), que permitan avanzar igual de rápido pero de manera más segura en la gestión del cambio.

Esto suena muy bonito y lógico en la teoría, pero en la práctica no siempre es posible. Como decía, que la Administración aborde sus grandes proyectos como obras ciclópeas no es un capricho, sino que responde a buenas razones como hemos visto. Pero si hay algo realmente crítico es que, por la propia dinámica de la Administración no parece posible abordar un gran cambio web como pequeños proyectos.

  • Legalidad: Fraccionar un proyecto único en diferentes proyectos pequeños es un tema que levanta las alertas sobre la legalidad de un proceso, dado que es una técnica habitual para evitar controles y garantías de competencia. Si usted plantea dividir la creación de su web en distintos pequeños proyectos, aunque la inteción sea buena, generará no poco ruido
  • La velocidad de la gestión:Entendamos que un proyecto o grupo de proyectos supone generalmente la previsión presupuestaria (normalmente un año antes), la dotación de crédito, el anuncio previo, la convocatoria de la contratación, la realización del concurso, la adjudicación…. y luego hay que hacer el proyecto. Dicho de otra manera: desde que tenemos la idea hasta que se termina el proyecto podemos esperar 18 o 24 meses (si el proyecto va rápido y no hay errores en la realización del contrato). Pensemos en lo que suponen 18 o 24 meses en términos de tecnología y diseño web
  • La unidad de mando. Por mucho que queramos hacer una estructura especializada con distintas subunidades, lo normal es que, si queremos mantener el cambio en una única dirección, el mando deber ser único.

Cualquier ingenioso consultor podría recomendar que simultanée el lanzamiento de pequeños proyectos para gestionarlos a la vez y así evitar la acumulación de plazos de 18 meses para hacer el proyecto. Sin embargo, su propio sentido común le puede decir que si gastas mucho dinero a la vez, y gestionas muchos proyectos al mismo tiempo, bajo una misma unidad de mando, y con un fin común… estas gestionando un solo proyecto.

 La evolución planificada.

En resumidas cuentas, estamos en un entorno en el que no es eficaz hacer proyectos grandes, no es eficiente hacerlos pequeños, y no parece que haya opciones intermedias. Esto no significa que no podamos encontrar respuestas. Lo primero que tenemos que considerar es que lo que necesitamos, en términos reales, es poder ir implementando medidas y testear todo lo que hacemos. Probar es una de las cosas más importantes para conseguir los resultados deseados. No me refiero a los modelos de gestión de pruebas de QA imprescindibles para ver si funciona algo técnicamente, sino pruebas que ayuden a conocer si lo que hacemos cumple un objetivo. Esto es importante por que un error detectado pronto es fácilmente corregible, pero enterrado a lo largo del tiempo afecta a los pilares del proyecto.

Para poder actuar de esta manera necesitamos:

  • Horizontes de acción concretos en menos de 6 meses. Antes de que pasen 6 meses del inicio del proyecto deben estar en marcha algunos de sus hitos fundamentales. Puede ser que no estén 100%, o que no estén integrados en el interfaz definitivo (por ejemplo, una nueva funcionalidad en la web no tiene por qué esperar a que su interfaz esté diseñado para ir realizando pruebas). Así podemos averiguar qué es lo que funciona, qué es lo que no, y cómo afecta al proyecto.
  • Cada pequeño hito debe tener unos objetivos externos testeables. En gestión de proyectos suelen referirse al aspecto interno del alcance, pero no al externo. Esto hace proyectos solventados técnicamente bien pero fuera de los hábitos de uso del público. Cada hito debe tener un horizonte de KPI’s evolutivos a prueba para ver cómo va adaptándose el proyecto a la realidad.
  • Valorar los objetivos deseados, los márgenes de desviación tolerables y las condiciones de cambio y las posibles interacciones con otros hitos del proyecto. Si, por ejemplo, tenemos un formulario que no funciona tal y como se diseñó, posiblemente será necesario replantear el sistema para crear nuevos usuarios. Tendremos que saber cuándo va bien, cuando hay que cambiar un poco y cuando es necesario replantear el diseño entero.

En resumidas cuentas partimos podríamos decir que, si bien las cosas pueden ser más manejables, si que podemos hacer que se puedan gestionar de manera más manejable. Basta con entender que no tenemos por qué conformarnos con modelos que no cumplen con su propósito y probar nuevas fórmulas.

Comparte este artículo

Acerca del autor

Regístrate y consigue los últimos artículos en tu mail.

1 comentario en «La gestión de proyectos web en las Administraciones: cuando llegues serás viejo»

Deja un comentario

SUSCRÍBETE AL BOLETÍN DEL BLOG

y recibe novedades y material exclusivo sobre transformación digital en Administraciones Públicas
Analítica Pública usará esta información para mandarte el boletín y actualizaciones puntuales. Del mismo modo, si deseas señalar qué aspectos son los que te interesan de la Transformación Digital, lo tendremos en cuenta para trabajar más en esos campos. También tendremos en cuenta si abres o no los correos y si haces clic en ellos. No es por cotilleo, eso ayuda mucho a la hora de saber qué temas y enfoques son los que interesan y los que hacen que la gente nos regale un poco de su tiempo. En cumplimiento de lo establecido en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal le informamos que sus datos personales quedarán incorporados y serán tratados en los ficheros de Analítica Pública, con el fin de poderle prestar y ofrecer nuestros servicios, así como para informarle sobre novedades y nuevos proyectos en los que se encuentre trabajando la empresa. Le informamos de la posibilidad de que ejerza los derechos de acceso, rectificación, cancelación y oposición de sus datos de carácter personal en info@publilitica.es, mediante la utilización de un correo electrónico conforme se informa en la política de privacidad.»