Tal y como vimos el ciclo de vida del proyecto es el conjunto de fases en la que este se organiza. Dependiendo de la organización y solapamiento entre las fases, se pueden diferenciar varios modelos de ciclo de vida del proyecto que van desde el enfoque predictivo o clásico, donde el producto y los entregables se definen al comienzo del proyecto, pasando por el ciclo de vida iterativo o incremental, que definen fases que van incrementando el producto, hasta el ciclo de vida adaptativo o ágil, donde el producto se desarrolla tras múltiples iteraciones y el alcance detallado para cada iteración se define solamente en el comienzo de la misma.

Ciclo de vida predictivo, clásico u orientados a la planificación

Los ciclos de vida predictivos (también conocidos como clásicos u orientados a la planificación) son aquellos en los cuales el alcance, plazo y costo se determinan lo antes posible en el ciclo de vida del proyecto y los esfuerzos se orientan a cumplir con los compromisos establecidos en cada uno de estos factores.

Normalmente estos proyectos se organizan en una serie de fases secuenciales o consecutivas, donde cada una de las fases se enfoca en un subproducto o actividad concreta. Normalmente el trabajo de una fase es muy diferente al del resto y por lo tanto el equipo de proyecto va variando dependiendo de las fases.

Al inicio la dirección del proyecto se centra en definir el alcance y definir un plan detallado de las actividades necesarias. A partir de aquí la dirección del proyecto orienta su trabajo a cumplir con la planificación. Cualquier cambio en el alcance del proyecto se debe gestionar de forma explícita y, habitualmente, conlleva la revisión de la planificación y la aceptación formal del nuevo plan.

Se opta por ciclos de vida predictivos cuando el producto a entregar está bien definido y existe un conocimiento bastante amplio sobre la forma de construir el producto. Este ha sido el modelo de trabajo más habitual, aunque no por ello se ajusta a las circunstancias de todos los proyectos y organizaciones.

Ciclo de vida iterativo e incremental

Los ciclos de vida iterativos e incrementales son aquellos en los cuales se repiten las actividades del proyecto en fases o iteraciones y en cada una de ellas se aumenta el entendimiento del producto por parte del equipo del proyecto. Las iteraciones desarrollan el producto a través de una serie de ciclos repetidos que van añadiendo sucesivamente funcionalidad al producto.

Al final de cada iteración, se habrá completado un entregable o un conjunto de entregables. Las futuras iteraciones pueden mejorar dichos entregables o crear nuevos. El producto final será la acumulación de funcionalidades construida en las iteraciones.

Se opta por los ciclos de vida iterativos e incrementales cuando es necesario gestionar objetivos poco definidos o de una alta complejidad o cuando la entrega parcial del producto es clave para el éxito. Este tipo de ciclo de vida permite al equipo del proyecto incorporar la retroalimentación e ir incrementando la experiencia del equipo durante el proyecto.

Ciclo de vida adaptativo o ágil

Los ciclos de vida adaptativos, también conocidos como métodos orientados al cambio o métodos ágiles, responden a niveles altos de cambio y a la participación continua de los interesados.

Existen dos modelos básicos para este tipo de ciclos de vida, aquellos centrados en el flujo (por ejemplo, Kanban) y otros centrados en ciclos iterativos e incrementales (por ejemplo, Scrum). En el primer caso se establecen limitaciones muy claras sobre la concurrencia de actividades (Work in Progress) y en el último las iteraciones muy rápidas (entre 1 y 4 semanas) donde se realiza el trabajo (Sprint).

Habitualmente en los modelos ágiles el alcance global del proyecto será descompuesto en un conjunto de requisitos o trabajos a realizar (en ocasiones denominado Product Backlog). Al inicio de una iteración el equipo define las funcionalidades que serán abordadas en ese ciclo. Al final de cada iteración el producto debe estar listo para su revisión por el cliente. Este tipo de ciclo de vida requiere de equipos muy involucrados que incluyan al patrocinador o al cliente para proporcionar continua retroalimentación.

Generalmente se opta por los métodos ágiles en entornos que cambian rápidamente, cuando el alcance es confuso o cuando la aportación de valor es muy cambiante y con equipos altamente involucrados.

Proverbio danés.

Vivimos en un mundo lleno de acrónimos, conceptos, tecnologías y dispositivos que cambian rápidamente. Lo que creíamos conocer desaparece y rápidamente es reemplazado por un nuevo modelo, un nuevo paradigma o un nuevo concepto que debemos aprender. En este constante devenir nos cuesta reconocer que no conocemos un nuevo término, una nueva idea o unas nuevas siglas.

Cuando uno domina una materia se olvida con rapidez de que alguna vez fue un ignorante. Nadie nació sabiendo, todos hemos tenido que aprender, desde niños hemos aprendido a andar, a hablar, a pensar. Pero todo este proceso se nos ha olvidado, ya no recordamos cuando no sabíamos algo, parece como si siempre hubiera estado ahí ese conocimiento. Nos convertimos en inconscientemente competentes.

