¿Es la gestión de proyectos un mito? (I)

18 junio, 2018

Hay un conjunto de razones que están cambiando en muchas empresas la manera de ver la gestión de proyectos y la gestión de las TI en su totalidad. Desde el lado de la demanda: la presión de los clientes internos (los líderes de negocio) por el tiempo de respuesta (el time-to-market), las TI de en la sombra (el shadow IT) y las soluciones de usuario final y autoservicio, entre otras. Desde el lado de la oferta: los modelos de entrega continua (continuous delivery DevOps), la construcción ágil, las nuevas fórmulas de subcontratación (outsourcing), la interdependencia de las plataformas de software y las nuevas arquitecturas de componentes, entre otros.

Según Gartner, las empresas vienen a gastar un 77% del presupuesto de informática en el funcionamiento ordinario de las operaciones (el run), un 13% en el mantenimiento y evolución del parque de activos (el grow) y sólo un 10% en la transformación y creación de nuevos productos (el transform).

A mí (que he dedicado una parte de la carrera a la gestión de proyectos en la docencia, en la consultoría y en la gestión, y sobre la que he publicado algunos libros (1, 2), artículos, materiales y un montón de entradas en este blog) estos datos y tendencias me hacen dudar y me provocan. Y quiero compartir esta provocación con vosotros. Puede que alguno de los principios de oro en que se basó la gestión de proyectos estén ahora en cuestión y, con ellos, la profesión. Comencemos hoy y, si os interesa y me voy animando, seguiremos otros días.

Un proyecto es una entidad única, distinta y separada de las operaciones. Creo que hoy esto no es ya así. La mayoría de los proyectos son una evolución o una variación de un activo existente. Una parte muy importante de las actividades del proyecto, si no la mayoría a veces, son cambios de estado del software e integraciones con otras aplicaciones, que nos cuesta prever y medir dentro del proyecto. Y un número grande de proyectos, sobre todo los basados en producto estándar, son más o menos replicables (excepto precisamente la customización y la integración).

Una cosa es la gestión del proyecto y otra cosa es la ejecución y producción de software. Creo que esto no es así, si lo fue alguna vez. La ejecución representa la mayoría del esfuerzo (en duración y coste) y cuesta pensar que, después de la planificación, eso se pueda delegar en el equipo de desarrollo y luego ponerse a contar horas, hacer actas y encender semáforos. El software ya no se hace de esta manera, o se hace pocas veces. Y si no queremos que el jefe de proyecto se remangue y baje a la arena, entonces necesitamos alguien que lo haga y debemos sustituir al jefe de proyecto por un controller.

Un proyecto tiene un principio y un final. Por desgracia, esto no es verdad. En el mejor de los casos, tiene un principio. Actualmente los proyectos no se acaban o, cuando se acaban, es porque hemos decidido administrativamente darlos por acabados y pasárselos a otra gente, que no participó en su creación y que no sabe muy bien qué hacer, porque no tiene el conocimiento funcional y técnico. ¿Por qué? Sólo para poder decir que lo hemos acabado. Pero esto no tiene que ver con lo que el cliente necesita y, muy frecuentemente, tampoco con lo que pidió.

El triángulo de hierro: alcance, tiempo y coste. Esta es otra de las reglas de oro. Si se toca el alcance o el tiempo, se afecta el coste. Si se reduce el coste o el tiempo, se reduce el alcance. Alargamos los anteproyectos, para desesperación del cliente y de los equipos, porque suponemos que sabremos mejor lo que hay que hacer y cuánto cuesta. Como consecuencia, a veces el anteproyecto es más largo y más caro que el propio proyecto. También nos pasa con el análisis funcional, que a veces se come todo el presupuesto. Y con todo esto, por desgracia, no sabemos mucho mejor lo que se hará o, si lo sabemos, cambiará enseguida.

Otro día podemos hablar de la ilusión de la predictibilidad, del valor «ganado», del famoso PDCA, del reporting, de la gestión de riesgos y, al final, de la misma figura del jefe de proyecto… E incluso aportar, en medio de las frustraciones, algunas vías de solución.

