El Origen de la gestión de protectos

En la década de los años 50, el desarrollo de grandes proyectos militares puso de manifiesto la necesidad de coordinación entre los equipos que trabajaban simultáneamente en la construcción de un mismo sistema. Estos proyectos, debido a su envergadura y complejidad, requerían el trabajo concurrente y sincronizado de múltiples equipos de ingenieros. Sin embargo, a menudo surgían problemas recurrentes que afectaban negativamente a estos proyectos:

• Incumplimiento de fechas: Los proyectos no se completaban dentro de los plazos establecidos, lo que generaba retrasos y dificultades en la entrega final.

• Sobrecostes de presupuesto: Los proyectos excedían el presupuesto asignado, lo que implicaba un desequilibrio financiero y una gestión deficiente de los recursos.

• Deficiencia en la funcionalidad o calidad: Los proyectos presentaban problemas en cuanto a la funcionalidad esperada o la calidad del producto final, lo que afectaba a su rendimiento y utilidad.

Ante estos desafíos, en los años 60 se empezaron a desarrollar modelos de organización y gestión que buscaban abordar y evitar estos problemas recurrentes en los proyectos. Estos modelos buscaban optimizar la coordinación entre los equipos, mejorar la planificación y seguimiento, y fomentar la eficiencia y calidad en el desarrollo de los sistemas.

Con el paso del tiempo, estos modelos evolucionaron y dieron lugar a la gestión de proyectos como una disciplina reconocida. Se establecieron estándares y mejores prácticas que permitieron un enfoque más efectivo en la gestión de proyectos, brindando herramientas y técnicas para abordar los desafíos inherentes a proyectos complejos.

Hoy en día, la gestión de proyectos se ha convertido en una habilidad clave en diversos ámbitos, no solo en el campo militar, sino también en el sector empresarial, tecnológico y de desarrollo de software. Su objetivo principal es garantizar la entrega exitosa de proyectos dentro de los plazos establecidos, el presupuesto asignado y con los niveles de calidad esperados.

En la década de los años 50, el desarrollo de grandes proyectos militares puso de manifiesto la necesidad de coordinación entre los equipos que trabajaban simultáneamente en la construcción de un mismo sistema. Estos proyectos, debido a su envergadura y complejidad, requerían el trabajo concurrente y sincronizado de múltiples equipos de ingenieros. Sin embargo, a menudo surgían problemas recurrentes que afectaban negativamente a estos proyectos: Incumplimiento de fechas: Los proyectos no se completaban dentro de los plazos establecidos, lo que generaba retrasos y dificultades en la entrega final. Sobrecostes de presupuesto: Los proyectos excedían el presupuesto asignado, lo que implicaba un desequilibrio financiero y una gestión deficiente de los recursos. Deficiencia en la funcionalidad o calidad: Los proyectos presentaban problemas en cuanto a la funcionalidad esperada o la calidad del producto final, lo que afectaba a su rendimiento y utilidad.

Gestión de proyectos predictivos

Si nos adentramos en una planificación por seguimiento, debemos considerar tres aspectos clave:

• Definición de objetivos: En esta etapa, se realiza un análisis detallado del trabajo que se debe llevar a cabo y se desglosa en tareas específicas. Esto implica identificar los requerimientos iniciales y comprender a fondo las necesidades del proyecto. A partir de este análisis, se construye un plan que involucra los recursos necesarios y el tiempo disponible.

• Planificación del trabajo: Una vez establecidos los objetivos, se procede a la planificación del trabajo. Esto implica asignar tareas a los miembros del equipo, establecer plazos y definir las dependencias entre las diferentes actividades. Es importante tener en cuenta la secuencia y coordinación de las operaciones para asegurar una ejecución eficiente.

• Ejecución y control: Durante la ejecución de las tareas, es fundamental realizar un seguimiento continuo para detectar posibles desviaciones del plan. Esto implica monitorear el progreso, evaluar el rendimiento y realizar ajustes si es necesario. El control adecuado permite mantener el proyecto en el rumbo correcto y garantizar que se cumplan los objetivos establecidos.

