La complejidad de un proyecto puede depender de diferentes factores como, por ejemplo:

• Requisitos poco definidos, ambiguos, incompletos, poco maduros o cambiantes.
• Tecnologías nuevas, inestables o con muchos elementos diferentes a integrar.
• Personas trabajando juntas con diferentes habilidades técnicas, experiencia, formación, valores, motivaciones, inteligencia, habilidades sociales, de skills de relaciones interpersonales [1], de enfoques de gestión [2], diferentes vidas personales, disponibilidad, diversidad de criterios, … y todo esto en organizaciones con culturas determinadas que pueden estar más cerca o más lejos de la manera natural de trabajar de cada una de estas personas.

• Asume que es posible predecir y detallar a largo plazo las variables del proyecto (requisitos, planificación y recursos/coste, relacionados directamente con la calidad del producto en el Triángulo de hierro). Se intenta solucionar la complejidad de un proyecto esforzándose en una planificación detallada. Dado que se firman contratos en función de los requisitos iniciales del proyecto, el objetivo principal a lo largo de todo el proyecto será entregar esos requisitos iniciales que fueron firmados, incluso los que aportan un valor ínfimo o los que apenas serán utilizados, no los que el cliente realmente necesitará una vez se le entregue el proyecto. Para no desviarse de la predicción inicial, este proceso necesita de un férreo control de cambios de requisitos.
• Se realiza un desarrollo en cascada del proyecto con la secuencia típica de actividades de recogida de requisitos, análisis, diseño, desarrollo, pruebas y aceptación por el cliente («waterfall»).
  • La comunicación con el cliente sobre el resultado a entregar se basa en la elaboración de un documento de análisis que incluye todo el alcance del proyecto. Este dcoumento ha sido realizado por una o varias personas a tiempo completo y se prentende que el cliente (que también se dedica a otras tareas) lo valide en un tiempo muy corto, con el riesgo de que esta validación se realice de manera superficial (y que al final lo que se desarrolle no sea correcto). Adicionalmente, se añade el problema de que puede ser difícil para el cliente imaginarse y entender de un golpe cómo será todo el sistema.
  • La comunicación entre los miembros del equipo se puede ver disminuida al basarse en documentos donde se detalla el paso del “testigo” de cada actividad (un enfoque que puede resultar muy burocrático y poco eficiente respecto a producir el valor real que necesita el cliente, el producto que finalmente se le entregará). Este paso de “testigos” tampoco facilita que haya una responsabilidad común del proyecto a nivel de equipo.
  • El cliente no puede aprovechar los resultados del proyecto (o de una fase de varios meses) hasta que no se ha realizado toda la secuencia de actividades, con lo que después de este tiempo el contexto del proyecto puede haber cambiado. Dado que es la primera vez que el cliente ve los resultados reales del proyecto, puede ser necesario realizar cambios para poder satisfacer sus necesidades, retardándose la entrega más de lo que se predijo.
• El proyecto está preparado para ser entregado hacia su final (o al final de una fase de varios meses), momento en que riesgos y tareas no previstos afloran, retardando la entrega, obligando al equipo a sobreesforzarse y comprometiendo la calidad, con la consecuente insatisfacción del cliente.

• Asume que hay un horizonte de predicción de las variables del proyecto dado que siempre hay cambios en el contexto del proyecto debido a la indeterminación y complejidad propios. Para gestionar la complejidad y obtener el mayor valor posible, el proceso de control del proyecto debe ser empírico, basado en inspección y adaptación regular en función de los resultados que se van obteniendo y del propio contexto del proyecto (de manera similar a como funciona el control de procesos industriales, o siguiendo el ciclo de mejora continua PDCA de Deming). Al cliente le resulta más sencillo ir entendiendo el producto que necesita conforme se va desarrollando, cosa que le implica un esfuerzo menor cada vez que debe tomar decisiones.
  • Como ejemplo de adaptación, los requisitos a desarrollar en la siguiente iteración dependen del conocimiento que el cliente va adquiriendo acerca del proyecto, de la velocidad de desarrollo, de las demandas del mercado, de los movimientos de los competidores, etc. Los requisitos «emergen» y es necesario adaptarse a ellos.
• Aunque en principio parece que un control empírico tiene un coste adicional respecto a utilizar un proceso predictivo, en proyectos complejos este coste se ve compensado por evitar el gasto todavía mayor en que se incurre si al finalizar el proyecto (en un proyecto tradicional en cascada) no se cumplen las expectativas del cliente respecto a cómo se han desarrollado los requisitos del producto o su calidad, lo cual obligaría a rehacer partes del producto, incrementando el tiempo de entrega, aumentando su coste (para el proveedor y/o para el cliente) y minando la relación cliente/proveedor.

• El cliente aporta feedback del proyecto inspeccionando los resultados en la demostración que se realiza al final de cada iteración. A partir de datos objetivos realiza las adaptaciones necesarias en la lista de requisitos priorizada.
• El equipo mejora de manera continua su metodología de trabajo y el entorno del proyecto en la retrospectiva que se realiza al final de cada iteración. Las tareas resultantes se incluyen en las planificaciones de la siguientes iteraciones.
• Los miembros del equipo se comunican en cada reunión diaria de sincronización para poder realizar las adaptaciones necesarias entre ellos que permitan conseguir el objetivo de la iteración en curso y del proyecto.

Ver también:

• Desarrollo iterativo e incremental
• Planificación ágil vs planificación tradicional
• El expendedor – Juego de simulación de Scrum
• [1] Skills en un equipo ágil.
• [2] El buen gestor de un equipo ágil.