Ya decía Sócrates que “Sólo sé que no sé nada”, siendo este el primer principio de la sabiduría. Reconocer nuestra ignorancia es el primer paso para el aprendizaje. Preguntar el significado de un nuevo término, preguntar que significa un nuevo concepto o para que sirve una nueva idea es el medio para aprender.

En la gestión de proyectos -ámbito que ha sido bastante estable durante algún tiempo- ha aparecido una nueva corriente de metodologías y modelos denominados ágiles que traen todo un nuevo conjunto de términos, expresiones e ideas que -reconozcámoslo- tenemos que aprender. Algunos ya llevan tiempo en trabajando con éxito con estos modelos, si bien es ahora cuando se están extendiendo en todo tipo de organizaciones.

No nos avergoncemos por preguntar y en reconocer que no sabemos. Esta es la única forma en la que podremos aprender realmente. Si alguien nos habla de Kanban, Scrum, WIP, Sprint o Product Backlog y no sabemos que significa, preguntemos sin rubor. Todos estos nuevos conceptos esconden grandes posibilidades para la gestión de proyectos y no debemos perder la oportunidad de aprender sobre ellos, ya que de su conocimiento podrá surgir el aprovechamiento de esta nueva forma de hacer las cosas.

Seamos valientes y adentrémonos en terreno desconocido. Salgamos de nuestra zona de confort y no temamos en preguntar a quienes ya han recorrido parte del camino. Recordemos siempre que a quien teme preguntar, le avergüenza aprender.

Un interesado es un individuo, grupo u organización relacionado con el proyecto de alguna forma. Los interesados pueden afectar, verse afectados o percibirse a sí mismos como afectados por una decisión, resultado o actividad de un proyecto. En ocasiones no es sencillo identificar a todos los interesados en un proyecto, sobre todo si lo son de forma indirecta.

El interesado puede participar en el proyecto o tratar de influir al equipo para que el resultado final satisfaga sus intereses o necesidades. Por ello, en ocasiones los intereses y expectativas entre diferentes interesados por el proyecto pueden estar enfrentados, lo que es susceptible de generar conflictos dentro del desarrollo del mismo. El líder del proyecto debe ser capaz de gestionar estas expectativas.

El grupo de interesados lo componen los miembros del equipo del proyecto y todas las personas y entidades interesadas, ya sean internas o externas. Normalmente el equipo del proyecto divide a estos en internos y externos, negativos y positivos, ejecutores y asesores. Realizar un mapa de interesados en el proyecto es una buena práctica que permite hacer explícita las relaciones de los diferentes actores con el equipo y su tipo de relación.

Una de las funciones del director de proyecto es mantener equilibradas las expectativas de todos los interesados, para que el proyecto no se vea desbordado, y ser capaz de gestionarlas adecuadamente. La relación con el proyecto pueden ir cambiando a lo largo del ciclo de vida y por lo tanto su identificación y gestión debe ser realizada de forma continua. La participación de un interesado puede ser total, intermitente o puntual, por lo que es asimismo deber del equipo del proyecto identificar a tiempo a los interesados, cooperando con ellos de manera profesional y gestionando las expectativas e intereses. No hacerlo en el momento adecuado puede llevar a retrasos, aumentos de presupuesto, pérdida de calidad, problemas en la aceptación de entregables, etc.

Ejemplos de interesados en un proyecto son:

• Equipo de trabajo

• Patrocinadores

• Clientes y usuarios

• Vendedores

• Socios de negocios

• Departamentos de la organización

• Proveedores

• Clientes

• Otros interesados

Cuando se analiza un producto y se observa que hay elementos de baja calidad, gran cantidad de problemas de diseño o construcción, y cuesta comprender cómo se ha construido, es muy probable que sea debido a que fue construido en un proyecto cuya planificación ha sufrido importantes tensiones. Esto es así en todo tipo de productos, tanto en ingeniería, construcción, software o creatividad. Cuando hay presión en los plazos o se aumentan los costes, o se reduce el alcance o se sacrifica la calidad.

Cuando la planificación se ve desbordada el primer elemento que se sacrifica es la calidad. Se tiende a no hacer las cosas bien, a tomar atajos y caminos que aparentemente son más cortos y que permitirán responder a los plazos de entrega con mayor facilidad. En ocasiones estas medidas no resuelven de forma efectiva el problema de plazos que nos encontramos, pero es difícil evitar que se tomen estas medidas, tanto de forma consciente, como de forma inconsciente por el equipo. Un equipo presionado tiene tendencia a no comunicar los problemas y a ocultar las deficiencias del producto.

Los problemas aparecen después, en las fases de implantación y mantenimiento. Las prisas ya se han pasado, pero los problemas en el producto están ahí, esperando a que alguien los descubra y tenga que resolver las deficiencias. En cuanto es necesario hacer alguna adaptación o un simple mantenimiento rutinario, saltan los problemas, el producto deja de funcionar o lo hace de forma deficiente, pero esto -normalmente- es problema del equipo de mantenimiento.