José Ramón Rodríguez es profesor de dirección de las TIC en diferentes programas de la UOC y consultor independiente. Investiga la planificación y gestión de proyectos de transformación empresarial facilitados por los sistemas y tecnologías de la información.

(Visited 44 times, 1 visits today)
Autor / Autora
José Ramón Rodríguez
Profesor de Dirección de Sistemas de Información, Gestión de Proyectos y Business Intelligence de los Estudios de Informática, Multimedia y Telecomunicación de la UOC y consultor de empresas independiente.
Comentarios
Eva P. Gil20 junio, 2018 a las 7:23 pm

Pues la verdad es que lo que expones en este post, más que provocarme, casi que me reconforta, porque efectivamente concuerdo con mucho de lo que dices. Sin embargo, aquí me pregunta es: ante este panorama, ¿cómo podemos afrontar la gestión de proyectos? Aunque mejor expongo mis inquietudes punto por punto:

1. Un proyecto es una entidad única, distinta y separada de las operaciones: Totalmente de acuerdo cuando dices que la mayoría de los proyectos son una evolución o una variación de un activo existente (o al menos, es lo que me encuentro en la práctica). Y esto implica efectivamente un mayor trabajo transversal de los jefes de proyecto no sólo con negocio, sino también con el resto de actores de Sistemas de Información, incluidos los responsables de operaciones.

2. Una cosa es la gestión del proyecto y otra cosa es la ejecución y producción de software: también estoy de acuerdo con que el jefe de proyecto ya no puede limitarse a ser un controller. La alineación con negocio en tiempos de ejecución es clave, y por ello el jefe de proyecto no puede delegar la ejecución por completo en el equipo de desarrollo.

3. Un proyecto tiene un principio y un final: la presentida muerte de este principio es de lo que más escuece en tu post, y es que está en relación directa con lo que comentabas en el punto 1; si la mayoría de los proyectos son una evolución o una variación de un activo existente, ¿cuándo finaliza esta evolución? Y lo que es peor (o no): ¿si la evolución o modificación no tiene un final claro, cómo podemos realizar el tan necesario ejercicio de la planificación?

4. El triángulo de hierro: alcance, tiempo y coste. Yo no sé si llamarlo triángulo de hierro o triángulo de las bermudas (por sus agujeros negros, básicamente…). Cómo persona habituada a trabajar con negocio, para mí el alcance es el punto fundamental. Y creo que la única solución posible respecto al tema de alargar los anteproyectos es la de ¡acabar con ellos! Planteando eso sí una metodología ágil desde el principio: reunamos a desarrolladores y negocio, recojamos objetivos y necesidades, y construyamos requisitos viables para ponernos sin más dilación manos a la obra (o manos al código, en este caso). Pero es que si trabajamos así bien es cierto que volvemos a lo que comentaba en el punto 1: entonces, ¿cómo planificamos?

De todas formas, y dicho sea de paso, un planteamiento de desarrollo ágil también resolvería el tema de los análisis funcionales que se alargan, y de los que creo que es necesario cambiar por completo el concepto: muerte a los documentos, y larga vida a los wireframes de los diseñadores de interacción, o a las primeras pantallas en producción de un desarrollo ágil.

Y es que sólo cuando vemos de qué estamos hablando realmente nos ponemos de acuerdo en lo que queremos y necesitamos.

PD: Por cierto, volviendo por última vez a lo de que la mayoría de los proyectos son una evolución o una variación de un activo existente… creo que todo lo que estamos hablando aplica a proyectos «grow» y no a proyectos «transform» (o no ;)).

Responder
jose ramon21 junio, 2018 a las 10:40 am

Ufff, muchas gracias, Eva
Me encanta esta serie y me comprometo a seguirla en próximos posts
No sé si tu postdata, por empezar por algo, es también provocadora. Yo creo que en la nueva «gestión de proyectos» o lo que sea, la diferencia entre grow (evolutivos) y transform (nuevos) se diluye en la mayoría de los casos, precisamente por la interdependencia entre aplicaciones (si tocas una cosa, tocas muchas más), por la importancia de la arquitectura (no hay una arquitectura del proyecto, sino una arquitectura de empresa) y por la importancia de la gestión del cambio (el usuario no distingue entre grow y transform, creo).
Seguimos en el próximo post.