Este enfoque de gestión se conoce como desarrollo predictivo debido a su énfasis en el análisis detallado y la secuencia planificada de las operaciones. Permite una planificación más precisa y una mayor coordinación entre los miembros del equipo, lo que ayuda a garantizar que el proyecto se desarrolle de acuerdo con lo previsto.

Pongamos un ejemplo, nuestro amigo PMI donde nos habla de 6 fases para la dirección de un proyecto, pero que también nos da 10 áreas de conocimiento (como ellos lo denominan):
Ejecución y control: Durante la ejecución de las tareas, es fundamental realizar un seguimiento continuo para detectar posibles desviaciones del plan. Esto implica monitorear el progreso, evaluar el rendimiento y realizar ajustes si es necesario. El control adecuado permite mantener el proyecto en el rumbo correcto y garantizar que se cumplan los objetivos establecidos. Este enfoque de gestión se conoce como desarrollo predictivo debido a su énfasis en el análisis detallado y la secuencia planificada de las operaciones. Permite una planificación más precisa y una mayor coordinación entre los miembros del equipo, lo que ayuda a garantizar que el proyecto se desarrolle de acuerdo con lo previsto. Pongamos un ejemplo, nuestro amigo PMI donde nos habla de 6 fases para la dirección de un proyecto, pero que también nos da 10 áreas de conocimiento (como ellos lo denominan): Planificación del trabajo: Una vez establecidos los objetivos, se procede a la planificación del trabajo. Esto implica asignar tareas a los miembros del equipo, establecer plazos y definir las dependencias entre las diferentes actividades. Es importante tener en cuenta la secuencia y coordinación de las operaciones para asegurar una ejecución eficiente. Ejecución y control: Durante la ejecución de las tareas, es fundamental realizar un seguimiento continuo para detectar posibles desviaciones del plan. Esto implica monitorear el progreso, evaluar el rendimiento y realizar ajustes si es necesario. El control adecuado permite mantener el proyecto en el rumbo correcto y garantizar que se cumplan los objetivos establecidos. Este enfoque de gestión se conoce como desarrollo predictivo debido a su énfasis en el análisis detallado y la secuencia planificada de las operaciones. Permite una planificación más precisa y una mayor coordinación entre los miembros del equipo, lo que ayuda a garantizar que el proyecto se desarrolle de acuerdo con lo previsto. Tomemos como ejemplo el enfoque propuesto por PMI, que establece 6 fases para la dirección de un proyecto y nos presenta 10 áreas de conocimiento:

1. Integración del proyecto
2. Gestión del alcance del proyecto
3. Gestión del tiempo del proyecto
4. Gestión de los costes del proyecto
5. Gestión de la calidad del proyecto
6. Gestión de los Recursos Humanos del Proyecto
7. Gestión de las Comunicaciones del Proyecto
8. Gestión de los Riesgos del Proyecto
9. Gestión de las Adquisiciones del Proyecto
10. Gestión de los Interesados del Proyecto

Estos documentos nos brindan valiosa información para aplicar técnicas y herramientas que nos permiten registrar, ordenar, consultar y analizar dicha información. Entre estas herramientas, destacan:

• Diagrama de Gantt.
• Ruta critica.
• Plan de comunicación.
• Plan de riesgos.
• Plan de calidad.
• Plan de recursos.
• Matriz de responsabilidades.
• Minutas de reunión.

Sin embargo, es importante recordar que el trabajo del administrador de proyectos no se limita a la creación de gráficas de Gantt, presupuestos, planes de comunicación, gestión de riesgos y moderación de reuniones. Estas herramientas son solo parte del proceso y su uso puede variar según la empresa y sus necesidades específicas. La verdadera misión del administrador de proyectos radica en garantizar el seguimiento del plan establecido y lograr los objetivos propuestos de manera eficiente.