Este es un hecho que no siempre se puede evitar. Las tensiones en la panificación son, desgraciadamente, más habituales de lo que gustaría reconocer. Cuando el producto esconde problemas debemos ser claros y documentar estos problemas, no esperar que salten sin avisar en fases posteriores. Si se es consciente de que hay un problema es posible gestionarlo. Debemos pensar en los equipos de implantación y mantenimiento y no sólo en terminar el proyecto de cualquier forma.

Tenemos que recordar siempre: "las prisas pasan, los problemas quedan".

La gobernabilidad del proyecto es el marco en el que se engloban las pautas, procesos, modelos de toma de decisiones y herramientas para llevar a cabo el proyecto.

Cada organización debe ajustar este marco general a las políticas y modo de gobierno que tenga implantados. El proyecto se realiza dentro de una organización y debe estar alineado con la forma en la que se toman las decisiones y con la cultura empresaríal donde va a ser desarrollado.

Este marco de gobernabilidad del proyecto debe ser revisado a lo largo del ciclo de vida del mismo por el director y equipo de proyecto, siendo en ocasiones necesario ajustar su modelo dependiendo de las circunstancias, evolución y experiencia obtenida.

Este es un elemento especialmente crítico para proyectos grandes y complejos, ya que proporciona un método coherente que aporta definición, documentos, herramientas y comunicación de prácticas fiables y repetibles dentro del proyecto. Define asimismo roles y prueba la eficacia del director del proyecto, dejando siempre un marco para la toma de decisiones.

La gobernabilidad del proyecto involucra a interesados, políticas, procedimientos, herramientas, estándares, responsabilidades y autoridades documentadas. A pesar de que el marco en el que se desarrolle el proyecto ayuda a la gobernabilidad del mismo, el equipo continúa siendo responsable de la planificación, la ejecución, el control y el cierre.

Algunos ejemplos de elementos del marco de gobernabilidad de un proyecto que nos ofrece el PMBOK son:

Criterios de éxito del proyecto y de aceptación de los entregables

• El proceso para identificar, escalar y resolver incidentes que puedan surgir durante el proyecto.
• Las relaciones entre el equipo del proyecto, los grupos de la organización y los interesados externos.

El organigrama del proyecto que identifica los roles del mismo

• Los procesos y procedimientos para la comunicación de información.
• Los procesos para la toma de decisiones del proyecto.
• Las guías para alinear la gobernabilidad del proyecto con la organización.

El enfoque del ciclo de vida del proyecto

• El proceso para la revisión de fases o cambios de etapas.
• El proceso para la revisión y aprobación de cambios en el presupuesto, el alcance, la calidad y el cronograma.
• El proceso para alinear a los interesados con los requisitos del proyecto.

Frase atribuida a John Ruskin

La calidad no es gratis, no es algo que surge porque sí. Requiere planificación, esfuerzo e inversión, es decir, debe ser gestionada. Podríamos en pensar que la calidad es algo de lo que no es necesario hablar, que es algo implícito y que cualquier profesional debe tener calidad en su trabajo y en sus productos. Es algo que se presupone en muchos casos y puede llegar a ser un error que, en ocasiones, se paga muy caro.

La calidad es rentable y merece la pena invertir en ella. El coste de la no calidad es alto. Situar nuestros servicios o proyectos con un alto nivel de calidad es rentable a medio y largo plazo, ya que la diferenciación de los servicios y productos permite aumentar el precio, retener a clientes satisfechos y conseguir nuevas oportunidades por medio de las recomendaciones. Por contra, gestionar el descontento de los clientes y usuarios, así como corregir errores, es caro.

Las variaciones o desviaciones en el alcance, esfuerzo o plazo afectan directamente en la calidad. Hay una cierta tendencia a pensar que en los proyectos sólo se producen variaciones de alcance, esfuerzo o plazo, pero lo cierto es que cuando alguno de estos factores tiene variaciones o desviaciones es muy común sacrificar la calidad, sin ser siempre conscientes de ello. Hacer el mismo trabajo con menos plazo o con menos recursos, hacer más trabajo sin aumentar el plazo y el coste, o que se produzcan errores en la planificación y estimación, afectan directamente a la calidad del proceso y la calidad del producto.

Aunque no nos guste oírlo, la calidad es negociable. No todos los productos requieren la misma. Los productos y servicios que utilizamos cada día tienen diferentes niveles. Todos los sabemos cómo consumidores o usuarios. Los productos y servicios de bajo coste o bajo precio conllevan una menor exigencia y, en ocasiones, los compradores están dispuestos a aceptar esta menor calidad por un menor precio. Definir el nivel de calidad es una buena idea, ya que permite gestionar adecuadamente las expectativas y realizar una gestión activa para alcanzar el nivel de calidad acordado.

La calidad se debe gestionar y es, por lo tanto, un elemento clave en la gestión de nuestros proyectos. Tanto la calidad del proceso, es decir, en la gestión del proyecto, como la calidad del producto, es decir, de los entregables que va a generar el proyecto, deben ser gestionados de forma activa, medidos y planificados.