Yo trabajo en el mundo de la tecnología informática y aquí el uso de la gestión de proyectos es un asunto fundamental, como lo es en ingeniería, en medicina, en arquitectura, en construcción de obras civiles o en la creación de un plan de educación estatal.
En este campo, el desarrollo de software es un campo muy jóven y está sufriendo muchos cambios en lo que es la gestión del ciclo de vida del producto o servicio que construyen, no en la gestión de proyectos.
En este punto, hay muchas filias y fobias en lo que respecta la gestión de proyectos y el uso en la construcción de software. Yo creo que no es para tanto y que para entender mejor el asunto es fundamental poner en contexto las cosas.
Para ello, me gustaría repasar primero un poco de historia para ganar un poco de contexto y perspectiva.
Un poco de historia
De la antiguedad hasta finales del siglo XIX.
La gestión de proyectos ha existido durante miles de años y estuvo involucrada en la planificación, coordinación y construcción de las Antiguas Maravillas del Mundo. Se reconoce que en el antiguo Egipto se tenía una serie de formas de gestión de la construcción muy básicas.
Después es por todo reconocido la capacidad de planificación y coordinación de construcciones realizadas por los Romanos. Sus calzadas son un ejemplo de ello.
La construcción de edificios, catedrales, acueductos comenzaron requerían de una planificación y de gestión de recursos, por no hablar de que requerían de un sponsor que promoviera esas aventuras.
De lo que he podido leer, el Ferrocarril Transcontinental se considera la primera empresa de gestión de proyectos a gran escala. El Ferrocarril Transcontinental fue un factor clave en el desarrollo industrial de los Estados Unidos, pero la gente a menudo olvida el verdadero alcance de este proyecto. Incluyó atravesar terrenos traicioneros y desafiar condiciones climáticas peligrosas para construir una línea de ferrocarril y telégrafo.
Pero yo creo que antes en la revolución industrial que se llevó a cabo en Inglaterra tuvo que haber muchas consideraciones de planificación y de movilización de recursos que hicieron que todo el conocimiento técnico que se estaba desarrollando se pudiera llevar a cabo a escala.
Además, durante la revolución industrial, a medida que el siglo XIX avanzaba, las empresas comenzaron a hacer frente a los retos de las leyes y reglamentos laborales del gobierno.
Comienzos del Siglo XX
En 1911, Frederic Taylor publicó un libro, «Los principios de la gestión científica», basado en su experiencia en la industria del acero. Uno de los temas centrales del libro es la división funcional, y la especialización para poder dar trabajo específico a personas poco cualificadas. También identificó la necesidad de crear sistemas salariales basados en incentivos y aprovechar las técnicas para ahorrar tiempo.
Después de la Segunda Guerra Mundial, la gestión de proyectos comenzó a usar las matemáticas para mejorar la ejecución de estas iniciativas. Las más populares son: la técnica de revisión de la evaluación del programa (PERT) y el método de la ruta crítica (CPM).
En los años 50 – 70 la industria aerospacial y de defensa fueron muy importantes y de ellas surgieron muchas mejoras tecnológicas, una de ellas fue la creación en 1975 de una organización sin ánimo de lucro que después fue el PMI, reconociendo la necesidad de la profesionalización de la gestión de proyectos. El primer PMBOK se publicó en 1996. En Inglaterra el marco de trabajo Prince 2 fue creado en 1989.
Separar la gestión del proyecto del ciclo de vida de lo que se construye
La construcción de un ferrocarril requiere de técnicas distintas a la fabricación de un cohete o al desarrollo de una aplicación de software. Todo el mundo conviene que la construcción y el desarrollo de una especialidad tiene su propia naturaleza y por ello son los especialistas en estas áreas de conocimiento los que son capaces de hacer evolucionar las propias áreas de conocimiento.
Al fin de al cabo estos son prácticas distintas que evolucionan de manera distinta y en momentos distintos.
Las prácticas fueron apareciendo desde la antigüedad hasta nuestros días y las nuevas se han beneficiado de las más antiguas para evolucionar y progresar. Este mapa es una propuesta, probablemente muy inexacta, de la evolución de las prácticas principales:
Todas estas prácticas siguen evolucionando individualmente y en conjunto (lo que podríamos llamar «progreso»). Esto no está reñido con que es necesario gestionar los recursos, los objetivos, la planificación, riesgos, calidad…. de la iniciativa que sea. La gestión de proyectos es también una práctica y se tiene que adaptar al contexto donde se aplica.
Las prácticas se han alimentado de otras prácticas y han crecido gracias a estas otras. La ingeniería electrónica no hubiera sido posible sin la ingeniería eléctrica por ejemplo, y ambas hoy en día evolucionan hacia sitios diferentes.
La gestión de proyectos como práctica
La gestión de proyectos se ha ido alimentando de todas las prácticas con las que ha convivido y ha ido evolucionando con respecto ha sido necesario en cada etapa de la historia. Los círculos en azul dibujan aspectos de la gestión de proyectos que fueron apareciendo conforme esas prácticas aparecían y evolucionaban.
¿cuáles son esas características de la práctica de gestión de proyectos que fueron naciendo? Pues mi limitado entendimiento estas son algunas de ellas:
La propia naturaleza de la gestión de proyectos hace que su campo de alcance sea limitado. Quiero decir que un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único, y por tanto cuando una práctica decide llevar a cabo una construcción de manera continua: coches, transistores, cables, software, etc. entonces la gestión de la operativa pasa a otras manos, existiendo en esa operativa en cadena aspectos similares como la gestión del coste, de la planificación, del riesgo, etc.
La representación de esto podría ser algo así:
En el mapa dejo vacío la parte izquierda del mapa, la de la génesis. En la génesis se inventa, se moldea algo nuevo, que no existe. Se intentan cosas nuevas, y normalmente, a menos que sea en un entorno altamente controlado, la gestión de proyectos no es muy útil. Alguien podrá decir que existen muchos proyectos de innovación, de investigación y desarrollo y con una entidad suficiente como para necesitar de una gestión de proyecto, y es así, pero pero no es la inventiva de algo radicalmente nuevo. Por ejemplo, no podemos tomar como génesis a un laboratorio farmaceútico que se dedica industrialmente a crear nuevos fármacos; yo consideraría esta una actividad industrializada y que está diseñada y gestionada para sacar adelante y desechar productos conforme un ciclo de vida determinado y definido.
Conflictos con otras prácticas
En cualquier cosa, el paso de una etapa a otra conlleva cambios y estos son cambios disruptivos no ajenos a conflictos y a problemas.
Para empezar existe una inercia, y esta inercia hay que romperla. Cuando Henry Ford trató de poner en práctica sus ideas de fabricación en cadena hubo detractores a la idea que apoyaban que la construcción de un automóvil era una tarea para personas multidisciplinares. La historia nos enseña que el señor Ford se salió con la suya y rompió esa inercia sin paliativos.
En las prácticas nuevas como el desarrollo del software en los años 2000-2010 se pasó de un modelo de producto a un modelo de operaciones, esto fue dio un crecimiento exponencial a muchas empresas tecnológicas, especialmente en Estados Unidos. Estas empresas dieron el salto hacia un modelo de desarrollo del software más evolucionado.
Pero en ámbitos menos evolucionados y con herencias del pasado fuertes todavía en 2021 existen ámbitos del desarrollo del software donde las prácticas de desarrollo de producto están muy arraigadas, y no la de desarrollo continuo.
La barra vertical negra representa una barrera, un obstáculo que hace que no puedas evolucionar por la inercia que te lleva a hacer las cosas de una manera erronea: ya sea por la referencia del pasado, o por el desconocimiento de una manera diferente de hacer las cosas. Romper esa inercia suele ser complejo y no podemos subestimarla, especialmente en grandes organizaciones.
En este conflicto, la gestión de proyectos a veces se percibe como un elemento de inercia negativo y son los líderes de las organizaciones los que tienen que identificar que tienen que dar el paso hacia adelante y evolucionar hacia un modelo diferente y que tenga más sentido para la práctica en cuestión.
Esto se ha dado a lo largo de la historia en todos los ámbitos de la vida. Por recordar algunos, uso una tabla prpuesta por Simon Wardley:
Para terminar
Es interesante de vez en cuando mirar las prácticas como entes que evolucionan y entender los puntos de conexión y la propia evolución de las mismas. Yo he intentado hacerlo con una que conozco, que es la gestión de proyectos.