Responder
Josep Lluis Monte27 junio, 2018 a las 10:47 am

Imaginem una organització que dedica temps i esforços en definir les necessitats del negoci, mitjançant Avantprojectes, per articular un catàleg de projectes que prioritza i executa. Depenent de la complexitat de la problemàtica potser necessita força temps per a construïr un avantprojecte, potser mesos. Un cop enllestit l’avantprojecte tenim una imatge fidedigna de la necessitat a data d’ahir. El negoci canvia a cada moment i aquesta imatge no estarà en la majoria de casos alineada al 100% amb la necessitat d’avui.
Això en el millor dels casos, perquè una altra problemàtica derivada d’aquest exercici és que l’eina principal per la definició de la necessitat és la paraula escrita. Moltes Tecnològiques i consultores d’avui dia descarten tota documentació que sigui únicament narrativa. Hi ha eines que ens ajuden a mitigar (no a resoldre) l’ambigüitat intrínseca en la paraula escrita. Com va dir Quevedo: “Entre un clavel y una rosa, su majestad es*coja”

Així tenim una definició amb una possible desviació a causa del temps necessari per a construïr-la amb la intenció d’incorporar tota la problemàtica (aquí és on està la clau); i que estarà subjecta a la interpretació del lector, i de la seva orientació professional, rol en l’organització i fins i tot creences de com és la problemàtica concreta i la seva solució. Amb això no estic dient que els estudis inicials o avantprojectes no tinguin cabuda. El que dic és que depent de com es conceptualitzi l’execució d’aquesta tasca pot afectar la resta del procés, o pot fer aflorar una gestió de canvis més o menys dura

I amb això anem a definir les dues variables que ens falten en el triangle, temps i cost. I per això aquesta organització potser compta amb un proveïdor, que pot ser habitual o nou per aquest projecte. Suposem que és habitual, és a dir, que ha executat altres projectes en l’organització, i que coneix la infraestructura tecnològica, organitzativa i de dades de l’organització. Vol dir això que el proveïdor és coneixedor del negoci de l’organització? Jo crec que no. El proveïdor en tot cas és un expert en donar una solució adaptada al ventall d’eines que la propia organització posa a disposició

Amb això tenim al proveïdor construint un anàlisi, proposta comercial o de solució en base a un avantprojecte interpretat i amb una possible desviació sobre la necessitat, i que casa més o menys perfectament amb una infraestructura donada, però no necessàriament donarà una resposta completa a la necessitat plantejada. “Digue’m el que vols i faré el que entengui”

I al mig de tot això tenim a una persona que porta el pes de la gestió, i que potser en organització no saben definir si és un gestor, si és un cap, si és un controller, si és un facilitador o si és un escrivent. O si és una barreja més o menys encertada d’aquests o altres conceptes. No crec en la funció de controller. Crec que està en direcció contraria de tots els esforços dels últims anys per a definir el paper de la gestió de projectes. Crec a més que és una concepció basada en la desconfiança. Jo “direcció” no confio en la meva massa productiva, i habilito una capa intermitja de “capatassos”

Quins penso que poden ser els enunciats que poden facilitar la gestió:
Rols i responsabilitats clars
Procediment de gestió clar i públic
Ús adequat i estandaritzat de les eines
Enfocament en solucions d’increment de valor útil, utilitzable i que permeti l’adaptació al canvi

Gràcies per aquest post. És molt motivador i ha despertat en mi les ganes d’escriure, de compartir la meva opinió i d’aprendre

Responder
josé ramón29 junio, 2018 a las 8:06 pm

Gràcies a tu.
Creo que no voy a tener más remedio que contestaros, o sea seguir la converación en el siguiente post, el lunes.
Salud.

Responder
Deja un comentario