Cuentan los historiadores del tema que la gestión de proyectos que hoy conocemos comenzó en 1931 teniendo como padre a Neil H. McElroy. Aquellos primeros jefes de proyecto debían ser responsables de las “marcas” que representaban, con responsabilidad desde el seguimiento de las ventas a la gestión del producto, la publicidad, promoción, pruebas con clientes e interacción con el cliente.
El tal McElroy más tarde se convirtió en Secretario de Defensa en los USA y ayudó a fundar la NASA, potenciando la figura del jefe de proyecto y contando sus ideas en la Universidad de Stanford donde, dicen, que influyó sobre dos jóvenes llamados Bill Hewlett y David Packard.
Aquellos primeros jefes de proyectos tenían responsabilidad sobre el marketing, de entender los problemas de los clientes, de que se desarrollara correctamente un producto, etc. Sus “indicadores clave” eran coste, precio, retorno, tiempo, etc.
Y el tiempo pasó, y la gestión de proyectos llegó al mundo de la tecnología, donde el jefe de proyectos (rol que tuve la oportunidad de desempeñar en varias empresas hace años) seguía siendo el que reportaba en la jerarquía, el que priorizaba varios proyectos, el que controlaba los tiempos y los costes, el que alineaba dentro de una gran jerarquía la visión y objetivos con el equipo de desarrollo.
La definición clásica de la gestión de proyectos
Por ser un poco más concreto en qué entendemos por jefe de proyectos y gestión de proyectos, llamemos clásica, como debe haber centenares de definiciones de jefe de proyecto, gestión de proyectos, etc., he ido a por una que me lo ponía fácil, popular y conocida, la del popular “Project Management Institute” (PMI), que en su web dice así…
“A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.”
“The development of software for an improved business process, the construction of a building or bridge, the relief effort after a natural disaster, the expansion of sales into a new geographic market — all are projects.” (Esta frase “me gusta” especialmente porque vuelve a poner a los “proyectos” software al nivel de la construcción de un puente, peligrosa comparación a la que le he dedicado varios post, como aquel de El ejemplo del albañil y la estimación software y la ágil o el de Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas)
“And all must be expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need.”
“Project management, then, is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”
Menos proyecto, menos plan y más adaptación y entrega constante de valor
Como has podido leer en las anteriores frases, todas se basan en que la gestión del proyecto parte de requisitos, se entiende cerrados, para cumplir, como dicen, tiempo, presupuesto. Pero a mayor planificación inamovible y requisitos cerrados, menor innovación, y hoy tenemos claro que en servicios o negocios de base tecnológica la mayoría de los “requerimientos” deben ser cambiables, no son cerrados, son innovación, se obtienen por prototipos, por MVPs, los planes deben ser adaptables, etc.
Por ello hoy hablamos de que más que proyectos trabajamos añadiendo de manera constante valor a productos y servicios de base tecnológica, planificación clásica vs planificación ágil.
Menos “jefe” y menos “jefes”
Después de haber dejado atrás (frase con ironía) la época de las grandes jerarquías, el “comand and control”, que tenían varios problemas, mucha gente menos productividad, mucha jerarquía más lentitud, el centralizar la “jefatura de proyecto” tenía problemas de perder el poder contar con el conocimiento de la gente de “más abajo”, la que realmente sabía qué pasada, lo que llevó a la autoorganización, etc.
Por ello hoy la figura del jefe de proyecto, como rol entre super jefes y quien hace el trabajo operativo, tiene menos sentido, siendo hoy la tendencia a empresas más planas con equipos pequeños auto-organizados, gestión orientada a proyectos vs orientada a equipos (llámala ágil).
El presente – futuro de “el jefe de proyectos”
Entonces, si al jefe de proyectos, le quitamos los proyectos, las planificaciones cerradas basadas en requisitos cerrados, le quitamos, o disminuimos, su papel en la jerarquía, las jerarquías son más planas, y hacemos que el equipo tome parte en la gestión del “proyecto”, porque es más eficiente, lo que se conoce como autoorganización… ¿qué le queda al jefe de proyectos si es menos jefe, hay menos jefes y hay menos proyecto?
Pues en esas estamos, en la transformación, una más de los tiempos que corren, que, en esta ocasión llega a una figura clave y popular del mundo tecnológico, el jefe de proyectos.
En algunos sitios el antiguo jefe de proyectos pasa a ser un “Product Owner”, si bien el “Product Owner” no es un jefe de proyectos con otro nombre. En otros se le recicla a “Scrum Master”, si bien un “Scrum Master” no es un jefe de proyectos con otro nombre. En otros se le dedica a las actividades puramente “financieras” del equipo. En otros de “project manager” se pasa a “product / program manager”. En otros se le da un papel de “stakeholder” destacado, trabajando con un Product Owner. Por combinaciones y opciones que no falte.
Interesante y movido futuro al que asiste el jefe de proyectos.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Las contrataciones de programadores y analistas in-house, los de antaño, los tocapelotas que sabían del tema, son rara avis en las opulentas, colosales corporaciones. En muchos casos, muerte por inanición o prejubilación al remanente.
El paradigma del momento más in para estas empresas es la subcontratación de todo el ciclo de vida a terceros (pros y cons de esto daría para un blog completo) y … ¡voilà!, magia … la contratación de un Jefe de Proyecto, que normalmente actúa como mero controller, como mucho canalizador de requerimientos de alto nivel, más o menos negrero con el calendario sin atender a mucho a raciocinio, lo que da lugar a su vez a la participación de 1 o más alter egos en el seno de las empresas proveedoras: sus respectivos Jefes de Proyecto.
Toma simplificación.
Eso sí, marcando bien el territorio, lo que origina un brecha que, en la práctica, se abre en plena línea de flotación de cualquier intento de organización que pretenda ser ágil.
Mientras no se renueven las conciencias que ocupan las altas direcciones de estas empresas, pasando a tener un mayor peso la presencia de líderes de procedencia técnica con sensibilidad y visión estratégica de negocio, pero que sepan lo que vale un bit, que entiendan de software, mi augurio es:
Larga vida al Jefe de Proyecto convencional, poca esperanza para los ciclos de vida cortos (y calidad asociada).