El uso de herramientas es el medio, no el fin.

Es importante procedimentar el trabajo en entornos basados en procesos, ya que esto brinda utilidad y necesidad. Sin embargo, es fundamental evitar que la rutina desvirtúe el objetivo principal de la gestión. Las organizaciones que gestionan proyectos de manera predictiva suelen contar con modelos y procesos maduros, junto con prácticas de trabajo bien definidas. El objetivo de estas organizaciones no es simplemente tener un plan dibujado en un diagrama, sino diseñar un plan que incluya la distribución adecuada de recursos y las rutas de tareas correspondientes. Los diagramas son simplemente una representación visual de ese diseño. Es crucial comprender que el trabajo de un administrador de proyectos no se limita a observar y cumplir con los pasos establecidos. Su verdadera responsabilidad es gestionar el proyecto en su totalidad. Es necesario evitar caer en la trampa de cumplir ciegamente con lo prescrito, ya que esto suele convertirse en un escudo para eludir responsabilidades cuando las cosas van mal. En ocasiones, los gestores de proyectos terminan convirtiéndose en meros cumplidores de procesos, lo cual limita su capacidad de tomar decisiones y adaptarse a situaciones cambiantes. Es fundamental fomentar una mentalidad ágil y flexible en la gestión de proyectos, donde se valore la toma de decisiones basada en el contexto y las necesidades específicas del proyecto. Esto permitirá obtener resultados más efectivos y evitará que los procesos se conviertan en obstáculos en lugar de herramientas facilitadoras.

Es importante evitar ciertas ideas erróneas, como considerar que los subproductos de la gestión son únicamente responsabilidad del administrador, asumir la obligación de controlar cada aspecto del trabajo de los equipos o transmitir al equipo una cultura excesiva de cumplimiento a expensas de la innovación y la adaptabilidad. Un enfoque más efectivo implica fomentar la responsabilidad compartida, la colaboración y la creatividad, permitiendo que cada miembro del equipo se sienta empoderado y comprometido con el éxito del proyecto.

Los subproductos no son deberes

Considerar los requisitos, la planificación, los informes y los registros como meras tareas escolares u obligaciones del administrador puede llevar a subestimar su importancia y relegarlos a un mero cumplimiento de obligaciones laborales. Este enfoque no refleja la verdadera naturaleza de estos subproductos, ya que su correcta elaboración y gestión son fundamentales para el éxito del proyecto. Para evitar caer en este error, es necesario que tanto el departamento de calidad como el de procesos sean conscientes del riesgo que implica una cultura del cumplimiento. Estos departamentos tienen un compromiso con los valores culturales de la empresa y desempeñan un papel clave en la prevención de esta mentalidad. Su función consiste en promover una cultura en la que el diseño, el plan y la administración sean vistos como elementos esenciales para alcanzar la excelencia, en lugar de meros requisitos burocráticos. En lugar de centrarse únicamente en escribir y registrar según las normas establecidas, el enfoque debe ser buscar constantemente la mejora y encontrar la solución que mejor se adapte a cada caso específico. Se trata de alcanzar un nivel de calidad y eficacia óptimo en todos los aspectos del proyecto, aprovechando al máximo los recursos disponibles y aplicando mejores prácticas en cada etapa. Al fomentar una cultura que valora la excelencia en lugar del simple cumplimiento, se logrará un ambiente de trabajo en el que los subproductos del proyecto sean vistos como herramientas poderosas para el éxito y no como simples tareas rutinarias. Esto permitirá aprovechar al máximo su potencial y contribuirá a la realización de proyectos exitosos y satisfactorios.

Administrar no implica controlar

En la gestión de proyectos predictiva, el administrador diseña y traza el plan, asumiendo la responsabilidad de su cumplimiento. A diferencia de la gestión ágil, no es necesario que el administrador sea un experto en la tecnología utilizada en el desarrollo. Los administradores que se centran en el control no suelen formar parte integrante de sus equipos, ni suelen participar en las decisiones técnicas. En cambio, tienden a sentir una propiedad exclusiva sobre el plan y se responsabilizan de su ejecución, adoptando una postura de control y manteniendo un orden jerárquico. Si bien este enfoque puede ser adecuado en entornos industriales, donde los procesos y la tecnología son los principales valores, puede generar un ambiente de trabajo que limita el potencial del talento personal en proyectos de desarrollo de software.

La cultura del cumplimiento puede ser contagiosa

La cultura del cumplimiento puede tener un impacto significativo en la forma en que se desarrollan las tareas y proyectos. Cuando se prioriza el cumplimiento de las normas y los procedimientos sobre la eficiencia y la calidad de los resultados, se corre el riesgo de generar una cultura en la que las formas se vuelven más importantes que los objetivos finales. Es fundamental tener en cuenta que la cultura del cumplimiento puede ser contagiosa dentro de una organización. Si se fomenta constantemente la idea de que seguir las reglas y cumplir con los procedimientos establecidos es lo más importante, es probable que los empleados adopten esa mentalidad y se enfoquen más en cumplir con las formalidades que en lograr resultados óptimos. Es importante recalcar que la cultura del cumplimiento puede limitar la capacidad de innovación y adaptación al cambio. Cuando se enfatiza en exceso el cumplimiento de normas y procesos, puede resultar difícil para los equipos de trabajo encontrar soluciones creativas y flexibles para abordar los desafíos y aprovechar las oportunidades. Por tanto, es crucial encontrar un equilibrio entre el cumplimiento de las normas y la búsqueda de resultados excepcionales. En lugar de enfocarse únicamente en seguir los procedimientos, es importante fomentar una cultura en la que se valoren la eficiencia, la calidad y la innovación. Esto implica dar a los empleados la libertad y la confianza necesarias para tomar decisiones informadas y encontrar formas más eficientes de lograr los objetivos establecidos.

Gestión ágil

En el desarrollo de productos, los negocios necesitan diferentes modelos para su desarrollo, pero debemos entender que las circunstancias de los mercados y las empresas no se pueden cambiar, y es la gestión de los proyectos la que debe adaptarse y responder a estas nuevas necesidades. Son las empresas las que acuden a los expertos con descripciones abiertas, y son estos mismos los que suelen pedir descripciones cerradas para poder ofrecerles garantías de cumplimiento de un plan. Pero es ahora el poder desarrollar y construir un producto a la par de la investigación y el descubrimiento de los requisitos para lograr una capacidad de adaptación al cambio que dicta el entorno. Siendo el cliente el poseedor de la visión del producto motivado por la novedad, el valor de la innovación y la velocidad necesaria a la que se debe mover el escenario tecnológico junto con el negocio hacen imposible que se pueda detallar cómo será el producto final. Y ya que estamos hablando de innovación, aquí están dos tazas. En estos momentos, ya no hablamos de sacar un producto final, sino que en su mayoría se lanza un producto beta o “producto mínimo viable”. La gestión ágil nació de las empresas que pudieron dar una respuesta a sus propias demandas, entre las cuales destacó el valor al producto, la reducción en los tiempos de desarrollo, tener una respuesta rápida y flexible a cambios, pero sobre todo, poder tener resultados fiables, ya que la permanencia de las empresas de entornos ágiles en el mercado está dado por la capacidad de innovación continua. En una gestión predictiva, cada equipo realiza solamente la fase de la cual tiene una especialización con la información que requiere, el resultado es entregado al siguiente equipo hasta terminar con la línea de producción. En la gestión ágil todo el trabajo es realizado por un equipo multidisciplinario y de una forma continua, en este contexto, el equipo requiere que la información del proyecto sea compartida entre todos y no solo a un par de personas. Estamos hablando que un proceso típico aborda el desarrollo por fases, cada persona o departamento son diferentes, aquellos que están encargados de los requisitos de dedican a describir funcionalidades del sistema, de esta forma el analista diseña dicho sistema que, el área de desarrollo tiende a traducir a código. Todo ese trabajo se integra para hacer la ejecución de pruebas según las indicaciones del documento de análisis. Cuando el cliente ve el producto, esté ya está cerrado, cualquier sugerencia que pueda surgir quedará fuera del proyecto. Pero hablemos de tiempo, ya que en la década de 1990, la media de un nuevo producto era de 35 meses, y muchas empresas daban la vida por tener algo en menos tiempo. Las estrategias que se dieron gracias a la naciente gestión ágil pudieron tener una media de 11 meses, esto se logró por la entrega temprana de los primeros incrementos funcionales de un producto, partes que contenían las necesidades más urgentes del cliente, y eso pudo lograr que el lanzamiento de un producto fuera en el menor tiempo posible. Al tener una completa flexibilidad de incorporar cambios y mejoras de forma continua, una capacidad que el modelo predictivo carecía, la innovación continua se volvió un verbo, los productos no tenían que vender su innovación en su ventana de lanzamiento, rezando que la competencia lanzara algo mejor que ellos, ahora los productos tenían la capacidad de ser adaptables, de evolucionar junto al mercado, podrán tener modificaciones, actualizaciones. Ahora podias plantarte frente a frente con tu competencia y luchar por ser mejor que ellos olvidándote de la innovación radical. Ya no tenias que predecir los resultados, ahora podías que adaptar el resultado. Y es aquí donde el patrón del ciclo de vida del modelo de desarrollo se rompe para dar paso a un nuevo ciclo de vida ágil

• Concepto
• Especulación
• Exploración
• Revisión
• Cierre

Este ciclo de vida es el que más tarde se usará para crear el concepto de “producto mínimo viable”, un concepto que acuñara Frank Robinson y se volverá popular gracias a al emprendedor Steve Blank y el empresario Eric Ries. En este ciclo de vida se crea una visión de producto o servicio que se pretende ofrecer y el alcance del proyecto. Se selecciona al equipo de personas que lo llevará a cabo. Una vez que se tiene esta visión de lo que se quiere conseguir, el equipo especula y construye hipótesis, recordemos que la visión suele ser muy general como para determinar requisitos, un diseño o incluso costes. En esta etapa es donde se determinan las limitaciones impuestas por el entorno del negocio, como la agenda o los costos, y se determina la primera aproximación de lo que se puede producir. Durante el desarrollo se afronta la realidad de lo que se va obteniendo. La etapa de especulación se va repitiendo en cada iteración del desarrollo teniendo como referencia la visión y el alcance del producto. Durante cada iteración se determinan las funcionalidades para el siguiente incremento del producto, y si la organización lo requiere, también se genera información administrativa y financiera. En el momento de la revisión, el equipo y los usuarios pueden ver las funcionalidades realizadas hasta ese momento, y eso les da la ventaja de poder alinear la dirección de sus objetivos de ser necesario. Y al llegar a la fecha de entrega del producto, este es lo que se esperaba gracias a la continua interacción del cliente. Mientras la influencia de la gestión ágil sigue moviéndose al mainstream, el legado de la gestión de proyectos sigue siendo evidente, fue el puente entre proyectos los proyectos estructurados y la primera piedra de lo que hoy es esta disciplina.

El manifiesto ágil llegaría en una época de cambios y renovaciones, pero una década antes tendríamos un par de metodologías enfocadas al desarrollo de software que bebieran de la gestión ágil, en 1986 nacería scrum, y en 1995 saldría su versión para el desarrollo de software, ese mismo año saldría feature-drive development, que propondría un modelo global y un desarrollo basado en lista de funcionalidades. Extrem Programming saldría un año después, y resaltaría la simplicidad, la comunicación y la retroalimentación como valores de su propia visión del desarrollo ágil.

Pero el verdadero salto llegaría de la mano de Kent Beck, creador de la programación extrema, de la mano de 16 individuos mas que estaban cansados de la gestión predictiva en el área del desarrollo de software.