Tratado para la Dirección y Gestión Agil de proyectos, en entornos de alta incertidumbre by SMPartners 2012

Tratado para la Dirección y Gestión Ágil de Proyectos, en entornos de alta incertidumbre Base de conocimientos para certificaciones SMA, SMP y SMT

las

Cómo aplicar realmente toda la teoría que vamos encontrando por el mundo, cómo mejorar la situación de nuestros proyectos, antes incluso de iniciarlos, cómo conseguir una dinámica exitosa dentro de los diferentes ciclos en los que nos envuelve la incertidumbre, cómo convertir el caos en orden de manera sistemática, cómo mejorar los resultados una vez declarado el fracaso, cómo cambiar una situación en la que no es posible conseguir los objetivos trazados por otra en la que esos objetivos tracen nuestra dinámica hacia el éxito de nuestro proyecto.

Versión 3.2

1-6-2011

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 1 de 141

Índice de Contenidos

AGRADECIMIENTOS ................................................................................... 7 LOS AUTORES ............................................................................................... 8 CAPÍTULO 1 INTRODUCCIÓN ............................................................... 9 1.1

El enfoque de SMPartners® .......................................................................................... 10

1.2

Evocando la Dirección de Proyectos ...................................................................... 11

1.3 Introducción a la complejidad y salida de la incertidumbre.................... 12 1.3.1 Complejidad ................................................................................................................... 12 1.3.2 El Enfoque Empírico .................................................................................................... 13 1.3.3 Sistemas Adaptativos Complejos ........................................................................... 15 1.3.4 El Origen de Scrum ..................................................................................................... 16

CAPÍTULO 2 CULTURA ORGANIZACIONAL .................................... 19 2.1 Estructura tradicional de la Organización (causante de la complejidad) ...................................................................................................................................... 20 2.2 Paradigmas Culturales ................................................................................................... 22 2.2.1 Paradigma cultural de clan ....................................................................................... 23 2.2.2 Paradigma cultural de jerarquía ............................................................................. 23 2.2.3 Paradigma cultural de adhocracia ......................................................................... 23 2.2.4 Paradigma cultural de mercado .............................................................................. 23 2.2.5 Conclusiones .................................................................................................................. 24 2.3 La gestión del cambio y de la transición ............................................................. 25 2.3.1 El cambio como evolución | El cambio como revolución .............................. 25 2.3.2 Cambio Organizacional .............................................................................................. 26 2.3.3 Dimensiones del Cambio ........................................................................................... 27 2.3.4 ¿Preparado para el cambio? .................................................................................... 29 2.3.5 Las siete fases del cambio ........................................................................................ 30 2.3.6 Implementación del Cambio .................................................................................... 33 2.3.7 El Cambio Sistemático ............................................................................................... 36

CAPÍTULO 3 LA PLANIFICACIÓN Y SUS PERSPECTIVAS .......... 37 3.1

Ejecución Incremental por Fases ............................................................................. 38

3.2

Actividades ejecutadas vs Valor entregado ....................................................... 39

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 2 de 141

3.3

Una panorámica al flujo de trabajo ........................................................................ 40

3.4 Modelos tradicionales, en ocasiones útiles ........................................................ 41 3.4.1 Descomposición ............................................................................................................ 41 3.4.2 Planificación Gradual .................................................................................................. 42 3.4.3 Plantillas .......................................................................................................................... 43 3.4.4 Método de Diagramación por Precedencia (PDM) ........................................... 43 3.4.5 Determinación de Dependencias ............................................................................ 43 3.4.6 Aplicación de Adelantos y Retrasos ...................................................................... 44 3.4.7 Plantillas de Red del Cronograma .......................................................................... 45 3.4.8 Análisis de la Red del Cronograma........................................................................ 45 3.4.9 Método de la Ruta Crítica .......................................................................................... 45 3.4.10 Método de la Cadena Crítica .................................................................................... 46 3.4.11 Nivelación de Recursos .............................................................................................. 47 3.4.12 Análisis “¿Qué pasa si…?” ......................................................................................... 47 3.4.13 Compresión del Cronograma ................................................................................... 48 3.4.14 Estimación Análoga ..................................................................................................... 48 3.4.15 Estimación Paramétrica ............................................................................................. 49 3.4.16 Estimación Ascendente .............................................................................................. 49 3.4.17 Estimación por Tres Valores .................................................................................... 50 3.4.18 Análisis de Reserva ..................................................................................................... 50 3.4.19 Análisis de Propuestas para Licitaciones ............................................................. 50 3.4.20 Análisis Costo-Beneficio............................................................................................. 51 3.4.21 Costo de la Calidad (COQ)........................................................................................ 51 3.4.22 Diagramas de Control ................................................................................................ 51 3.4.23 Estudios Comparativos .............................................................................................. 52 3.4.24 Diseño de Experimentos ............................................................................................ 52 3.4.25 Muestreo Estadístico ................................................................................................... 52 3.4.26 Diagramas de Flujo ..................................................................................................... 53 3.4.27 Metodologías Propietarias de Gestión de la Calidad ....................................... 53 3.4.28 Herramientas Adicionales de Planificación de Calidad ................................... 53 3.4.29 Diagramas de Causa y Efecto ................................................................................. 54 3.4.30 Diagramas de Control ................................................................................................ 54 3.4.31 Histograma ..................................................................................................................... 55 3.4.32 Diagrama de Pareto .................................................................................................... 55 3.4.33 Diagrama de Comportamiento ................................................................................ 55 3.4.34 Diagrama de Dispersión ............................................................................................ 56 3.4.35 Evaluación de Probabilidad e Impacto de los Riesgos ................................... 56 3.4.36 Matriz de Probabilidad e Impacto .......................................................................... 56 3.4.37 Evaluación de la Calidad de los Datos sobre Riesgos .................................... 58 3.4.38 Categorización de Riesgos ........................................................................................ 58 3.4.39 Evaluación de la Urgencia de los Riesgos ........................................................... 58 3.4.40 Técnicas de Recopilación de Información ........................................................... 59 3.4.41 Análisis de las Listas de Control ............................................................................. 60 3.4.42 Análisis de Supuestos ................................................................................................. 60 3.4.43 Técnicas de Diagramación ........................................................................................ 60 3.4.44 Análisis SWOT (o DAFO, Debilidades, Amenazas, Fortalezas y Oportunidades) ................................................................................................................................ 60

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 3 de 141

CAPÍTULO 4 ORGANIZANDO EL HORIZONTE................................ 62 4.1 Armonizando el trabajo | Implicancias tangibles .......................................... 63 4.1.1 Planificación ágil ........................................................................................................... 65 4.1.2 Planificación vs Plan .................................................................................................... 65 4.1.3 Objetivos de la planificación ágil ............................................................................ 66 4.1.4 Principios Armónicos ................................................................................................... 68 4.1.5 Los Roles (Director del Proyecto, Gestor de Expectativas y Gestor de la Ejecución) .......................................................................................................................................... 69 4.1.6 Reuniones, ¿cuáles son y por qué tan pocas? .................................................. 71 4.1.7 Artefactos y herramientas | Mecánicas a aplicar ............................................. 72 4.1.8 Pila de la Fase ............................................................................................................... 74 4.2

Formalizando el inicio ..................................................................................................... 75

4.3

Identificando a los interesados ................................................................................ 76

4.4 Recopilando Requisitos.................................................................................................. 78 4.4.1 Reunión de Recopilación de Requisitos | Construcción de la Pila del Producto Inicial ................................................................................................................................ 78 4.5 Estimando Recursos y Calculando Costes ........................................................... 91 4.5.1 Estimación Relativa ..................................................................................................... 92 4.5.2 Técnicas de Estimación .............................................................................................. 93 4.5.3 Otros costes ................................................................................................................... 96 4.6 Cerrando el horizonte 1 | Alcance inicial ............................................................ 97 4.6.1 Priorización ..................................................................................................................... 97 4.6.2 Establecer la longitud de las Fases ..................................................................... 101 4.6.3 Estimar la velocidad .................................................................................................. 102 4.6.4 Planificar las entregas .............................................................................................. 102 4.7 Planificación de la Calidad | Orientación ISO10006 ................................... 103 4.7.1 Condiciones de Satisfacción ................................................................................... 103 4.8 Planificando con personas ......................................................................................... 105 4.8.1 Mentor ............................................................................................................................ 105 4.8.2 Facilitador ..................................................................................................................... 105 4.8.3 Solucionador de Problemas .................................................................................... 106 4.9

Comunicando | El proceso.......................................................................................... 107

4.10 Abrazando la incertidumbre | Gestionando los riesgos ........................... 108 4.10.1 Riesgos asociados al alcance ................................................................................. 108

CAPÍTULO 5 EJECUTANDO LA PLANIFICACIÓN ......................... 109 5.1 Dirección y gestión de la ejecución | Proyectos con alta incertidumbre .................................................................................................................................. 110

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 4 de 141

5.2

Gestión de las expectativas del cliente .............................................................. 111

5.3

Control integrado de cambios .................................................................................. 112

5.4 Planificación de la fase N ............................................................................................ 113 5.4.1 Recopilar requisitos y determinar el horizonte de la fase N | Reunión de planificación de la fase ................................................................................................................ 113 5.4.2 Planificación de las comunicaciones en la Fase N.......................................... 116 5.4.3 Planificación de la Gestión de Riesgos en la Fase N ..................................... 117 5.5 Gestión de la Calidad en la Fase N ........................................................................ 118 5.5.1 Calidad del Producto ................................................................................................. 118 5.5.2 Calidad de los Procesos ........................................................................................... 118 5.6

Gestión de las Personas en la Fase N .................................................................. 119

5.7 Control y Seguimiento .................................................................................................. 120 5.7.1 Monitorizar y controlar los riesgos ...................................................................... 120 5.7.2 Monitorizar y controlar el trabajo ........................................................................ 122 5.7.3 Controlar el cronograma | Seguimiento del desempeño ............................ 124 5.7.4 Controlar los costes................................................................................................... 125 5.7.5 Asegurando la calidad .............................................................................................. 125 5.7.6 Comunicaciones .......................................................................................................... 125 5.8 Cierre de la Fase N .......................................................................................................... 126 5.8.1 Control y cierre de la calidad ................................................................................. 126 5.8.2 Informes de Desempeño ......................................................................................... 127 5.8.3 Mejora continua | aprendiendo ............................................................................. 127

CAPÍTULO 6 CIERRE DEL PROYECTO ............................................. 131 6.1

Cierre Administrativo del proyecto y sus fases ............................................. 132

CAPÍTULO 7 COMPLEMENTANDO EL CONOCIMIENTO............. 133 7.1 Contratos Ágiles ............................................................................................................... 134 7.1.1 Evaluación de los contratos ................................................................................... 134 7.1.2 Información que debe incluirse en el contrato ............................................... 135 7.1.3 Algunos enfoques contractuales ........................................................................... 135 7.2 Claves de la comunicación ......................................................................................... 138 7.2.1 El Canal y su Ancho de Banda .............................................................................. 138 7.2.2 Comprender ................................................................................................................. 139 7.2.3 Ser Comprendidos ..................................................................................................... 140

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 5 de 141

Índice de Figuras

Figura 1.1: Complejidad........................................................................................ 12 Figura 2.1 Características de Estructuras de las Organizaciones ......... 20 Figura 2.2: Paradigmas Culturales ................................................................... 22 Figura 2.3: Pirámide de Maslow ......................................................................... 25 Figura 2.4: Dimensiones del Cambio ............................................................... 29 Figura 2.5: Matriz liderazgo / dirección .......................................................... 33 Figura 3.1: Matriz de Probabilidad e Impacto .............................................. 57 Figura 4.1: Triángulo de Hierro .......................................................................... 63 Figura 4.2: Enfoque tradicional vs Enfoque Ágil ......................................... 64 Figura 4.3: Principios Armónicos ....................................................................... 68 Figura 4.4: Equipo de Proyecto .......................................................................... 71 Figura 4.5: Ejemplo de Ficha de Historia de Usuario ................................ 83 Figura 4.6: Comenzando a crear el Mapa de Historias de Usuario ...... 87 Figura 4.7: Mapa de Historias de Usuario ...................................................... 88 Figura 4.8: Walking Skeleton .............................................................................. 89 Figura 4.9: Determinación de las diferentes releases ............................... 89 Figura 4.10: Relación Esfuerzo - Precisión a la hora de estimar .......... 91 Figura 4.11: Valor - Riesgo .................................................................................. 98 Figura 4.12: Reducción de la incertidumbre - Enfoque Tradicional (adaptación de Cohn 2006) ................................................................................. 99 Figura 4.13: Reducción de la incertidumbre - Enfoque Ágil (adaptación de Cohn 2006) ............................................................................... 100 Figura 5.1: Diseño básico de un Panel de Tareas ..................................... 123 Figura 5.2: Diagrama de quemado o burndown ....................................... 124 Figura 7.1: Esquema de Comunicación......................................................... 138

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 6 de 141

AGRADECIMIENTOS Queremos daros las gracias a todos los que habéis colaborado con nosotros en esta iniciativa. Una iniciativa que busca, humildemente, aportar un valor diferencial al mundo del Management Global. Todos nuestros esfuerzos se han dirigido hacia un objetivo central: hacer de este tratado, de nuestro tratado, de vuestro tratado, una guía de “buen hacer”, tan gentil como efectiva para gestionar ágilmente frente a contextos llenos de incertidumbre y poca claridad. De esta manera buscamos apoyar a la consecución de los más complejos objetivos, en la mayor diversidad de “tipos” de proyecto.

Los autores.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 7 de 141

LOS AUTORES SMPartners®, nace de la conjunción de 4 profesionales del mundo del management y los negocios, 4 reconocidos personajes que tras diferentes experiencias y haber caminado por diferentes países, sectores, proyectos, temáticas, éxitos y no éxitos; deciden dotar al mundo de un know how diferente, una serie de técnicas no escritas hasta el día de hoy, con una altísima cuota de aplicabilidad. Es así que nace para el mundo, una nueva dinámica, una nueva vía de gestión, un compendio de buen hacer y una nueva forma de gobernar proyectos, en cualquier situación, contexto o lugar. Jesús Candón Rosado

Juan Manuel Espinoza

Óscar Ramírez Muñoz

Jesús Cobos Romano

www.scrummanagementpartners.org

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 8 de 141

Capítulo 1 INTRODUCCIÓN

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 9 de 141

1.1 El enfoque de SMPartners® Queremos con este trabajo, dar a conocer al mundo una nueva vía de gestión, una vía que nos ayude a trascender por sobre lo tradicional, lo rígido, lo estático y sobre todo aquello que limita la creatividad de los verdaderos directores de proyecto, aquellos que gestionan sus días, sus horas y sus momentos, con criterio, con emoción y muchísimo sentido común… ¿no es acaso la vida misma, un proyecto complejo? Nuestro Tratado no es un compendio de teorías caducas, no es un modelo meramente filosófico, ni es una visión sesgada de una realidad inexistente; no es simplemente un compendio rígido que “marque el camino” y que sentencia toda “opción ajena” como una “desviación. Nuestro Tratado es la vía que nos permitirá al dirigir y gestionar proyectos, generar ventajas sobre desventajas, cambiar giros y reveses bruscos, por dinámicas suaves pero constantes, con puntos reales de conciencia, y con bases sostenibles hacia una mejor gestión del tiempo, del presupuesto y del alcance (aunque todo esto cambie en el día +1). El mundo ha cambiado y, hoy por hoy, podemos ser testigos, sin hacer mucho esfuerzo, de lo caduco de muchos modelos de gestión, de cómo la balanza se ha inclinado hacia sectores o países donde ayer reinaba la incertidumbre y una inmensa necesidad de adaptación, y cómo por el contrario, donde todo estaba “en orden” y “estandarizado” hemos visto sucumbir, bajo la poca o casi nula capacidad de adaptación y previsión, a las más grandes economías. Esta situación no ha sido exclusiva de los mercados, ni se limita a las grandes economías o a las grandes inversiones, no; es una situación que sin temor a equivocarnos, hemos visto todos los que gestionamos proyectos día a día, el “cómo hacer 4 con 8″ ha pasado a ser “como hacer 8 con 1″ y aunque suena imposible no lo es, es solo cuestión de adaptación, planificación, y adaptación otra vez. Solo gestionando los proyectos o programas de esta manera, conseguiremos el éxito en el día a día de nuestro negocio y el de nuestros socios/clientes, y seremos fuertes y altamente eficientes, cuando no haya necesidad de una adaptación tan dinámica y tan exhaustiva.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 10 de 141

1.2

Evocando la Dirección de Proyectos

Existen suficientes evidencias como para tener claro que la dirección de proyectos no es algo nuevo, no es algo que se haya inventado alguna entidad de algún país desarrollado y está claro que es una necesidad que el mundo viene satisfaciendo de época en época, con mejores o peores herramientas, con más o menos “éxito” y con buenas y malas técnicas. Cuando pensamos en la dirección de proyectos, es natural que miremos hacia atrás, sí, pero no a la versión 1 de “la norma”, sino muchísimo más atrás aún. Sabemos que desde tiempos inmemoriales, el hombre ha fabricado construcciones de todo tipo, algunas colosales, otras simplemente inexplicables, otras no tan notorias, y muchísimas que de seguro quedan por descubrir. Seria quizás algo soberbio afirmar que estos señores no utilizaban ya alguna técnica para la dirección de sus proyectos. Es probable que incluso fueran mucho más efectivas que las que actualmente existen; basándonos simplemente en lo imposible que resultaría repetir algunas de las obras que hace miles de años ya se llevaban a cabo de manera sistemática. Entonces, partamos de que la dirección de proyectos lleva en el mundo quizás más años que muchos de los miles que ahora leemos este tratado, y que sin lugar a dudas, seguirá aquí cuando muchos otros nos hallamos ido; por lo tanto, es necesario aportar nuevos enfoques, nuevos planteamientos que la enriquezcan cada vez más, aportar complementos que la hagan más aplicable a cualquier situación y a cualquier contexto. Para ello estamos aquí. Nuestro tratado escapa completamente al planteamiento reducido y limitado que ha llevado a las técnicas y métodos ágiles, a “llevar por apellido” el desarrollo de software o cosas similares. Gestionando con “El Tratado” podremos dirigir y gestionar la construcción de un barco, la ampliación de una autopista, el desarrollo de un sistema operativo, la puesta en marcha y posterior gobierno de una Software Factory, la implementación de oficinas de proyecto y de servicios (PMO, SMO, con éxito), los servicios que brindamos o queremos brindar a nuestros clientes, nuestra organización interna y la relación externa (entre empresas), la puesta en marcha de eventos (p.e. un congreso internacional en tiempo record), la creación de una empresa, el lanzamiento de una nueva línea de negocio (con el equipo implicado), y un largo etcétera. ¿Está orientado al desarrollo de software? Si lo necesitas, sí, pero esto va mucho más allá y el limite solo lo estableces tú.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 11 de 141

1.3 Introducción a la complejidad y salida de la incertidumbre 1.3.1 Complejidad Podemos caracterizar los proyectos por su complejidad, determinada por la incertidumbre existente en dos dimensiones:  

QUÉ es lo que se quiere hacer CÓMO queremos hacerlo

La siguiente gráfica caracteriza las distintas tipologías de proyectos en función de esta definición de complejidad:

Figura 1.1: Complejidad

1.3.1.1

Proyectos Simples

Son aquellos donde se conoce prácticamente al detalle QUÉ hay que hacer y se dispone de la forma y los medios que definen CÓMO hacerlo. En estos casos, existe un proceso definido que resuelve el problema con unos recursos determinados en un tiempo conocido. En este contexto funciona el enfoque predictivo, puesto que el grado de incertidumbre aquí es mínimo. La dirección de proyectos simples se basa en dos actividades principales:

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 12 de 141



Planificación inicial predictiva: haciendo un desglose de actividades, estimando los recursos y el tiempo y estableciendo las líneas maestras del plan. Control: verificar que el proyecto se desarrolla según el cronograma planteado.

1.3.1.2

Proyectos Complicados

En este tipo de proyectos se conoce QUÉ y se conoce CÓMO pero su tamaño y/o por los riesgos implicados estas dimensiones podrían variar ligeramente. La labor de dirección aquí se complica respecto a los proyectos simples, obligando a tener una especial atención en la definición inicial de los riegos y en su gestión a lo largo del ciclo de vida. 1.3.1.3

Caos

El caos es el terreno de la inspiración, de las ideas, de muchos proyectos de investigación. No se ha definido en concreto QUÉ se quiere conseguir ni CÓMO conseguirlo. Se trabaja de forma anárquica y no planificada. En este entorno el éxito suele llegar de la mano de la serendipia. 1.3.1.4

Proyectos Complejos

En los proyectos complejos tenemos una visión clara, pero no tenemos completamente definidos al inicio QUÉ es lo que hay que hacer y CÓMO hay que hacerlo. Existe incertidumbre en ambas dimensiones, por tanto son impredecibles. El enfoque predictivo aquí tiene unos resultados desastrosos, puesto que es imposible predecir lo que no se conoce. 1.3.2 El Enfoque Empírico Para llevar las riendas de un proyecto de estas características es importante tener en cuenta que muchos procesos implicados en nuestra vida diaria funcionan únicamente porque su grado de imprecisión es aceptable. Pensemos en una bicicleta. Las ruedas se tambalean, el manillar se desalinea, los frenos son inestables, pero todo ello no nos impide ir en bici. Lo que ocurre es que todo ello sucede a un nivel del que no tenemos consciencia. Si quisiéramos construir una bicicleta, uniríamos una serie de piezas con una precisión que consideráramos aceptable (por ejemplo que no se note al ojo humano las uniones de los tubos del cuadro). Somos capaces de gestionar muchos procesos únicamente porque la precisión de sus resultados está limitada a nuestra percepción. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 13 de 141

Ahora bien, imaginamos que somos constructores de bicicletas y queremos acceder al mercado profesional. Es posible que nuestros clientes requieran que nuestros procesos constructivos alcance un nivel de precisión superior para que las prestaciones de la bici satisfagan las especiales necesidades de este mercado. En este caso deberemos controlar el proceso paso por paso asegurándonos que se obtiene un resultado con un grado de aceptación aceptable. Conocemos el QUÉ (con sus restricciones, como es el grado de precisión aceptable), conocemos el CÓMO (a través de un proceso repetible que produce un resultado con una calidad determinada). Si este resultado no se produce, tendremos que hacer ajustes en el proceso hasta que vuelva a estar en el rango de precisión aceptable. A este tipo de control del proceso se le denomina definido. Pero si no podemos lograr un control definido del proceso debido a la complejidad de las actividades necesarias para desarrollar el producto hay que emplear un control empírico del proceso. El control empírico del proceso exige mayor coste que el control definido del proceso. Pero si la complejidad de las actividades es lo suficientemente grande, en el largo plazo, hacer productos bien a la primera con un control empírico del proceso resulta ser mucho más barato que rehacer un proceso que da lugar continuamente a productos inadecuados usando un control definido del proceso. 1.3.2.1

Claves del Control de Proceso Empírico

Las tres claves del Control Empírico del Proceso son: visibilidad, inspección y adaptación.   

Visibilidad: los aspectos que influyen en el resultado deben ser visibles para facilitar el control del proceso. Inspección: estos aspectos deben ser controlados con frecuencia para detectar las variaciones inaceptables. Adaptación: una vez detectada estas variaciones o identificados puntos de mejora, deben realizarse los cambios precisos en el proceso para mejorarlo.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 14 de 141

1.3.3 Sistemas Adaptativos Complejos En este contexto de alta incertidumbre, nos centramos en la resolución de los problemas que hemos identificados como complejos. En la mayoría de los casos la complejidad de estos problemas es tal que son muy difíciles, imposibles o inviables de resolver por una única persona. Por esta razón se opta por que la resuelvan un conjunto de personas, entendiendo que así será más sencillo, o será posible o será viable. Esta aproximación intuitiva tiene cierta base científica. Existen los denominados Sistemas Multi Agente o SMA que, como su propio nombre indica, son sistemas compuestos por múltiples agentes inteligente interactuando entre ellos. Inteligentes hace referencia a que son capaces de tomar decisiones. Ahora bien, hay un tipo de SMA que es el que nos interesa para comprender por qué funciona Scrum. Nos referimos a los Sistemas Adaptativos Complejos SAC. Son también sistemas multiagente, pero tienen la particularidad de que tanto los elementos como el propio sistema es adaptativo; es decir, tienen la capacidad de aprender de la experiencia y adaptarse para conseguir mejores resultados. Este le confiere la capacidad de auto organización. Sin entrar a profundizar más en la teoría, valga con comprender que lo que aquí se plantea es que los equipos de trabajo se comporten como Sistemas Adaptativos Complejos. Para lograr esto merece la pena destacar tres características fundamentales que se deben fomentar en estos equipos: 



Relaciones horizontales: cada elemento es igual al otro en cuanto a oportunidad de participar, aportar y expresar, sin cabida a la discriminación y sin presiones. Fomentando que todos los integrantes se sientan socios y no jefes y subordinados. No existe elemento más valioso. Está claro que no todos son netamente iguales, pero sí son igualmente importantes. Confianza: como dice Fukuyama: “la confianza es como un lubricante que hace que cualquier grupo u organización funcione mejor, permitiendo que cada uno exprese sus ideas plenamente con la certeza de que no será sancionado o criticado, a actuar con libertad sabiéndose en un espacio de todos”. Es esa la clase de confianza esencial para que un equipo ágil pueda desarrollarse en plenitud de facultades. Comunicación: es la piedra angular que favorece la creación del resto de circunstancias. Una comunicación fluida, clara y directa. Es el punto sin duda más importante porque conforma la mayor clave de éxito y de fracaso en los equipos en la mayoría de los proyectos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 15 de 141

1.3.4 El Origen de Scrum Scrum es un marco de trabajo ágil para la gestión de proyectos de cuyos principios bebe el presente tratado. Estos principios comenzaron a emerger y a ponerse en negro sobre blanco en 1986, fecha de publicación de “The New Product Development Game”, de Hirotaka Takeuchi and Ikujiro Nonaka, un estudio que habla de cómo incrementar la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales, utilizando como base casos de estudio de Estados Unidos y Japón procedentes la industria automovilística así como de la fabricación de cámaras fotográficas, impresoras y ordenadores. En este estudio se comparaba el comportamiento de los componentes de los equipos de trabajo multidisciplinares con las estrategias presentes en el juego del rugby. Por esta razón, posteriormente la aproximación descrita en este artículo fue referenciada como Scrum (lo que es en español “la melé”). En 1995, los que están considerados como los padres del marco de trabajo Scrum, Ken Schwaber y Jeff Sutherland coincidieron en un importante evento relacionado con el desarrollo del software presentando en paralelo un conjunto de artículos en los que describían Scrum. A partir de ese encuentro comenzaron a colaborar, aunando su conocimiento, sus experiencias y las mejores prácticas existentes para desarrollar lo que se conoce en la actualidad como Scrum. Pero es imposible comprender el sentido de Scrum sin hacer referencia al “Manifiesto por el Desarrollo Ágil de Software”, en cuya elaboración, en 2001, participaron los creadores de Scrum junto con otros quince profesionales del desarrollo de software que estaban en desacuerdo con el enfoque basado en procesos que hasta la fecha predominaba en el sector. En él se expresa lo siguiente: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: 

Individuos e interacciones sobre procesos y herramientas



Software funcionando sobre documentación extensiva



Colaboración con el cliente sobre negociación contractual



Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 16 de 141

Y además exponen doce principios en los que se basa el desarrollo ágil de software: “Seguimos estos principios: 

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.



Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.



Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.



Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.



Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.



El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.



El software funcionando es la medida principal de progreso.



Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.



La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.



La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.



Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.



A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.”

Scrum es un marco de trabajo que cristalizó en un contexto de desarrollo de software pero se ha demostrado efectivo en muchos otros ambientes. La característica común de los contextos donde Scrum funciona es la Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 17 de 141

complejidad, factor que hemos analizado anteriormente y que da sentido al presente tratado.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 18 de 141

Capítulo 2 CULTURA ORGANIZACIONAL

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 19 de 141

2.1 Estructura tradicional de la Organización (causante de la complejidad) Un factor importante que influye dramáticamente en el modo de dirigir los proyectos es la estructura de la organización. Las estructuras típicas se debaten entre dos extremos. Por un lado tenemos la organización funcional clásica. Se trata de una organización jerarquía donde cada empleado tiene un superior claramente definido. Sobre ellos, los miembros del personal están agrupados por especialidades, como pueden ser: producción, ingeniería o contabilidad. Las especialidades pueden dividirse en organizaciones funcionales, como la ingeniería mecánica y la ingeniería eléctrica. Cada uno de estos departamentos desempeña el trabajo del proyecto de forma independiente de los demás departamentos. En el extremo opuesto de la organización funcional, tenemos la organización orientada a proyectos. En este tipo de organizaciones, los miembros del equipo están localizados en un mismo lugar, la mayor parte de los recursos de la organización participa en el trabajo de los proyectos y los directores del proyecto tienen mucha más independencia y autoridad. Estas organizaciones suelen contar con unidades organizacionales denominadas departamentos, pero estos grupos dependen directamente del director del proyecto, o bien prestan sus servicios a varios proyectos. Matricial Fuerte

Orientada a Proyectos

Funcional

Matricial Débil

Matricial Equilibrada

Autoridad del Director del Proyecto

Poca o Ninguna

Limitada

Baja a Moderada

Moderada a Alta a Casi Alta Total

Disponibilidad de recursos

Poca o Ninguna

Limitada

Baja a Moderada

Moderada a Alta a Casi Alta Total

Quién controla el Presupuesto del Proyecto

Gerente Funcional

Mixta

Director del Director del Proyecto Proyecto

Dedicación del Director del Proyecto

Parcial

Completa

Dedicación del Personal Administrativo de la Dirección de Proyectos

Parcial

Completa

Figura 2.1 Características de Estructuras de las Organizaciones

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 20 de 141

Entre ambas, nos encontramos con las organizaciones matriciales, que presentan una mezcla de características de las organizaciones funcionales y de las orientadas a proyectos. Las denominadas matriciales débiles mantienen muchas de las características de una organización funcional, y el rol del director del proyecto es más bien el de un coordinador o expedidor, que el de un verdadero director del proyecto. Las matriciales fuertes tienen muchas de las características de la organización orientada a proyectos: pueden tener directores del proyecto dedicados de tiempo completo y una autoridad considerable, y personal administrativo dedicado de tiempo completo. Si bien la organización matricial equilibrada reconoce la necesidad de contar con un director del proyecto, no le confiere autoridad plena sobre el proyecto ni su financiamiento. Bien es cierto en que muchas organizaciones coexisten todas estas estructuras a diferentes niveles, lo que se denomina organización combinada. Por ejemplo, imaginemos que una organización eminentemente funcional tiene un equipo del proyecto especial para gestionar un proyecto crítico, que puede tener muchas de las características de un equipo del proyecto de una organización orientada a proyectos. El equipo puede incluir personal dedicado de tiempo completo obtenido de varios departamentos funcionales, puede disponer de sus propios procedimientos desarrollar su propio conjunto de procedimientos. Dada la naturaleza de los proyectos a los que se circunscribe el presente tratado, la estructura propuesta está cercana a la organización por proyectos, pero va más allá del enfoque tradicional. En cualquier caso, en lo que atañe a la estructura, la organización debe dotar de la importancia, el poder y los recursos necesarios al Director del Proyecto para llevar a cabo su labor con la mayor probabilidad de éxito.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 21 de 141

2.2 Paradigmas Culturales De manera informal e intuitiva, podemos definir el concepto de Cultura Organizacional como el conjunto de experiencias, hábitos, costumbres, creencias, y valores de las personas que conforman una organización. Es un concepto íntimamente ligado al de estructura organizacional, puesto que ambas conforman el contexto de la organización. La cultura organizacional de una empresa determina, en muchos casos, el éxito o el fracaso de la incorporación de una metodología o marco de trabajo. Muchas organizaciones, admirando las virtudes de una metodología (la que sea, es independiente a este nivel de análisis) y deciden incorporarla sin preocuparse de verificar si su cultura organizacional está alineada con la metodología o viceversa. O en el caso de que quieran incorporarla sí o sí, la implantación de la metodología en muy contadas ocasiones comienza por el cambio cultural. Todas las organizaciones deben aspirar a obtener el mayor rendimiento de sus recursos. Por ello deben conjuntar los diferentes aspectos organizacionales para que funcionen en armonía. No deben pasar por alto que la conjunción de elementos que conforman la cultura organizacional de la empresa se convierte en un activo fundamental que puede acelerar, frenar o malograr la implementación de cualquier cambio en la empresa. Con objeto de ilustrar la importancia de la cultura de una organización, vamos a poner nuestra atención en cuatro paradigmas o cuadrantes definidos por Cameron y Quinn (1999), distribuidos en dos dimensiones: 1. Flexibilidad, discreción y dinamismo vs estabilidad, orden y control 2. Orientación interna, integración y unidad vs orientación externa, diferenciación y rivalidad

Figura 2.2: Paradigmas Culturales

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 22 de 141

2.2.1 Paradigma cultural de clan En una organización de clan las premisas básicas son las siguientes: 1. El ambiente puede manejarse mejor por medio del trabajo colaborativo y el desarrollo de los empleados 2. Los consumidores deben ser vistos como socios 3. La organización “está en el negocio” de desarrollar un ambiente humano de trabajo 4. la mayor tarea de la gerencia es otorgarles a los empleados el poder de decisión y facilitar su participación, dedicación, compromiso y lealtad. 2.2.2 Paradigma cultural de jerarquía Este paradigma está basado en los atributos clásicos de la burocracia de Max Weber: reglas, especialización, “meritocracia” (supervisión mediante premios y sanciones), jerarquía, propiedad separada, impersonalidad y responsabilidad. Estas características fueron adoptadas por empresas e instituciones cuyo mayor reto fue generar eficiencia, confiabilidad, flujos planos y resultados predecibles. Por tanto, suele ser adecuada en ambientes predecibles. 2.2.3 Paradigma cultural de adhocracia En este paradigma la principal labor directiva es lograr que se adopten la creatividad, el emprendimiento y la actividad de “permanecer en el límite”. La adaptación y la innovación son vías para conseguir nuevos recursos y lograr la rentabilidad; consecuentemente, se remarca de manera especial la creación de una visión del futuro, una “anarquía organizada” y una capacidad de imaginación considerable. Para los autores Cameron y Quinn (2006), este tipo de cultura organizacional representa un diseño organizacional de re‐construcción permanente. Las adhocracias tienen un carácter eminentemente temporal, se reconstituyen con rapidez cuando se presentan otras circunstancias. Una meta esencial de la organización adhocrática es crear adaptabilidad, flexibilidad y creatividad para combatir la incertidumbre, la ambigüedad y la carga excesiva de información, típicas de la era de la información que estamos viviendo 2.2.4 Paradigma cultural de mercado Las

premisas

fundamentales

cultura

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

mercado

son:

Pág. 23 de 141

1. El ambiente externo no es benigno sino hostil 2. Los consumidores son sensibles y están interesados en el coste del producto o servicio (el valor agregado es importante) 3. La compañía está inmersa en el “negocio” de incrementar su posición competitiva 4. La tarea mayor de la gerencia es conducir a la organización hacia la productividad, los resultados y las ganancias. Para ello se necesita de propósitos claros y una estrategia agresiva. 2.2.5 Conclusiones Estos cuatro paradigmas son extremos. En la mayoría de las organizaciones obtendremos combinaciones con elementos de unos y de otros. Pero es importante conocer en qué términos la empresa define el éxito y el modo de conseguirlo. En un contexto de alta incertidumbre, los equipos de trabajo funcionarán bajo un paradigma de clan, cercano a la adhocracia. A medida que vayamos avanzando en la lectura de este tratado, iremos razonando sobre las cuestiones culturales del marco de trabajo. La organización que alberga este equipo de proyecto puede trabajar bajo otro paradigma. Esto es posible. Aunque es necesaria la incorporación de elementos adaptadores, que permitan aislar y conectar al equipo del proyecto con el resto de la organización cuando se requiera. No obstante, siempre es conveniente que toda la organización esté alineada y que trabaje bajo un marco compartido de experiencias, hábitos, costumbres, creencias, y valores.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 24 de 141

2.3 La gestión del cambio y de la transición 2.3.1 El cambio revolución

como

evolución

cambio

como

El cambio es inherente a la realidad. La cultura oriental ya nos cuenta que “la única constante en el universo es el cambio”. Maslow ya ilustró de forma muy gráfica a través de su famosa pirámide que el ser humano tiene una serie de necesidades que debe satisfacer. Estas necesidades se disponen por niveles conceptuales. Lograr satisfacer las necesidades de un nivel hace que la persona se plantee necesidades de niveles inferiores. Así tenemos cinco principales estratos, que son: • • • • •

Necesidades básicas u homeostáticas, que son fisiológicas, relativas a la salud, como alimentarse o respirar. Necesidades de seguridad y protección. Necesidades de afiliación y afecto. Necesidades de estima y reconocimiento. Autorrealización.

Autorrealización

• creatividad • aceptación de hechos • resolución de problemas

Reconocimiento

• autorreconocimiento • confianza • respeto • éxito

Afiliación

• amistad • afecto • intimidad sexual

Seguridad

• física • de empleo • de recursos

Fisiología

• respiración • alimentación • descanso

Figura 2.3: Pirámide de Maslow

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 25 de 141

La evolución, la satisfacción de las necesidades y el acceso a las necesidades superiores implican evolución en la persona. Implican cambio. Hay muchos tipos de cambio. Muchos de estos cambios implican incertidumbre. Muchas personas responden a estas transiciones en su vida con miedo, otras con ilusión. Unas buscan situaciones de incertidumbre (“ir a la aventura”) y otras prefieren avanzar planificadamente. Por otro lado, las personas desarrollamos un sentimiento de paz y sosiego cuando nos encontramos dentro de nuestra “zona de confort”; es decir, cuando hacemos algo que dominamos y cuya incertidumbre es relativamente baja. Fuera de esta zona, están las situaciones nuevas, está la incertidumbre, pero también está el aprendizaje. Salir de la zona de confort implica un cambio. De atención, de actitud, nos hemos de activar, porque la incertidumbre hace su aparición. Y fuera de la zona de confort, en la medida que respondemos a situaciones nuevas, se produce el aprendizaje. Hay quienes buscan este aprendizaje de manera continua, dónde se hace natural al flujo de vida, los cambios se realizan por convencimiento. Hay una vocación inherente a la evolución. Pero hay otras personas u otras situaciones en las que el cambios es drástico, dramático en muchos casos. Imaginamos el caso de una persona que esté harta de la situación de su trabajo y decide poner fin a esa relación laboral. Su paradigma cambia de la noche al día. Se produce un cambio por revolución. En cualquier caso, la vida del ser humano está llena de cambios, cotidianos y excepcionales. La forma en la que respondemos a estos tiene su reflejo en nuestra capacidad aprendizaje. 2.3.2 Cambio Organizacional En una sociedad tan acelerada como la que nos encontramos en la actualidad, cualquier organización debe estar lo suficientemente preparada para adaptarse y evolucionar en entornos dinámicos, complejos y de gran incertidumbre. En épocas anteriores, las organizaciones han trabajado en entornos relativamente estables en el que la gestión del cambio no era una prioridad y sí la gestión del crecimiento o la fidelización de los nichos de mercado que habían conquistado. Eran momentos donde la excelencia en las actividades de planificación y control proporcionaban altos niveles de seguridad y estabilidad en el seno de las organizaciones y en el que los planes de

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 26 de 141

cambio se acometían de manera excepcional y como paso previo a grandes periodos de estabilidad. En la actualidad, la situación es muy diferente. Los cambios se aceleran en diferentes planos y de manera simultánea como la ciencia, la tecnología, la economía, la sociedad, etc., por lo que se hace imprescindible dar respuestas ágiles y rápidas a situaciones emergentes de escasa predictibilidad, y donde la cultura organizacional se convierte en el factor clave de éxito para llevar a cabo tales desafíos. La experiencia, la creatividad, la iniciativa, el compromiso o la coresponsabilidad son características, entre otras, que deben impregnar a cualquier organización que desee ejecutar de manera efectiva cualquier proceso de cambio. Por tanto, la gestión del cambio se ha convertido en un arte de gran importancia estratégica y que debe ejecutarse de manera continuada perfectamente integrada en el día a día de las organizaciones, requiriendo que éstas apuesten por un cambio cultural y que sean capaces de desarrollar de manera orgánica marcos de trabajo que potencien su capacidad de transformación. 2.3.3 Dimensiones del Cambio Generalmente, las organizaciones suelen responder a diferentes desafíos como la incorporación o desarrollo de nuevas tecnologías, la aparición y penetración en nuevos mercados, la aparición de nuevos competidores y a la propia motivación que mueve a las organizaciones por ser mejores y más grandes, a través de programas perfectamente diseñados y orientados a superar todos aquellos obstáculos que se interponga en el camino de la mejora de la organización. Estos programas habitualmente se pueden categorizar de la siguiente manera: 



Cambios estructurales. Son los provocados por nuevas fusiones, adquisiciones, consolidaciones, desinversiones de unidades operativas. Reducción de costes. Estos programas focalizan la atención en la eliminación de todas aquellas actividades que no aportan valor de negocio. Cambio de procesos. Este tipo de cambios pretenden cambiar la forma en la que se llevan a cabo las cosas para que se desarrollen procedimientos más rápidos, ágiles, eficaces, fiables y menos costosos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 27 de 141



Cambio cultural. Estos programas ponen toda la atención el el factor humano y cómo éste impacta en la forma en el que la organización hace los negocios o como se relaciona la dirección con los empleados.

Independientemente del programa de cambio que tenga pensado llevar a cabo, es fundamental que inicialmente sea capaz de identificar en qué categoría se encuentra su programa para que a continuación pueda prever los potenciales impedimentos que pueden afectar al transcurrir normal del proceso de cambio. Ya hemos visto que existen diferentes tipos de programas de cambio pero lo que debemos preguntarnos realmente es cuál es el objetivo que se persigue. Normalmente suelen ser dos: 



Una mejora económica a corto plazo normalmente como consecuencia de una crisis financiera. La consecución de este objetivo suele ir acompañado de la eliminación total de actividades que anteriormente no consiguieron demostrar una creación tangible de valor, siendo especialmente vulnerables las relacionadas con la I+D Una mejora de las capacidades de la organización con la firme intención de desarrollar culturas organizacionales más dinámicas, planas, con una formidable participación de los empleados y donde se apoye el aprendizaje, impulsando así el éxito financiero.

Ninguno de estos enfoques es garantía de éxito. Sin embargo, aquellas empresas que sean capaces de combinar de manera efectiva ambos enfoques al cambio, tendrán mayor predisposición a recoger importantes recompensas en productividad y rentabilidad.

Dimensiones del cambio

Objetivos

Liderazgo

Mejora económica a corto plazo

Mejora de las capacidades de la organización

Enfoque combinado

Incrementar al máximo el valor para el accionista

Desarrollar las capacidades de la organización

Equilibrio entre el valor económico y la capacidad de organización

Dirección/Gestión impulsado por la directiva

Fomentar la participación de abajo hacia arriba

Establecer la dirección desde los ejecutivos involucrando a los empleados

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 28 de 141

Focalizar de Cultiva la manera cultura simultánea en organizacional ambos

Enfoque/concentración

Centrado en la estructura y sistemas

Proceso

Planificación y control

Inspeccionar y adaptarse

Planificar la espontaneidad

Recompensas

Incentivos financieros

Utilizar el compromiso como motivación y el sueldo como respuesta justa

Facilitar incentivos para reforzar el cambio y no para impulsarlo

Ayuda de asesores externos

Analizan problemas y proponen soluciones

Apoyan a la dirección para que encuentren soluciones

Facilita y Democratiza la toma de decisiones entre los empleados

Figura 2.4: Dimensiones del Cambio

2.3.4 ¿Preparado para el cambio? Una vez conocida las diferentes dimensiones del cambio, de poco le servirá a la organización llevar a cabo los programas de cambio si ésta no está preparada. Las condiciones necesarias que se deben dar en cualquier organización para que el cambio se ejecute de manera efectiva son las siguientes:  

Que exista la figura de líder eficaz, servicial y respetado por todos. Que exista una buena motivación en la organización por cambiar. En este tipo de situaciones, se debe evitar por todos los medios respuestas reactivas ante situaciones de crisis. Lo deseable sería responder con una actitud proactiva sin recurrir a las tácticas tradicionales en época de crisis. Aquí presentamos algunas actividades que se pueden llevar a cabo para conseguir este objetivo: o Generar debate constructivo entre los empleados respecto a los problemas actuales y futuros de la organización transmitiendo la información sobre la situación competitiva de la organización o Facilitar oportunidades dentro de la organización para que los empleados eduquen a la dirección en cuanto a la insatisfacción y problemas que experimentan

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 29 de 141



Que existe un paradigma colaborativo en el seno de la organización, pues las estructuras jerárquicas no facilitan el trabajo en colaboración, que al mismo tiempo es una de las habilidades más importantes que deben tener los empleados de una empresa preparada para el cambio.

A continuación, presentamos algunas claves que le serán de utilidad para evaluar si su organización está preparada para el cambio:  

 

Evalúe diferentes unidades de negocio y comience el cambio por aquellas que están preparadas Fomente el trabajo colaborativo facilitando la toma de decisiones desde los puestos menos directivos, transmitiendo y compartiendo información, eliminando símbolos que denoten jerarquía o estatus, experimentando in situ el trabajo del resto de empleados, etc. Dele voz a la gente apoyando el pensamiento creativo e innovador, mostrando respeto, delegando, tomando riesgos. Elimine el miedo 2.3.5 Las siete fases del cambio

2.3.5.1

Fase 1

Objetivo: Potenciar la energía, el compromiso y la dedicación a través de la identificación conjunta de los problemas del negocio y sus soluciones. Es fundamental desarrollar un sentido de urgencia alrededor de la necesidad de cambio que sirva como empujón inicial para despertar la motivación y así el movimiento de cambio. Es importante la identificación del problema pero también lo es la manera en la que se identifica. Se deben generar espacios abiertos donde se dialogue y discuta de lo que está pasando en el mercado y su competencia. Por último, hay que desarrollar un plan de acción donde todas las partes se encuentren involucradas, formando parte de la solución. En cualquier caso, es fundamental en este punto en el que un porcentaje muy alto de los puestos directivos se encuentren convencidos y comprometidos con la propuesta de cambio. 2.3.5.2

Fase 2

Objetivo: Desarrollar una visión compartida de cómo organizarse y dirigir para ser competitivo. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 30 de 141

Todas las soluciones e ideas recogidas previamente deben estar vinculadas a una visión general y compartida que todo el mundo pueda entender y recordar sin problemas, que proporcione sentido. La comunicación en este punto es fundamental. Sea claro, conciso, indicando los beneficios que supondrá para todos. Una visión eficaz debe tener las siguientes características:        

Describe un futuro deseable Debe ser apremiante Ser realista Estar concentrado Ser flexible Fácil de comunicar Debe poder ser traducida a acciones concretas Compatible con los valores de la empresa

2.3.5.3

Fase 3

Objetivo: Identificar el liderazgo. Convencer a la gente de que el cambio es necesario implica un fuerte liderazgo y apoyo visible por parte de gente clave dentro de la organización. Gestionar el cambio no es suficiente. También tiene que liderarlo. Puede encontrar líderes del cambio dentro de la empresa. Para liderar el cambio, debe reunir una coalición o equipo de personas influyentes cuyo poder proviene de una variedad de fuentes, incluyendo los puestos que ocupan, status, experiencia e importancia política. Una vez formada, su “coalición” necesita trabajar como equipo, en la continua construcción de la urgencia y del impulso en torno a la necesidad del cambio. Los líderes del cambio comparten tres características:   

Creen de forma persistente que la revitalización es la clave de la competitividad Fundamentan su convicción bajo una visión creíble y apremiante. Tienen las habilidades necesarias para relacionarse con las personas y son poseedoras de un gran conocimiento de la organización, poniendo en práctica la visión.

2.3.5.4

Fase 4

Objetivo: Concentrarse en los resultados y no en las actividades. Es preferible establecer unos objetivos mensurables de actuación a corto plazo aparcando inicialmente los largos planes de preparación, formación, Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 31 de 141

desarrollo de cursos, etc. Se pretende obtener soluciones satisfactorias más que óptimas. 2.3.5.5

Fase 5

Objetivo: Empezar el cambio en la periferia, dejando que después se extienda a otras unidades sin presionar desde arriba. El proceso de cambio tendrá mayor probabilidad de éxito en la medida que el cambio se impulse desde unidades pequeñas y bastante autónomas. Estas unidades deberán percibir que obtienen claras ventajas respecto al statu quo, que es compatible con los valores, experiencias y necesidades, desde un punto de vista directivo, las exigencias son comprensibles, además de proporcionar la oportunidad a los empleados de experimentar el modelo de cambio a pequeña escala. 2.3.5.6

Fase 6

Objetivo: Institucionalizar el éxito por medio de políticas, sistemas y estructuras formales Muchos proyectos de cambio fracasan por celebrar los éxitos de manera anticipada. El cambio real sucede muy profundamente. Las victorias tempranas son sólo el comienzo de lo que se necesita hacer para lograr los cambios a largo plazo. Pero la búsqueda de las mejoras debe ser incesante. Cada victoria proporciona una oportunidad para construir sobre lo que salió bien y determinar qué se puede mejorar. La mejora continua es el objetivo máximo y final. 2.3.5.7

Fase 7

Objetivo: Vigilar atentamente y ajustar las estrategias en respuesta a los problemas del proceso de cambio. En general, cualquier programa de cambio no se cumple al pie de la letra. Durante su ejecución, es normal encontrarse en el camino con una gran cantidad de problemas no previstos o impedimentos, ya sean de carácter interno y/o externo. Por ello, es fundamental que los líderes del cambio sean flexibles y que tengan la suficiente resiliencia como para adecuarse a las posibles alteraciones. En cualquier programa de cambio, hay una delgada línea que separa el liderazgo de la de dirección. Mientras que el líder crea una visión atractiva de futuro y desarrollan todo un plan para hacerla realidad motivando a la gente, la dirección debe preocuparse y ocuparse que todas las tareas Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 32 de 141

necesarias para llegar a tal fin funcionen sin ningún tipo de problemas. A continuación, presentamos la relación entre el liderazgo y la dirección a través de la siguiente matriz:

Figura 2.5: Matriz liderazgo / dirección

2.3.6 Implementación del Cambio En muy pocas ocasiones, la implantación del cambio se realiza sin sobresaltos pues entra dentro de la normalidad que se cometan equivocaciones, que los factores externos trastornen la planificación, rotaciones de personas clave, falla la comunicación, etc. Una implantación efectiva del cambio comienza por tener en cuenta y ser consciente de los principales problemas que se producen en la puesta en marcha de un cambio y son los siguientes:  

Desviaciones en tiempo respecto a lo que se estimó inicialmente Aparición de problemas no identificados inicialmente

0 y Gestión Ágil de Proyectos… Tratado para la Dirección Versión 3.2

++ Pág. 33 de 141

    

Baja eficiencia en la coordinación de las actividades de puesta en práctica Actividades enfrentadas y crisis distrajeron la atención de la implantación Falta de capacidades y habilidades de las personas implicadas Poca adecuación de la formación a la puesta en práctica del cambio Factores externos incontrolables

Para mejorar las probabilidades de éxito, es fundamental tener éxito en los siguientes desafíos:      

Conseguir el apoyo y la implicación de personas clave Idear un plan de puesta en práctica Apoyar el plan a través de conductas y mensajes consistentes Desarrollar unas estructuras facilitadoras Celebrar los hitos conseguidos Comunicar

2.3.6.1

Conseguir el apoyo y la implicación de personas clave

Todo inicio de cambio debe comenzar consiguiendo un equipo de trabajo efectivo e implicado que sean capaces de actuar conjuntamente para conseguir unos objetivos establecidos. Para ello, este equipo de personas deberá estar formado por directivos y empleados que sean respetados por los demás, que proporcione credibilidad al resto y que cuenten con capacidades, habilidades y responsabilidades clave dentro de la organización. 2.3.6.2 



Idear un plan de puesta en práctica

Una visión clara y compartida del cambio facilita la canalización de los esfuerzos del equipo de trabajo para conseguir los objetivos propuestos. Pero este equipo también necesita un plan que describa qué es lo que tienen que hacer, cuándo y cómo tienen que hacerlo. Un plan efectivo suele presentar las siguientes características: o Sencillo o Es generado por todas aquellas personas en los diferentes niveles que se vean afectados por el cambio. Con esto conseguiremos una mayor implicación de todos. Los cambios por convicción suelen ser menos resistentes que los cambios por imposición o Estructurado en actividades que se pueden alcanzar. o Definir roles y responsabilidades o Flexible y vivo antes nuevos cambios y revisiones

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 34 de 141

2.3.6.3

Apoyar el plan a través de conductas y mensajes consistentes

Es vital para el transcurrir normal de la puesta en marcha, que una vez conseguido el apoyo necesario para ejecutarlo, éste se mantenga a través de comportamientos y mensajes coherentes. 2.3.6.4

Desarrollar unas estructuras facilitadoras

Este plan de acción es sostenido a través de actividades y programas que facilitan la consecución de los objetivos marcados. Generalmente, este tipo de actividades incluyen programas piloto, formación y un sistema de recompensa. Los programa piloto proporcionan oportunidades a personas para que éstas aborden la implantación y los problemas pero a una escala más pequeña. Los programas de formación están orientados a facilitar y mejorar la implantación del cambio. Por último, un sistema de recompensa bien diseñado facilita la motivación y la productividad en este tipo de programas de cambio. 2.3.6.5

Celebrar los hitos conseguidos

Es necesario para mantener altos niveles de energía y estados emocionales positivos. 2.3.6.6

Comunicar

Es fundamental comunicar sin descanso, de forma que motive e implique a todas las partes interesadas para superar con la mayor suavidad posible la resistencia al cambio preparando a todos ante posibles altibajos, desviaciones, etc. Los mensajes de comunicación suelen ir orientados a comunicar los siguientes aspectos:           

Naturaleza del cambio Motivos del cambio Aclarar el alcance del cambio, ya sea positivo o negativo Usar herramientas visuales para explicar el proyecto de cambio Pronosticar los aspectos negativos de la implantación Medición de hitos y criterios que se utilizarán para indicarnos el éxito Recompensas asociadas a los éxitos Repetir el propósito del cambio y las acciones planificadas Variar el estilo de comunicación atendido a su audiencia Facilitar la comunicación bidireccional Ser un anuncio viviente del programa de cambio

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 35 de 141

2.3.7 El Cambio Sistemático Los beneficios de un único proyecto de cambio en los tiempos en los que nos movemos no suelen durar para siempre. Aquellas organizaciones que durante programas de cambio desarrollaron productos y servicios despuntando en los mercados, ven como de manera gradual van pasando de la innovación a la defensa a muerte de un segmento de clientes. Por otro lado, paulatinamente la organización sufre un acomodamiento progresivo y reactivo, lo que termina en una urgente necesidad de hacer grandes cambios. Por lo tanto, es absolutamente fundamental que la organización esté continuamente respondiendo a toda clase de estímulos externos (clientes, mercados, competidores, etc.) al mismo tiempo que mejorando los factores internos para proporcionar una respuesta adecuada. El cambio por tanto se produce de manera natural y continuada a través de pequeños cambios proporcionando los siguientes beneficios:    

Facilita la gestión de los cambios Aumenta la probabilidad de éxito Mejora el control de impedimentos Se obtienen niveles estables de competitividad, preparación y buena disposición al cambio

A continuación, ofrecemos una serie de consejos destinados a poner en práctica el cambio continuo y progresivo en una organización y aumentar las probabilidades de éxito:   

Preparar a la organización para el cambio Monitorizar sistemáticamente el mundo exterior Monitorizar interna continua

Dotar a los equipos de trabajo de cosas que proporcionen sentido de rutina, familiaridad y continuidad, pues científicamente está probado que un exceso de cambio es insalubre, perturbador e inquietante. Teniendo en cuenta que las personas somos animales sociales y que el trabajo tiene una importante dimensión social, algunas actividades para mantener estos vínculos bien intactos suelen ser las que facilitan oportunidades compartiendo almuerzos, realizando actividades de ocio (deporte) y cosas por el estilo.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 36 de 141

Capítulo 3 LA PLANIFICACIÓN Y SUS PERSPECTIVAS

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 37 de 141

3.1 Ejecución Incremental por Fases La ejecución por fases plantea no hacer un único entregable al final del proyecto, sino planificar diferentes hitos intermedios con sus correspondientes entregables que nos sirvan para validar nuestro progreso e identificar nuestros errores cuanto antes, con el objetivo de abaratarlos lo máximo posible. El proyecto se planifica en bloques temporales, comúnmente llamado iteraciones o fases. En general, en cada fase se repite un proceso de trabajo similar. Los métodos iterativos o por fases, muy presentes en la matemática computacional, se suelen utilizar para resolver problemas que implican tal número de variables que los métodos directos (es decir, lo que intentan resolver el problema de una sola vez) tendrían un coste inviable. Recordemos que nos movemos en un entorno donde la incertidumbre es alta, donde el problema que pretendemos resolver es complejo, el número de variables es grande y donde por tanto sería conveniente no esperar hasta el final del proyecto para validar si lo que estamos haciendo es correcto o por el contrario nos estamos equivocando en algo. La ejecución incremental se basa en el desarrollo por fases, pero incluye importantes matices con el objetivo de que el entregable producido en cada iteración tenga mucho más valor. En el enfoque incremental cada entrega es un subconjunto del producto final. A medida que se suceden las entregas se incrementan las características y el valor del producto final. Por lo que es vital generar desde la primera fase un producto que tenga valor, que se pueda validar, que se pueda evaluar, del que se pueda extraer conclusiones y aprender para aplicar ese nuevo conocimiento en la siguiente fase. De este modo el cliente obtiene beneficios del proyecto de forma incremental, proporcionando resultados anticipados y disminuyendo el “time to market”.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 38 de 141

3.2 Actividades ejecutadas vs Valor entregado En la gestión de proyectos tradicional, la forma habitual de proceder a planificar un proyecto es recopilar requisitos, determinar el alcance, derivar las tareas necesarias para darles cumplimiento y estimar el tiempo y los recursos necesarios para llevarlas a cabo. El paradigma ágil no se basa en el desglose de actividades, sino en la definición de características que al crearlas proporcionan valor para el cliente. Esta es la base para una ejecución incremental por fases. Esto supone un cambio de paradigma enorme en cuyo epicentro se sitúa el cliente y que está plenamente orientado a ayudarle a que emerjan sus necesidades, a descubrir lo que realmente desea y a satisfacerle plenamente.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 39 de 141

3.3 Una panorámica al flujo de trabajo El proyecto comienza con una visión de lo que se va a desarrollar. El reto está en entregarles la consecución de la visión de un modo que maximice su ROI en todo momento. Para ello, se construye una lista de requerimientos potencialmente entregables que supone un punto de inicio. Sus contenidos y prioridades cambiarán a medida que el proyecto avance. La ejecución del proyecto es por fases, de forma incremental. Todas las fases tendrán la misma duración para conseguir un ritmo sostenible y consolidar los hábitos efectivos de trabajo. En cada fase, primero se decidirá QUÉ se va a hacer y luego CÓMO se va llevar a cabo, de modo que el trabajo en esa fase se define y se acota. Esta planificación cristaliza en una lista de tareas que transformarán los requisitos seleccionados para esa fase en un incremento de características del producto final. Una consecuencia directa es que las personas encargadas de la ejecución estén plenamente focalizadas durante la fase. Cada día de ejecución, se comparte el desempeño y los impedimentos, se sincroniza el trabajo de todos los miembros del equipo, se da visibilidad a los progresos de cada miembro y se comienzan a resolver los impedimentos. Al final de la fase se revisa el producto desarrollado durante la misma. Antes del comenzar la siguiente fase se revisan los procesos y prácticas utilizados en el proyecto, de modo que sean más efectivos y más agradables en la siguiente fase. Sin entrar en detalles en este punto, en esta panorámica ya se intuye cómo se pone de manifiesto valores como la comunicación o la inspección y adaptación empíricas referidos cuando hablamos sobre la complejidad.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 40 de 141

3.4 Modelos tradicionales, en ocasiones útiles A continuación presentamos una serie de técnicas que han venido utilizándose en el paradigma (la tan reconocida ANSI/PMI 99-001-2004) tradicional de planificación de actividades, y que en las ocasiones donde todo es susceptible de ser previsto y esquematizado son muy útiles; por tanto merece la pena conocer. 3.4.1 Descomposición La descomposición es la subdivisión de los entregables del proyecto en componentes más pequeños y más manejables, hasta que el trabajo y los entregables queden definidos al nivel de paquetes de trabajo. El nivel de paquetes de trabajo es el nivel más bajo en la EDT, y es aquél en el que el costo y la duración de las actividades del trabajo pueden estimarse y gestionarse de manera más confiable. El nivel de detalle para los paquetes de trabajo varía en función del tamaño y la complejidad del proyecto. La descomposición de la totalidad del trabajo del proyecto en paquetes de trabajo implica generalmente las siguientes actividades: • • • • •

identificar y analizar los entregables y el trabajo relacionado estructurar y organizar la EDT descomponer los niveles superiores de la EDT en componentes detallados de nivel inferior desarrollar y asignar códigos de identificación a los componentes de la EDT verificar que el grado de descomposición del trabajo sea el necesario y suficiente

La estructura de la EDT puede crearse de diferentes maneras, tales como: •

• •

Usando las fases del ciclo de vida del proyecto como primer nivel de descomposición, con los entregables del producto y del proyecto insertados en el segundo nivel. Usando los entregables principales como primer nivel de descomposición. Usando subproyectos que pueden ser ejecutados por organizaciones externas al equipo del proyecto, como trabajo contratado. En el marco de un trabajo mediante contrato, el vendedor desarrollará la estructura de desglose del trabajo contratado correspondiente.

La descomposición de los componentes del nivel superior de la EDT requiere subdividir el trabajo para cada uno de los entregables o subproyectos en

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 41 de 141

sus componentes fundamentales, hasta el nivel en que los componentes de la EDT representen productos, servicios o resultados verificables. La EDT puede estructurarse como un esquema, un organigrama, un diagrama de espina de pescado o cualquier otro método. La verificación de la exactitud de la descomposición requiere determinar que los componentes de nivel inferior de la EDT sean los necesarios y suficientes para completar los entregables de alto nivel correspondientes. Cada entregable diferente puede tener diferentes niveles de descomposición. Para llegar al nivel del paquete de trabajo, en el caso de algunos entregables sólo se necesitará descomponer el trabajo al siguiente nivel, mientras que en otros casos será necesario añadir niveles suplementarios de descomposición. Conforme se descompone el trabajo en niveles de mayor detalle, la capacidad de planificar, gestionar y controlar el trabajo es mayor. Sin embargo, una descomposición excesiva puede ocasionar un esfuerzo improductivo de gestión, un uso ineficaz de recursos y una disminución de la eficiencia de realización del trabajo. En el caso de entregables o subproyectos cuya realización se sitúe en un futuro lejano, es probable que no pueda realizarse la descomposición. Normalmente, el equipo de dirección del proyecto espera hasta que el entregable o subproyecto sea lo suficientemente claro para poder desarrollar los detalles de la EDT. Esta técnica se denomina a veces planificación gradual. La EDT representa todo el trabajo necesario para realizar el producto o el proyecto, e incluye el trabajo de gestión del proyecto. El total del trabajo en los niveles inferiores de la EDT debe corresponder al cúmulo de los niveles superiores, de modo que no se omita nada y que no se efectúe ningún trabajo innecesario. Esto se denomina a veces la regla del 100 %. 3.4.2 Planificación Gradual La planificación gradual es una forma de planificación mediante elaboración gradual, donde se planifica en detalle el trabajo que debe desarrollarse en el corto plazo y el trabajo futuro se planifica a un nivel superior de la EDT. Por lo tanto, dependiendo de su ubicación en el ciclo de vida del proyecto, el trabajo puede existir en diferentes niveles de detalle. Por ejemplo, durante la planificación estratégica temprana, donde la información está menos definida, los paquetes de trabajo pueden descomponerse a nivel de hitos. Conforme se conoce más acerca de los próximos eventos en el corto plazo, pueden descomponerse en actividades.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 42 de 141

3.4.3 Plantillas Una lista de actividades estándar o una parte de una lista de un proyecto previo, puede utilizarse a menudo como plantilla para un nuevo proyecto. La información relacionada con los atributos de las actividades de las plantillas también puede incluir otra información descriptiva útil para la definición de las actividades. Las plantillas también pueden utilizarse para identificar hitos típicos del cronograma. 3.4.4 Método de Diagramación por Precedencia (PDM) El método de diagramación por precedencia (PDM) es utilizado en el método de la ruta crítica (CPM) para crear un diagrama de red del cronograma del proyecto que utiliza casillas o rectángulos, denominados nodos, para representar las actividades, que se conectan con flechas que muestran sus relaciones lógicas. Esta técnica también se denomina actividad en el nodo (AON) y es el método utilizado por la mayoría de los paquetes de software de gestión de proyectos. El método de diagramación por precedencia incluye cuatro tipos de dependencias o relaciones lógicas.    

Final a Inicio. El inicio de la actividad sucesora depende de la finalización de la actividad predecesora. Final a Final. La finalización de la actividad sucesora depende de la finalización de la actividad predecesora. Inicio a Inicio. El inicio de la actividad sucesora depende del inicio de la actividad predecesora. Inicio a Final. La finalización de la actividad sucesora depende del inicio de la actividad predecesora.

El tipo de relación de precedencia final a inicio es el más comúnmente utilizado por el método de diagramación por precedencia. La relación inicio a final se usa esporádicamente, pero se incluye aquí para proporcionar una lista completa de los tipos de relaciones de este método. 3.4.5 Determinación de Dependencias Para definir la secuencia entre las actividades, se emplean tres tipos de dependencias: 

Dependencias obligatorias. Las dependencias obligatorias son aquéllas requeridas por contrato, a) o inherentes a la naturaleza del trabajo. El equipo del proyecto determina qué dependencias son obligatorias durante el proceso de establecimiento de la secuencia de las actividades. Las

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 43 de 141

dependencias obligatorias a menudo implican limitaciones físicas, como en un proyecto de construcción, donde es imposible erigir la superestructura hasta tanto no se construyan los cimientos; b) o en un proyecto de electrónica, donde se debe construir el prototipo antes de poder probarlo. A veces se utiliza la expresión “lógica dura” para referirse a las dependencias obligatorias. 

Dependencias discrecionales. El equipo del proyecto determina qué dependencias son discrecionales durante el proceso de establecimiento de la secuencia de las actividades. A veces, las dependencias discrecionales se denominan lógica preferida, lógica preferencial o lógica blanda. Las dependencias discrecionales se establecen con base en el conocimiento de las mejores prácticas dentro de un área de aplicación determinada o a algún aspecto poco común del proyecto, donde se desea una secuencia específica, aunque existan otras secuencias aceptables. Las dependencias discrecionales deben documentarse totalmente, ya que pueden crear valores arbitrarios de holgura total y pueden limitar las opciones posteriores de planificación. Cuando se emplean técnicas de ejecución rápida, estas dependencias discrecionales deben revisarse, y debe considerarse su modificación o eliminación.



Dependencias externas. El equipo de dirección del proyecto determina qué dependencias son externas durante el proceso de establecimiento de la secuencia de las actividades. Las dependencias externas implican una relación entre las actividades del proyecto y aquéllas que no pertenecen al proyecto. Normalmente, estas dependencias están fuera del control del equipo del proyecto. Por ejemplo, la actividad de prueba en un proyecto de software puede depender de la entrega del hardware por parte de una fuente externa, o en el caso de un proyecto de construcción, puede ser necesario realizar informes gubernamentales de evaluación del impacto ambiental antes de iniciar la preparación del emplazamiento. 3.4.6 Aplicación de Adelantos y Retrasos

El equipo de dirección de proyecto determina las dependencias que pueden necesitar un adelanto o un retraso para definir con exactitud la relación lógica. No deben utilizarse adelantos y retrasos para sustituir la lógica de la planificación. Deben documentarse las actividades y sus supuestos relacionados. Un adelanto permite una aceleración de la actividad sucesora. Por ejemplo, en un proyecto para la construcción de un nuevo edificio de oficinas, puede Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 44 de 141

planificarse que el desmonte del terreno comience dos semanas antes de la fecha programada para completar la lista de pendientes. Esto debe mostrarse como una relación lógica final a inicio, con un adelanto de dos semanas. Un retraso ocasiona una demora en la actividad sucesora. Por ejemplo, un equipo de redacción técnica puede comenzar a editar el borrador de un documento extenso quince días después de haber comenzado a escribirlo. Esto puede mostrarse como una relación lógica inicio a inicio con un retraso de 15 días. 3.4.7 Plantillas de Red del Cronograma Para acelerar la preparación de las redes de actividades del proyecto, pueden emplearse plantillas normalizadas del diagrama de red del cronograma del proyecto. Pueden abarcar un proyecto completo o sólo una parte del mismo. Las partes de un diagrama de red del cronograma del proyecto se denominan a menudo subred o fragmento de red. Las plantillas de las subredes son especialmente útiles cuando un proyecto abarca varios entregables idénticos o casi idénticos, como los pisos de un edificio alto de oficinas, los estudios clínicos de un proyecto de investigación farmacológica, los módulos de codificación de programas de un proyecto de software o la fase de lanzamiento de un proyecto de desarrollo. 3.4.8 Análisis de la Red del Cronograma El análisis de la red del cronograma es una técnica utilizada para generar el cronograma del proyecto. Emplea diversas técnicas analíticas, tales como el método de la ruta crítica, el método de la cadena crítica, el análisis “¿Qué pasa si…?” y la nivelación de recursos, para calcular las fechas de inicio y finalización tempranas y tardías para las partes no completadas de las actividades del proyecto. Algunos caminos de red pueden tener puntos de convergencia o divergencia de rutas que pueden identificarse y emplearse en el análisis de compresión del cronograma o en otros análisis. 3.4.9 Método de la Ruta Crítica El método de la ruta crítica calcula las fechas teóricas de inicio y finalización tempranas y tardías para todas las actividades, sin considerar las limitaciones de recursos, realizando un análisis que recorre hacia adelante y hacia atrás toda la red del cronograma. Las fechas de inicio y finalización tempranas y tardías resultantes no constituyen necesariamente el cronograma, sino que más bien indican los periodos dentro de los cuales pueden planificarse las actividades, teniendo Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 45 de 141

en cuenta las duraciones de las actividades, las relaciones lógicas, los adelantos, los retrasos y otras restricciones conocidas. Las fechas de inicio y finalización tempranas y tardías calculadas pueden ser afectadas por la holgura total de la actividad que proporciona flexibilidad al cronograma y cuyo valor puede ser positivo, negativo o nulo. En cualquier camino de red, la flexibilidad del cronograma se mide por la diferencia positiva entre las fechas tempranas y tardías, lo cual se conoce como “holgura total”. Las rutas críticas tienen una holgura total igual a cero o negativa y las actividades del cronograma en una ruta crítica reciben el nombre de “actividades críticas”. Una ruta crítica se caracteriza normalmente por el hecho de que su holgura total es igual a cero. Las redes pueden tener varias rutas casi críticas. Puede ser necesario realizar ajustes a las duraciones de las actividades, a sus relaciones lógicas, a los adelantos y a los retrasos, o a otras restricciones del cronograma para lograr caminos de red con una holgura total igual a cero o positiva. Una vez que se ha calculado la holgura total de un camino de red, entonces puede determinarse la holgura libre, que es la cantidad de tiempo que una actividad puede retrasarse dentro de un camino de red, sin demorar la fecha de inicio temprana de cualquier actividad sucesora inmediata dentro de dicho camino de red. 3.4.10 Método de la Cadena Crítica La cadena crítica es una técnica de análisis de la red del cronograma que permite modificar el cronograma del proyecto para adaptarlo a los recursos limitados. Inicialmente, el diagrama de red del cronograma del proyecto se elabora mediante los estimados de la duración, con las dependencias requeridas y las restricciones definidas como entradas. Entonces se calcula la ruta crítica. Una vez que se ha identificado la ruta crítica, se ingresa la disponibilidad de recursos y se determina el resultado del cronograma con recursos limitados. A menudo, el cronograma resultante presenta una ruta crítica modificada. La ruta crítica con restricciones de recursos se conoce como cadena crítica. El método de la cadena crítica agrega colchones de duración, que son actividades del cronograma que no requieren trabajo y que se utilizan para manejar la incertidumbre. Un colchón que se coloca al final de la cadena crítica se conoce como colchón del proyecto y protege la fecha de Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 46 de 141

finalización objetivo contra cualquier retraso a lo largo de la cadena crítica. Se colocan colchones adicionales, conocidos como colchones de alimentación, en cada punto donde una cadena de tareas dependientes, que está fuera de la cadena crítica, la alimenta. De este modo, los colchones de alimentación protegen la cadena crítica contra retrasos a lo largo de las cadenas de alimentación. La dimensión de cada colchón debe tener en cuenta la incertidumbre en la duración de la cadena de tareas dependientes que conducen a ese colchón. Una vez que se han determinado las actividades del cronograma con colchón, las actividades previstas se planifican en base a sus fechas posibles de inicio y finalización programadas más tardías. Consecuentemente, en lugar de gestionar la holgura total de los caminos de red, el método de la cadena crítica se concentra en gestionar las duraciones restantes de los colchones en función de las duraciones restantes de las cadenas de tareas. 3.4.11

Nivelación de Recursos

La nivelación de recursos es una técnica de análisis de la red del cronograma que se aplica a un cronograma que ya ha sido analizado por medio del método de la ruta crítica. La nivelación de recursos puede utilizarse cuando los recursos compartidos o críticos necesarios sólo están disponibles en ciertos momentos o en cantidades limitadas, o para mantener la utilización de recursos en un nivel constante. La nivelación de recursos es necesaria cuando los recursos han sido sobre asignados, es decir, cuando un recurso se ha asignado a dos o más tareas para el mismo periodo, o cuando los recursos compartidos o críticos necesarios sólo están disponibles en ciertos periodos o en cantidades limitadas. La nivelación de recursos provoca a menudo cambios en la ruta crítica. 3.4.12 Análisis “¿Qué pasa si…?” Éste es un análisis de la pregunta “¿Qué pasa si se produce la situación representada por el escenario ‘X’?” Se realiza un análisis de la red del cronograma, usando el cronograma para calcular los diferentes escenarios, tales como un retraso en la entrega de un componente principal, la prolongación de la duración de un diseño específico o la introducción de factores externos, como una huelga o un cambio en el procedimiento para la obtención de permisos. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 47 de 141

Los resultados del análisis del escenario “Qué pasa si…” pueden usarse para evaluar la viabilidad del cronograma del proyecto bajo condiciones adversas, y para preparar planes de contingencia y respuesta para superar o mitigar el impacto de situaciones inesperadas. La simulación implica calcular múltiples duraciones del proyecto a partir de diferentes conjuntos de supuestos sobre las actividades. La técnica más común es la del análisis Monte Carlo, en el cual se define una distribución de duraciones posibles para cada actividad, que es usada para calcular una distribución de posibles resultados para todo el proyecto. 3.4.13 Compresión del Cronograma La compresión del cronograma reduce el calendario del proyecto sin modificar el alcance del mismo, para cumplir con las restricciones del cronograma, las fechas impuestas u otros objetivos del cronograma. Las técnicas de compresión del cronograma incluyen: 

Compresión. Una técnica de compresión del cronograma en la cual se analizan las concesiones entre costo y cronograma para determinar cómo obtener la mayor compresión con el menor incremento de costo. Ejemplos de compresión pueden incluir la aprobación de horas suplementarias, el aporte de recursos adicionales o un pago adicional para acelerar la entrega de las actividades que se encuentran en la ruta crítica. La compresión sólo funciona para actividades en las que los recursos adicionales permiten acortar la duración. La compresión no siempre resulta una alternativa viable y puede ocasionar un incremento del riesgo y/o del costo.



Ejecución rápida. Una técnica de compresión del cronograma en la cual las fases o actividades que normalmente se realizarían en forma secuencial, se realizan en paralelo. Un ejemplo de esto es la construcción de los cimientos de un edificio antes de finalizar todos los planos arquitectónicos. La ejecución rápida puede dar como resultado un reproceso y un aumento del riesgo. La ejecución rápida sólo funciona en actividades que pueden superponerse para acortar la duración. 3.4.14 Estimación Análoga

La estimación de costos por analogía utiliza los valores de parámetros como el alcance, el costo, el presupuesto y la duración, o medidas de escala tales como el tamaño, el peso y la complejidad de un proyecto anterior similar,

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 48 de 141

como base para estimar el mismo parámetro o medida para un proyecto actual. Cuando se trata de estimar los costos, esta técnica utiliza el costo real de proyectos similares anteriores como base para estimar el costo del proyecto actual. Es un método de estimación del valor bruto, que a veces se ajusta en función de diferencias conocidas en cuanto a la complejidad del proyecto. La estimación de costos por analogía se emplea frecuentemente para estimar un parámetro cuando existe una cantidad limitada de información detallada sobre el proyecto, como es el caso, por ejemplo, en sus fases iniciales. La estimación de costos por analogía utiliza la información histórica y el juicio de expertos. Por lo general, la estimación de costos por analogía es menos costosa y requiere menos tiempo que las otras técnicas, pero también es menos exacta. Puede aplicarse a todo un proyecto o a partes del mismo, y puede utilizarse en conjunto con otros métodos de estimación. La estimación análoga es más confiable cuando el proyecto anterior es similar, no sólo en apariencia sino en los hechos, y cuando los miembros del equipo del proyecto responsables de efectuar las estimaciones poseen la experiencia necesaria. 3.4.15 Estimación Paramétrica La estimación paramétrica utiliza una relación estadística entre los datos históricos y otras variables (p.e., metros cuadrados de construcción) para calcular una estimación de parámetros de una actividad tales como costo, presupuesto y duración. Con esta técnica pueden lograrse niveles superiores de exactitud, dependiendo de la sofisticación y de los datos que utilice el modelo. La estimación paramétrica de costos puede aplicarse a todo un proyecto o a partes del mismo, en conjunto con otros métodos de estimación. 3.4.16 Estimación Ascendente La estimación ascendente es un método para estimar los componentes del trabajo. El costo de cada paquete de trabajo o de cada actividad se calcula con el mayor nivel de detalle. El costo detallado luego se resume o “acumula” en niveles superiores para fines de información y seguimiento. En general, la magnitud y complejidad de la actividad o del paquete de trabajo individual influyen en el costo y la exactitud de la estimación ascendente de costos. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 49 de 141

3.4.17 Estimación por Tres Valores La exactitud de las estimaciones de costos de una actividad única puede mejorarse tomando en consideración la incertidumbre y el riesgo. Este concepto se originó con la Técnica de Revisión y Evaluación de Programas (PERT). PERT utiliza tres estimados para definir un rango aproximado de costo de una actividad: •

• •

Más probable (cM). El costo de la actividad se basa en una evaluación realista del esfuerzo necesario para el trabajo requerido y cualquier gasto previsto. Optimista (cO). El costo de la actividad se basa en el análisis del mejor escenario posible para esa actividad. Pesimista (cP). El costo de la actividad se basa en el análisis del peor escenario posible para esa actividad.

El análisis según el método PERT calcula un costo Esperado (CE) de la actividad utilizando un promedio ponderado de estas tres estimaciones: cE = (cO + 4cM + cP) / 6 Las estimaciones de costos basadas en esta ecuación (o aun en un promedio simple de los tres valores) pueden proporcionar una mayor exactitud, y los tres valores aclaran el rango de incertidumbre de las estimaciones de costos. 3.4.18 Análisis de Reserva Las estimaciones de costos pueden incluir reservas para contingencias (llamadas a veces asignaciones para contingencias) para tener en cuenta la incertidumbre del costo. La reserva para contingencias puede ser un porcentaje del costo estimado, una cantidad fija, o puede calcularse utilizando métodos de análisis cuantitativos. A medida que se dispone de información más precisa sobre el proyecto, la reserva para contingencias puede utilizarse, reducirse o eliminarse. Debe identificarse claramente esta contingencia en la documentación del cronograma. Las reservas para contingencias forman parte de los requisitos de financiamiento. 3.4.19 Análisis de Propuestas para Licitaciones Los métodos de estimación de costos pueden incluir el análisis de cuánto debe costar el proyecto, con base en las propuestas de proveedores calificados.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 50 de 141

En los casos en los que los proyectos se otorgan mediante procesos competitivos, se puede solicitar al equipo del proyecto un trabajo adicional de estimación de costos para examinar el precio de los entregables individuales y obtener un costo que sustente el costo total final del proyecto. 3.4.20 Análisis Costo-Beneficio Los principales beneficios de cumplir con los requisitos de calidad pueden incluir un menor reproceso, una mayor productividad, menores costos y una mayor satisfacción de los interesados. Un caso de negocio para cada actividad de calidad permite comparar el costo del procedimiento de calidad con el beneficio esperado. 3.4.21 Costo de la Calidad (COQ) El costo de la calidad incluye todos los costos en los que se ha incurrido durante la vida del producto en inversiones para prevenir el incumplimiento de los requisitos, para evaluar la conformidad del producto o servicio con los requisitos, y por no cumplir con los requisitos (reproceso). Los costos por fallos se clasifican a menudo en internos (constatados por el equipo del proyecto) y externos (constatados por el cliente). Los costos por fallos también se denominan costo por calidad deficiente. 3.4.22 Diagramas de Control Los diagramas de control se utilizan para determinar si un proceso es estable o no, o si tiene un desempeño predecible. Los límites superior e inferior de las especificaciones se basan en los requisitos del contrato. Reflejan los valores máximo y mínimo permisibles. Puede haber sanciones asociadas con el incumplimiento de los límites de las especificaciones. El director del proyecto y los interesados apropiados establecen los límites de control superior e inferior para reflejar los puntos en los cuales deben implementarse acciones correctivas para evitar que se sobrepasen los límites de las especificaciones. Para procesos repetitivos, los límites de control se establecen por lo general en ± 3σ. Un proceso se considera fuera de control cuando un punto de datos excede un límite de control o cuando siete puntos consecutivos se encuentran por encima o por debajo de la media. Los diagramas de control pueden utilizarse para monitorear diferentes tipos de variables de salida. Aunque se utilizan más frecuentemente para rastrear actividades repetitivas tales como las relativas a la fabricación de lotes, los Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 51 de 141

diagramas de control también pueden usarse para monitorear las variaciones del costo y del cronograma, la cantidad y frecuencia de los cambios en el alcance, u otros resultados de gestión, para ayudar a determinar si los procesos de dirección del proyecto se encuentran bajo control. 3.4.23 Estudios Comparativos Los estudios comparativos implican comparar prácticas reales o planificadas del proyecto con las de proyectos comparables para identificar las mejores prácticas, generar ideas de mejoras y proporcionar una base para la medición del desempeño. Estos otros proyectos pueden estar dentro o fuera de la organización ejecutante y pueden pertenecer a la misma área de aplicación o a otra. 3.4.24 Diseño de Experimentos El diseño de experimentos (DoE) es un método estadístico para identificar qué factores pueden influir en variables específicas de un producto o proceso en fase de desarrollo o de producción. El DoE debe emplearse durante el proceso Planificar la Calidad para determinar la cantidad y el tipo de pruebas por efectuar, así como su impacto en el costo de la calidad. El DoE también juega un papel en la optimización de productos o procesos. Puede utilizarse para reducir la sensibilidad del desempeño del producto a las fuentes de variación causadas por diferencias ambientales o de fabricación. Un aspecto importante de esta técnica es que proporciona un marco estadístico para cambiar sistemáticamente todos los factores importantes, en lugar de cambiar un factor a la vez. El análisis de los datos experimentales debería proporcionar las condiciones óptimas para el producto o proceso, resaltar los factores que influyen en los resultados y revelar la presencia de interacciones y sinergia entre los factores. Por ejemplo, los diseñadores de automóviles emplean esta técnica para determinar qué combinación de suspensión y neumáticos producirá las mejores características de marcha a un costo razonable. 3.4.25 Muestreo Estadístico El muestreo estadístico consiste en seleccionar una parte de la población de interés para su inspección (por ejemplo, una selección al azar de diez planos de ingeniería a partir de una lista de setenta y cinco planos). La frecuencia y el tamaño de la muestra deben determinarse durante el Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 52 de 141

proceso Planificar la Calidad, de modo que el costo de la calidad incluya el número de pruebas, los rechazos esperados, etc. Existe un cuerpo sustancial de conocimientos sobre muestreo estadístico. En algunas áreas de aplicación, puede ser necesario que el equipo de dirección del proyecto esté familiarizado con diferentes técnicas de muestreo para asegurarse de que la muestra seleccionada sea realmente representativa de la población de interés. 3.4.26 Diagramas de Flujo Un diagrama de flujo es una representación gráfica de un proceso que muestra las relaciones entre las etapas del proceso. Existen muchos estilos de diagramas de flujo, pero todos muestran las actividades, los puntos de decisión y el orden de desarrollo del proceso. Durante la planificación de la calidad, los diagramas de flujo pueden ayudar al equipo del proyecto a anticipar problemas de calidad que pudieran ocurrir. Tener consciencia de los problemas potenciales puede permitir el desarrollo de procedimientos de prueba o métodos para abordarlos. 3.4.27 Metodologías Propietarias de Gestión de la Calidad Existen numerosas metodologías propietarias, entre las que se incluyen, sin pretender dar una lista exhaustiva o de recomendaciones, Six Sigma, Lean Six Sigma, Despliegue de Funciones de Calidad (Quality Function Deployment), CMMI®, etc. 3.4.28 Herramientas Calidad

Adicionales

Planificación

A menudo se emplean otras herramientas de planificación de calidad para ayudar a definir mejor los requisitos de calidad y a planificar actividades eficaces de gestión de calidad. Éstas incluyen, entre otras: • • • •

•

Tormenta de ideas Diagramas de afinidad, que se usan para identificar visualmente los agrupamientos lógicos en base a relaciones naturales. Análisis de campos de fuerzas, que son diagramas de las fuerzas a favor y en contra de un cambio. Técnicas de grupo nominal, que permiten que las ideas se analicen en una tormenta de ideas en grupos pequeños y luego sean revisadas por un grupo más amplio. Diagramas matriciales, que incluyen dos, tres o cuatro grupos de información, y muestran las relaciones entre factores, causas y

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 53 de 141

•

objetivos. Los datos dentro de una matriz se organizan en filas y columnas, con celdas de intersección que pueden completarse con información que describe la relación demostrada entre los elementos de la fila y los de la columna. Matrices de priorización, que brindan un modo de clasificar por orden de importancia un conjunto de problemas diversos y/o polémicas (identificados normalmente por medio de tormentas de ideas). 3.4.29 Diagramas de Causa y Efecto

Los diagramas de causa y efecto, también conocidos como diagramas de Ishikawa o diagramas de espina de pescado, ilustran la manera en que diversos factores pueden estar vinculados con un problema o efecto potencial. Una causa posible puede descubrirse preguntando continuamente “¿por qué?” o “¿cómo?” a lo largo de una de las líneas. Los diagramas “por qué-por qué” y “cómo-cómo” pueden utilizarse en el análisis causal. Los diagramas de causa y efecto también pueden usarse en el análisis de riesgos. 3.4.30 Diagramas de Control En este proceso se recopilan y analizan los datos pertinentes para indicar el estado de la calidad de los procesos y productos del proyecto. Los diagramas de control ilustran la manera en que se comporta un proceso a lo largo del tiempo y cuándo un proceso está sujeto a variación por una causa especial, lo que crea una condición fuera de control. Estos diagramas responden gráficamente a la pregunta: “¿La variación del proceso se encuentra dentro de los límites aceptables?” El patrón de puntos de datos en un diagrama de control puede revelar valores fluctuantes aleatorios, saltos repentinos en el proceso o una tendencia gradual al incremento de la variación. Por medio del monitoreo de las salidas de un proceso a lo largo del tiempo, un diagrama de control puede ayudar a evaluar si la aplicación de cambios a dicho proceso logró las mejoras deseadas. Cuando un proceso se encuentra dentro de los límites aceptables, significa que está controlado y no requiere ajustes. Por el contrario, cuando un proceso se encuentra fuera de los límites aceptables, entonces debe ajustarse. Una sucesión de siete puntos consecutivos fuera de los límites de control superior o inferior indica que el proceso está fuera de control. Normalmente, los límites de control superior e inferior se fijan en ± 3σ, siendo 1σ una desviación estándar.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 54 de 141

3.4.31 Histograma Un histograma es un diagrama de barras verticales que ilustra la frecuencia de ocurrencia de un estado particular de variación. Cada columna representa un atributo o característica de un problema/ una situación. La altura de cada columna representa la frecuencia relativa de la característica. Esta herramienta ayuda a ilustrar la causa más común de los problemas en un proceso por medio del número y las alturas relativas de las barras. 3.4.32 Diagrama de Pareto Un diagrama de Pareto es un tipo específico de histograma, ordenado por frecuencia de ocurrencia. Muestra cuántos defectos se generaron por tipo o categoría de causa identificada. El ordenamiento por categoría se emplea para guiar la acción correctiva. El equipo del proyecto debería atender en primer lugar las causas que provocan el mayor número de defectos. Los diagramas de Pareto están relacionados conceptualmente con la ley de Pareto, que establece que un número relativamente pequeño de causas provocará generalmente la mayoría de los problemas o defectos. Esto se denomina comúnmente principio 80/20, donde el 80 por ciento de los problemas se debe al 20 por ciento de las causas. Los diagramas de Pareto también se pueden usar para resumir diversos tipos de datos y analizarlos según el principio 80/20. 3.4.33 Diagrama de Comportamiento De manera similar a un diagrama de control pero sin mostrar los límites, un diagrama de comportamiento muestra el historial y el patrón de variaciones. Un diagrama de comportamiento es una gráfica lineal que muestra los puntos de datos trazados en el orden en que suceden. Los diagramas de comportamiento muestran las tendencias, variaciones, deterioros o mejoras de un proceso a lo largo del tiempo. El análisis de tendencias se realiza mediante diagramas de comportamiento e implica utilizar técnicas matemáticas para proyectar resultados futuros basándose en resultados históricos. El análisis de tendencias se usa a menudo para supervisar: • •

El desempeño técnico. ¿Cuántos errores o defectos se han identificado y cuántos permanecen sin corregir? El desempeño del costo y del cronograma. ¿Cuántas actividades se completaron por periodo con variaciones significativas?

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 55 de 141

3.4.34 Diagrama de Dispersión Un diagrama de dispersión, muestra la relación entre dos variables. Esta herramienta permite al equipo de calidad estudiar e identificar la posible relación entre los cambios observados en dos variables. Se trazan las variables dependientes frente a las variables independientes. Mientras más próximos se encuentren los puntos con respecto a una línea diagonal, mayor será su relación. 3.4.35 Evaluación Riesgos

Probabilidad

Impacto

los

Mediante esta evaluación se estudia la probabilidad de ocurrencia de cada riesgo específico. La evaluación del impacto de los riesgos investiga el efecto potencial de los mismos sobre un objetivo del proyecto, tal como el cronograma, el costo, la calidad o el desempeño, incluidos tanto los efectos negativos en el caso de las amenazas, como positivos, en el caso de las oportunidades. Para cada riesgo identificado, se evalúan la probabilidad y el impacto. Los riesgos pueden evaluarse en entrevistas o reuniones con participantes seleccionados por su familiaridad con las categorías de riesgo en la agenda. Entre ellos, se incluyen los miembros del equipo del proyecto y, quizás, expertos que no pertenecen al proyecto. Durante estas entrevistas o reuniones, se evalúan el nivel de probabilidad de cada riesgo y su impacto sobre cada objetivo del proyecto. También se registran los detalles explicativos, incluidos los supuestos que justifican los niveles asignados. Las probabilidades e impactos de los riesgos se califican de acuerdo con las definiciones proporcionadas en el plan de gestión de riesgos. Los riesgos con una baja calificación en cuanto a probabilidad e impacto se incluirán en una lista de supervisión para su seguimiento futuro. 3.4.36 Matriz de Probabilidad e Impacto Los riesgos pueden priorizarse para realizar un análisis cuantitativo posterior y elaborar respuestas basadas en su calificación. Por lo general, estas reglas de calificación de los riesgos son definidas por la organización antes del inicio del proyecto y se incluyen en los activos de los procesos de la organización. Las reglas de calificación de los riesgos pueden adaptarse al proyecto específico durante el proceso Planificar la Gestión de Riesgos. Habitualmente, la evaluación de la importancia de cada riesgo y, por consiguiente, de su prioridad de atención, se efectúa utilizando una tabla de Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 56 de 141

búsqueda o una matriz de probabilidad e impacto. Dicha matriz especifica las combinaciones de probabilidad e impacto que llevan a calificar los riesgos con una prioridad baja, moderada o alta. El área gris oscuro (con las cifras más altas) representa un riesgo alto, el área gris intermedio (con las cifras más bajas) representa un riesgo bajo y el área color gris claro (con las cifras intermedias) representa el riesgo moderado. Ilustrativo: Impacto (escala relativa) sobre un objetivo (p.e., costo, tiempo, alcance o calidad). Cada riesgo es calificado de acuerdo con su probabilidad de ocurrencia y el impacto sobre un objetivo en caso de que ocurra. Los umbrales de la organización para riesgos bajos, moderados o altos se muestran en la matriz y determinan si el riesgo es calificado como alto, moderado o bajo para ese objetivo. Probabilidad

Amenazas

Oportunidades

0,90

0,05 0,09 0,18 0,36 0,72 0,72 0,36 0,18 0,09 0,05

0,70

0,04 0,07 0,14 0,28 0,56 0,56 0,28 0,14 0,07 0,04

0,50

0,03 0,05 0,10 0,20 0,40 0,40 0,20 0,10 0,05 0,03

0,30

0,02 0,03 0,06 0,12 0,24 0,24 0,12 0,06 0,03 0,02

0,10

0,01 0,01 0,02 0,04 0,08 0,08 0,04 0,02 0,01 0,01 0,05 0,10 0,20 0,40 0,80 0,80 0,40 0,20 0,10 0,05 Figura 3.1: Matriz de Probabilidad e Impacto

Como se ilustra en el Gráfico, una organización puede calificar un riesgo por separado para cada objetivo (p.e., costo, tiempo y alcance). Además, puede desarrollar formas de determinar una calificación general para cada riesgo. Puede elaborarse un esquema de calificación para el proyecto global, con el propósito de reflejar la preferencia de la organización por un objetivo determinado sobre otros y la utilización de tales preferencias para proceder a una ponderación de los riesgos evaluados para cada objetivo. Finalmente, las oportunidades y las amenazas pueden manejarse en la misma matriz, utilizando las definiciones de los diversos niveles de impacto apropiados para cada una de ellas.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 57 de 141

La calificación de los riesgos ayuda a guiar las respuestas a los riesgos. Por ejemplo, los riesgos que, si se concretan (amenazas), tienen un impacto negativo sobre los objetivos, y que se encuentran en la zona de riesgo alto (gris oscuro) de la matriz, pueden necesitar prioridad de acción y estrategias de respuesta agresivas. Las amenazas en la zona de riesgo bajo (gris intermedio) pueden no necesitar una acción de gestión proactiva, más allá de ser incluidas en una lista de supervisión o de ser agregadas a una reserva para contingencias. De manera similar, debe darse prioridad a las oportunidades que se encuentran en la zona de riesgo alto (gris oscuro), ya que pueden obtenerse más fácilmente y proporcionan mayores beneficios. Las oportunidades en la zona de riesgo bajo (gris medio) deben monitorearse. Los valores proporcionados son representativos. El número de etapas en la escala será determinado por la organización y depende de ella. 3.4.37 Evaluación Riesgos

de la

Calidad

los

Datos

sobre

Para ser creíble, un análisis cualitativo de riesgos requiere datos exactos y sin prejuicios. El análisis de la calidad de los datos sobre riesgos es una técnica para evaluar el grado de utilidad de los datos sobre riesgos para su gestión. Implica examinar el grado de entendimiento del riesgo y la exactitud, calidad, fiabilidad e integridad de los datos relacionados con el riesgo. Si la calidad de los datos es inaceptable, puede ser necesario recopilar datos de mayor calidad. 3.4.38 Categorización de Riesgos Los riesgos del proyecto pueden categorizarse por fuentes de riesgo (p.e., utilizando la RBS), por área del proyecto afectada (p.e., utilizando la EDT) u otra categoría útil (p.e., fase del proyecto) para determinar qué áreas del proyecto están más expuestas a los efectos de la incertidumbre. La agrupación de los riesgos en función de sus causas comunes puede llevar al desarrollo de respuestas efectivas a los riesgos. 3.4.39 Evaluación de la Urgencia de los Riesgos Los riesgos que requieren respuestas a corto plazo pueden ser considerados de atención más urgente. Los indicadores de prioridad pueden incluir el tiempo para dar una respuesta a los riesgos, los síntomas y las señales de advertencia, y la calificación del riesgo.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 58 de 141

En algunos análisis cualitativos, la evaluación de la urgencia de un riesgo puede estar asociada con la calificación del riesgo, la cual se determina a partir de la matriz de probabilidad e impacto para obtener una calificación final de la severidad del riesgo. 3.4.40 Técnicas de Recopilación de Información Algunos ejemplos de técnicas de recopilación de información utilizadas en la identificación de riesgos son: •

Tormenta de ideas. La meta de la tormenta de ideas es obtener una lista completa de los riesgos del proyecto. Por lo general, el equipo del proyecto efectúa tormentas de ideas, a menudo con un grupo multidisciplinario de expertos que no forman parte del equipo. Bajo el liderazgo de un facilitador, se generan ideas acerca de los riesgos del proyecto, ya sea por medio de una sesión tradicional y abierta de tormenta de ideas, con ideas que aportan los participantes, o en una sesión estructurada donde se utilizan técnicas de entrevista masiva, tales como las técnicas de grupo nominal. Como marco de referencia, pueden utilizarse categorías de riesgo, tales como una Estructura de Desglose de Riesgos. Luego, los riesgos son identificados y categorizados según su tipo, y sus definiciones son refinadas.

•

Técnica Delphi. La técnica Delphi es una manera de lograr un consenso de expertos. Los expertos en riesgos del proyecto participan en esta técnica de forma anónima. Un facilitador utiliza un cuestionario para solicitar ideas acerca de los riesgos importantes del proyecto. Las respuestas son resumidas y luego enviadas nuevamente a los expertos para que realicen comentarios adicionales. En pocas rondas, mediante este proceso se puede lograr el consenso. La técnica Delphi ayuda a reducir la distorsión en los datos y evita que cualquier persona ejerza influencias inapropiadas en el resultado.

•

Entrevistas. La realización de entrevistas a los participantes experimentados del proyecto, a los interesados y a los expertos en la materia puede ayudar a identificar los riesgos.

•

Análisis causal. El análisis causal es una técnica específica para identificar un problema, determinar las causas subyacentes que lo ocasionan y desarrollar acciones preventivas.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 59 de 141

3.4.41 Análisis de las Listas de Control Las listas de control para identificación de riesgos pueden desarrollarse basándose en la información histórica y el conocimiento acumulado a partir de proyectos similares anteriores y otras fuentes de información. También puede utilizarse como lista de control de riesgos el nivel más bajo de la estructura de desglose de riesgos. Si bien una lista de control puede ser rápida y sencilla, es imposible elaborar una lista exhaustiva. El equipo debe asegurarse de explorar elementos que no aparecen en la lista de control. La lista de control debe revisarse durante el cierre del proyecto para incorporar nuevas lecciones aprendidas y mejorarla para su utilización en proyectos futuros. 3.4.42 Análisis de Supuestos Cada proyecto y cada riesgo identificado se conciben y desarrollan tomando como base un grupo de hipótesis, escenarios y supuestos. Este análisis explora la validez de los supuestos según se aplican al proyecto. Identifica los riesgos del proyecto debidos al carácter inexacto, inestable, incoherente o incompleto de los supuestos. 3.4.43 Técnicas de Diagramación Las técnicas de diagramación de riesgos pueden incluir: •

•

Diagramas de causa y efecto. Estos diagramas también se conocen como diagramas de Ishikawa o diagramas de espina de pescado y son útiles para identificar las causas de los riesgos. Diagramas de flujo o de sistemas. Estos diagramas muestran cómo se interrelacionan los diferentes elementos de un sistema, y el mecanismo de causalidad. Diagramas de influencias. Estos diagramas son representaciones gráficas de situaciones que muestran las influencias causales, la cronología de eventos y otras relaciones entre las variables y los resultados. 3.4.44 Análisis SWOT (o DAFO, Debilidades, Amenazas, Fortalezas y Oportunidades)

Esta técnica examina el proyecto desde cada uno de los aspectos DAFO (debilidades, amenazas, fortalezas y oportunidades) para aumentar el espectro de riesgos identificados, incluyendo los riesgos generados internamente. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 60 de 141

La técnica comienza mediante la identificación de las fortalezas y debilidades de la organización, enfocándose ya sea en la organización del proyecto o bien en aspectos comerciales en un sentido más amplio. A menudo, estos factores se identifican utilizando la tormenta de ideas. El análisis DAFO identifica entonces cualquier oportunidad y amenaza para el proyecto, procedentes respectivamente de las fortalezas y debilidades de la organización. El análisis DAFO también examina el grado en el que las fortalezas de la organización contrarrestan las amenazas, y las oportunidades que pueden servir para superar las debilidades.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 61 de 141

Capítulo 4 ORGANIZANDO EL HORIZONTE

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 62 de 141

4.1 Armonizando el trabajo | Implicancias tangibles Los proyectos en entornos de alta incertidumbre tienen la particularidad de que no se pueden definir todos los requisitos del proyecto desde el inicio con la suficiente precisión como para poder cerrar alcance, recursos y tiempo. Por tanto se ha de optar por otras estrategias que permitan iniciar el proyecto con información suficiente como para dimensionarlo y caracterizarlo. Los proyectos, tradicionalmente, se caracterizan mediante la definición de tres variables fundamentales: alcance, costo y tiempo.  



Alcance: conjunto de requisitos y entregables que se han de satisfacer para dar por terminado un proyecto. Tiempo: duración total del proyecto, tiempo requerido para cumplir con el alcance teniendo en cuenta los recursos establecidos y la naturaleza de los trabajos que hay que llevar a cabo. Costo: recursos necesarios para cumplir con el alcance en el tiempo determinado.

Esta tripla suele estar representada a través de la figura conocida por unos como el “triángulo de hierro o férreo” y por otros por el “triángulo de oro o áureo”, cuya representación gráfica mostramos a continuación:

Figura 4.1: Triángulo de Hierro

En el centro del triángulo, como se aprecia, aparece encubierta una variable vital para considerar el éxito o el fracaso de un proyecto, y es la calidad. En la medida en que las variables cambien su magnitud y el triángulo se desvirtúe, la calidad se verá afectada. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 63 de 141

Hay diferencias notables entre el planteamiento tradicional y el enfoque ágil respecto a la definición de estas variables. Tradicionalmente todo el esfuerzo de planificación se hace al inicio del proyecto, con el objetivo de obtener la mejor definición posible del alcance, de modo que se pueda hacer un desglose de actividades realista para poder afinar al máximo en las estimaciones de costo y tiempo. Bien, en contextos de alta incertidumbre, donde aspiramos a resolver problemas complejos, no es posible hacer una buena definición de alcance inicial que permita proceder de este modo por dos razones fundamentales:  

Al inicio no se dispone de la información necesaria para definir al detalle el alcance. Los cambios van a estar presentes durante todo el ciclo de vida del proyecto.

Estamos hablando de proyectos en los que es más rentable comenzar a trabajar y generar así la información necesaria para ir descubriendo el alcance (enfoque empírico) que invertir ingentes cantidades de recursos y tiempo para intentar resolver por completo el problema a priori (enfoque predictivo). Si en este escenario el trabajo no está dirigido por el alcance, ¿cómo caracterizamos el proyecto? Las diferencias de enfoque entre el paradigma tradicional y el ágil se muestran muy claras con el siguiente diagrama:

Figura 4.2: Enfoque tradicional vs Enfoque Ágil

Mientras que en el enfoque tradicional el esfuerzo inicial se centra en fijar el alcance y a partir de ahí estimar el costo y el tiempo, en el enfoque ágil, se trata al inicio de establecer un marco sobre costo y tiempo, y a partir de ahí orientar los trabajos que se van a realizar en este marco siguiendo la Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 64 de 141

perspectiva del valor desde la óptica del cliente. A medida que el proyecto avanza, se irá incrementando el valor del resultado generado de forma incremental, buscando la implicación y la satisfacción del cliente desde los albores del proyecto y proyectando una ejecución siempre guiada por el objetivo de maximizar el ROI. 4.1.1 Planificación ágil Nos enfrentamos a un proyecto complejo en un contexto donde la incertidumbre es alta, donde hay multitud de variables en juego cuyos comportamiento son impredecibles. Planteemos los dos extremos: a) No planificar nada b) Invertir el esfuerzo necesario para lograr un “plan correcto”. La primera opción deja el proyecto en un estado de deriva, en el que nunca se tiene información suficiente como para tomar decisiones fundadas o plantear algún tipo de previsión tal como “¿podemos tener listo el producto para Abril?”. El trabajo del equipo estaría totalmente desenfocado y difícilmente se satisfaría al cliente. Dejar de gobernar el barco no es un opción válida para un profesional en dirección de proyectos. La segunda opción implica invertir cantidades ingentes de tiempo y esfuerzo que muy probablemente no se vean reflejados en un aumento de la precisión en el plan. Sobre todo teniendo en cuenta que el número de variables en un entorno de alta incertidumbre y el número de cambios que pueden sufrir suponen un número de escenarios posibles cuyo coste de estudio y control es inviable. Eso unido a que en un contexto de alta incertidumbre, no existen los planes correctos. 4.1.2 Planificación vs Plan Uno de cuatro puntos del manifiesto ágil dice: “Valoramos más responder a los cambios que seguir un plan” ¿Quiere decir esto que planificar no sirve para nada? Vamos a citar a un gran estratega: “Los planes son inútiles, pero la planificación es indispensable”. Dwight D. Eisenhower El plan no es más que el resultado de la planificación. Pero tenemos que ser conscientes que en un contexto de alta incertidumbre no sólo puede haber Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 65 de 141

cambios, sino que es completamente necesario que los haya, como respuesta al nuevo conocimiento que se va generando. Por otro lado, la labor de planificación es absolutamente indispensable, porque aunque el plan varíe, se adquiere muchísimo conocimiento planificando, y este conocimiento es tremendamente valioso para identificar riesgos, para responder a los cambios o para enfrentarnos a imprevistos. El hecho de que los cambios no sólo estén permitidos, sino que se fomenten, es lo que hace idóneo este tipo de enfoque en esta clase de proyectos. Por tanto, dotemos al plan la importancia que merece. Es un instrumento que nos servirá para guiarnos y para facilitarnos la comprensión del proyecto y la toma de decisiones. Y no es un documento cerrado. De hecho, los planes generados a partir de una planificación ágil deben ser herramientas que se puedan cambiar fácilmente, puesto que los cambios van a estar presentes durante toda la vida del proyecto. Por ello, la planificación es una actividad que no sólo se hace al inicio, sino que se extiende a lo largo de la vida del proyecto. En definitiva, la planificación ágil se caracteriza por:    

Fomenta el cambio Está focalizada más en la actividad de planificación que en el plan No es una actividad que se haga sólo al inicio, sino que se extiende a lo largo de todo el proyecto. Se traduce en planes que se pueden cambiar fácilmente. 4.1.3 Objetivos de la planificación ágil

Bajo el enfoque ágil, la planificación no está dirigida por las tareas que hay que llevar a cabo, sino por el valor que se le entrega al cliente. Planificar significa encontrar la mejor solución a la pregunta ¿QUÉ queremos hacer? Para responderla el equipo considerará funcionalidades, recursos y tiempo, pero no podemos resolver esta cuestión completamente al principio del proyecto. El enfoque ágil plantea ir construyendo la solución de modo iterativo e incremental, buscando los siguientes objetivos:   

Reducir los riesgos Reducir la incertidumbre Apoyar una mejor toma de decisiones

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 66 de 141

 

Generar confianza Compartir información y aprender de ella

4.1.3.1

Reducir riesgos

Planificar permite darnos cuenta de muchos de los riesgos asociados al proyecto, lo que facilita tomar decisiones importantes desde fases tempranas, como, por ejemplo, no seguir con el proyecto. Planificar saca a la luz los posibles puntos negros del proyecto. 4.1.3.2

Reducir incertidumbre

A medida que el proyecto avanza, se genera nuevo conocimiento que permite planificar y estimar mejor. Este nuevo conocimiento es utilizado en cada iteración para mejorar el proceso de planificación y estimar cada vez con mayor precisión. El riesgo más importante en la mayoría de los proyectos es desarrollar un producto incorrecto. A través de la planificación ágil este riesgo se reduce drásticamente hasta prácticamente eliminarlo. 4.1.3.3

Apoyar una mejor toma de decisiones

Planificar y estimar implica poner sobre la mesa conocimiento para poder tomar mejores decisiones. Como por ejemplo, decidir si comenzar o no un proyecto, decidir entre dos proyectos, conocer QUÉ vamos a desarrollar y CÓMO. 4.1.3.4

Generar confianza

Hacer cada vez estimaciones más realistas, esto genera confianza entre el cliente y quienes desarrollan el producto. Y esta confianza hace que las estimaciones sean cada vez más útiles para tomar mejores decisiones respecto al proyecto. 4.1.3.5

Compartir información y aprender de ella

Permite al responsable del QUÉ y a los responsables del CÓMO compartir información, negociar y aprender mutuamente. Permite establecer y gestionar de forma efectiva las expectativas de ambas partes.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 67 de 141

4.1.4 Principios Armónicos En el presente Tratado se plantea un marco de trabajo basado en la filosofía ágil e inspirado en Scrum. Lo realmente importante para aplicar cualquier marco de trabajo con éxito es comprender los principios que lo hacen realmente efectivo. A continuación presentamos una nube de tags en la que aparecen algunos de los principios más importantes que se ven referenciados a lo largo de este Tratado de forma directa o indirecta y que forman la base cultural necesaria para conseguir el alto rendimiento en entornos de alta incertidumbre.

Figura 4.3: Principios Armónicos

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 68 de 141

4.1.5 Los Roles (Director del Proyecto, Expectativas y Gestor de la Ejecución)

Gestor

La labor del Director del Proyecto ha sido tradicionalmente ingente para dirigir y gestionar todos los aspectos del proyecto. Ha sido la luz y la interfaz para todo y para todos. Pero ocuparse de todas las responsabilidades hace que se desfocalice al no disponer por desgracia del don de la ubicuidad. Este exceso de carga en las responsabilidades del Director del Proyecto hace que en muchas ocasiones no pueda hacer lo que tiene que hacer y está en la raíz del fracaso de muchos proyectos. En otro orden de las cosas, hemos visto cómo para resolver problemas complejos, la solución más efectiva la conforman los Sistemas Adaptativos Complejos, cuyas características principales son: comunicación, confianza y relaciones horizontales, y su capacidad más notable es la auto organización. El Director del Proyecto en un entorno de alta incertidumbre tiene que aprender a provocar esta auto organización. Tiene que fomentar que todos y cada uno de los miembros del equipo de proyecto tengan responsabilidades respecto de la gestión. Tiene que crear, mantener y fomentar un ambiente en el que la interacción entre los miembros y entre los interesados sea efectiva. Por ello no recaerá en él todas las responsabilidades de decisión. El director del proyecto se encargará de que el proceso funcione de la mejor forma posible. Esto implica que debe actuar como facilitador, asegurando que se llevan a cabo correctamente los procesos implicados en la gestión del proyecto, favorecer el flujo de comunicación entre los miembros del Equipo, facilitar la resolución de impedimentos y conflictos y procurar aumentar las capacidades y habilidades del Equipo. Es decir; se aleja de la figura del líder jerárquico para erigirse como un líder servicial, que está al frente del proyecto y al servicio del resto del equipo. El Director del Proyecto es de facto el director de orquesta del equipo. Para potenciar que el equipo funcione en condiciones de alto rendimiento, sus llamadas “habilidades blandas” para la gestión de personas tienen una relevancia suprema. El Director del Proyecto tiene que actuar aquí no como un líder jerárquico, sino como un líder servicial, que está al frente del proyecto y al servicio del resto del equipo. Generar y mantener la confianza es esencial en estos equipos de proyecto, puesto que el equipo trabaja como una unidad. 4.1.5.1

Qué no hará un Director del Proyecto

Las principales responsabilidades que no recaerán sobre el Director del Proyecto son las siguientes: Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 69 de 141

• • • •

Gestionar las comunicaciones con los interesados y gestionar sus expectativas Decidir sobre QUÉ se quiere crear mediante el proyecto Decidir sobre CÓMO se va a ejecutar el proyecto. Ejecutar el proyecto.

Para llevar a cabo estas responsabilidades, aparecen dos roles fundamentales que contribuirán a conseguir el alto rendimiento del equipo: • •

Gestor de Expectativas. Gestores de Ejecución.

4.1.5.2

El Gestor de Expectativas

Es la persona responsable de gestionar las expectativas del cliente y el resto de implicados externos. En el ámbito del proyecto, el Gestor de Expectativas es la voz del cliente y es el único que puede decidir respecto a QUÉ características del producto se van a crear. Será el encargado de priorizar el trabajo. Él es el principal canal de comunicación entre los Gestores de Ejecución y los interesados. De este modo, la complejidad de las comunicaciones disminuye drásticamente. 4.1.5.3

Los Gestores de Ejecución

Son los miembros del equipo destinado a ejecutar el proyecto. Son los únicos que pueden decidir sobre el plano del CÓMO, puestos que son ellos los que tienen la responsabilidad de ejecutarlo. Por ello son gestores, porque tienen la responsabilidad de gestionar el trabajo que deben llevar a cabo. Se recomienda que el número de Gestores de Ejecución esté entre 5 y 9. Con menos de 5 se pierde capacidad y efectividad potencial y a partir de 9 comienza a crecer dramáticamente el esfuerzo de coordinación. Esto no quiere decir que no se puedan rebasar estos límites, simplemente que entre estos dos valores suelen darse los mejores resultados. 4.1.5.4

El Equipo del Proyecto

Por tanto, un equipo de proyecto contará con: • • •

Director del Proyecto Gestor de Expectativas Gestores de Ejecución

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 70 de 141

Figura 4.4: Equipo de Proyecto

4.1.6 Reuniones, ¿cuáles son y por qué tan pocas? Uno de los principios armónicos más importante es la comunicación. Las reuniones son vehículos para el intercambio de información y la generación de conocimiento. Cuando hablamos de vehículos queremos hacer referencia a que son un medio, no un fin por sí mismas. El coste de las comunicaciones en la mayoría de proyectos tradicionales, unido al coste del retrabajo provocado por una mala comunicación supone en la mayoría de los casos graves problemas y en muchos de ellos, el fracaso absoluto del proyecto. Es una fuente inagotable de desviaciones. Por tanto, hay que prestar un especial cuidado a este factor. Este marco de trabajo tiene las siguientes reuniones claves: • • • • • •

Reunión Reunión Reunión Reunión Reunión Reunión

de recopilación de requisitos de planificación inicial de planificación de fase diaria de sincronización de revisión del entregable de retrospectiva

Estos son los principales puntos de intercambio de información. Sus duraciones y objetivos están definidos y todos los participantes conoces sus responsabilidades en cada una de ellas. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 71 de 141

Son 6 tipos de reuniones. Pueden parecer pocas. Aquí la clave no está en el número de tipos de reuniones que se llevan a cabo, sino que se hacen de forma sistemática. Porque en este tipo de entornos, donde la incertidumbre es alta, en el ámbito del proyecto no sólo se crea valor mediante la ejecución del proyecto, sino que también se crea conocimiento, sobre el QUÉ y sobre el CÓMO, y este conocimiento es un activo importante que revierte de nuevo en el valor generado. Lo que queremos provocar es que exista un intercambio sistemático de conocimiento de modo que la incertidumbre en ambas dimensiones disminuya. Y además queremos que esta transmisión de conocimiento esté plenamente focalizada, reduciendo el riesgo de infoxicación (intoxicación por exceso de información) por ambas partes (equipo e interesados). 4.1.7 Artefactos y herramientas | Mecánicas a aplicar Si queremos dirigir y gestionar proyectos de forma ágil, las herramientas que utilicemos deben ser herramientas ágiles, fáciles de usar, mantener y gestionar. Llamaremos artefactos a aquellos elementos conceptuales esenciales que son necesarios para gestionar el proyecto. Llamaremos herramientas a los elementos de gestión visual que nos facilitan la comprensión de la información durante el proyecto. Con este espíritu, vamos a centrarnos en este tratado en los artefactos y herramientas necesarias para llevar a cabo esta labor. Esto no quiere decir que se tengan que utilizar únicamente estas, simplemente que se han demostrado útiles por sí mismas para llevar a buen puerto este tipo de proyectos. Los artefactos básicos son: 1. Pila del Producto 2. Pila de la Fase Las herramientas básicas son 1. Panel de Tareas 2. Diagrama de quemado o burndown del proyecto. 3. Diagrama de quemado o burndown de la fase. Vamos a detenernos en este punto a describir someramente los artefactos y las dinámicas en las que están implicados. Las herramientas serán descritas más adelante, en el momento en que hagamos uso de ellas.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 72 de 141

4.1.7.1

Pila del Producto

La Pila del Producto es una lista priorizada de elementos, cada uno de los cuales representa una característica del producto que una vez implementada proporciona valor al cliente. El Gestor de Expectativas es el responsable de su contenido, priorización y disponibilidad. La Pila del Producto es dinámica. El Gestor de Expectativas ha de gestionarla y realizar los cambios necesarios para que en todo momento represente qué necesita el producto para ser apropiado, competitivo y útil. Es importante comprender que la Pila del Producto nunca está completa. Comienza siendo una estimación inicial de requerimientos y a lo largo del desarrollo incremental por fases, va evolucionado a medida que evoluciona el producto, el entorno, y el conocimiento generado sobre ambos. Por tanto no tiene porqué ser desechada al finalizar el proyecto. Puede que el alcance del proyecto contemple la creación del producto y no su mejora posterior. Por lo que tras su construcción inicial, el ciclo de vida del proyecto llega a su fin, pero no el ciclo de vida del producto. La Pila del Producto tiene sentido siempre que exista el producto, y trasciende la vida del proyecto. Por lo tanto, tras el cierre del proyecto, la Pila del Producto puede seguir siendo un instrumento útil. Esta es una de las razones por la que se la prefiere llamar pila del producto y no del proyecto. 4.1.7.1.1

Estructura de la Pila del Producto

Los elementos de esta pila pueden tener diferentes formatos. No es obligatorio optar por ninguno de ellos, lo que sí es conveniente es que sea cual sea el formato elegido para representarlos, permita:  

Actualizar la pila rápidamente Facilitar su comprensión por parte del Gestor de Expectativas y de los Gestores de Ejecución

Cada elemento de la pila del producto debe contener, al menos:    

Descripción de la característica que representa Representación del valor de negocio que tiene para el cliente Estimación del coste necesario para desarrollarla Representación del riesgo asociado al elemento

Un formato muy utilizado en equipos ágiles es el de historias de usuario. En la sección Recopilando Requisitos del presente tratado, explicamos con detalle esta técnica.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 73 de 141

4.1.8 Pila de la Fase En la planificación de cada fase, los Gestores de Ejecución deben determinar, en función de su capacidad, la lista de elementos de la Pila del Producto que van a convertir durante la fase en un incremento de valor entregable, siguiendo la prioridad marcada por el Gestor de Expectativas. La Pila de la Fase es una lista de actividades o tareas que los Gestores de Ejecución han de llevar a cabo para convertir el segmento de la Pila de Producto que seleccionó para esa fase en un incremento de valor entregable. Es por tanto, un instrumento que guía el trabajo del equipo y que facilita su focalización.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 74 de 141

4.2 Formalizando el inicio El inicio del proyecto usualmente se formaliza a través de un documento que firman todas las partes implicadas y que refleja los objetivos y condicionantes del proyecto que se quiere iniciar. Es muy buena práctica reflejar en un documento la visión del proyecto, y en el que se establece una aproximación respecto al alcance, presupuesto y calendario. Esto no significa cerrar el triángulo, simplemente poner por escrito las intenciones de la parte cliente y la parte ejecutora de trabajar juntos para llevar a cabo el proyecto. Si ya se ha decidido quiénes asumirán los diferentes roles, es interesante reflejarlo en el documento así como los poderes, responsabilidades y obligaciones de cada uno de ellos. También es interesante conocer diferentes opciones de contratación para proyectos ágiles. En el Capítulo 7: Conocimiento Adicional ampliamos información sobre este tipo de contratos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 75 de 141

4.3 Identificando a los interesados Lo primero que hay que decir sobre los interesados es que pueden ser personas y organizaciones (como son los clientes, etc), todos aquellos que estén involucrados de forma activa o cuyos intereses se vean afectados positiva o negativamente por el proyecto. Ellos tienen un grado de influencia sobre el proyecto y sobre los entregables. Una labor importante del Gestor de Expectativas es identificar a los interesados tanto internos como externos, para determinar los requisitos del proyecto y las expectativas de todas las partes involucradas. Además, deberá gestionar la influencia de los diversos interesados con relación a los requisitos del proyecto, para asegurar el éxito del proyecto. Es importante tener en cuenta que los interesados tienen diferentes niveles de responsabilidad y autoridad cuando participan en un proyecto y éstos pueden cambiar durante el ciclo de vida del mismo. Su responsabilidad y autoridad pueden variar desde una participación ocasional hasta el apoyo financiero y político. Del mismo modo no hay que perder de vista que los interesados pueden tener un impacto negativo en los objetivos del proyecto. En cualquier caso, El Gestor de Expectativas debe identificar a los interesados de forma continua. Para cada uno de los interesados, el proyecto puede tener resultados tanto positivos como negativos. Es obvio por tanto que para aquellos con expectativas positivas, sus intereses serán mejor atendidos si contribuyen al éxito del proyecto. Por contra, los de los interesados negativos se verán mejor atendidos si impiden el avance del proyecto. Es un verdadero error no tener en cuenta a los interesados negativos. Esto aumenta la probabilidad de fracaso del proyecto. A menudo los objetivos de los interesados son muy diferentes o contradictorios. El Gestor de Expectativas debe balancear estos intereses y asegurarse de que ser el canal por el que el equipo del proyecto interactúe con los interesados de una manera profesional y cooperativa. Por tanto, para el éxito del proyecto, resulta fundamental identificar a los interesados desde sus inicios y analizar sus niveles de interés, expectativas, importancia e influencia. El Gestor de Expectativas deberá elaborar una estrategia para abordar a cada uno de ellos y determinar el nivel y el momento de su participación, a fin de maximizar las influencias positivas y reducir los impactos negativos potenciales. Como proceso sujeto a la inspección y adaptación, la evaluación y la estrategia deben revisarse de Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 76 de 141

forma periódica durante la ejecución del proyecto para responder a los continuos cambios. Generalmente, el análisis de los interesados sigue los siguientes pasos: 1. Identificación de los principales interesados en el proyecto e información relevante, como por ejemplo sus roles, departamentos, intereses, niveles de conocimiento, expectativas y niveles de influencia. Por lo general, resulta fácil identificar a los interesados clave. Aquí debe imperar el sentido común. No tiene mucho sentido que se pierdan ingentes cantidades de tiempo y energías identificando a absolutamente todos aquellos que pueden verse mínimamente afectados por el proyecto. El Gestor de Expectativas debe hacer un esfuerzo de abstracción para identificar aquellos verdaderamente claves y en cuya vigilancia y mantenimiento de la relación merece la pena invertir tiempo y esfuerzo. 2. Identificación del impacto o apoyo potencial que cada interesado podría generar, y su clasificación para definir la estrategia de abordaje. Como comentamos anteriormente hay que priorizar a los interesados clave a fin de garantizar el uso eficaz del esfuerzo para comunicar y gestionar sus expectativas. Una parte fundamental del trabajo que hay que realizar respecto a los interesados, a lo largo del proyecto es gestionar las comunicaciones. El Gestor de Expectativas debe determinar las necesidades de información de los interesados en el proyecto para establecer un enfoque eficaz y eficiente; es decir, suministrar únicamente la información necesaria, en el formato adecuado, en el momento justo y con el impacto apropiado.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 77 de 141

4.4 Recopilando Requisitos Nos encontramos en un contexto de alta incertidumbre, donde los requisitos ni están definidos ni siquiera se pueden definir completamente al inicio, porque el cliente y el resto de interesados necesitarán del nuevo conocimiento que genere el proyecto para irlos descubriendo de forma iterativa e incremental. El proyecto en sus inicios parte de una visión. La visión es una idea, y el mundo de las ideas se mueve, teniendo en cuenta el diagrama de complejidad, en el área del caos. La misión del Gestor de Expectativas es lograr reducir la incertidumbre en el eje del QUÉ de modo que el problema se sitúe lo más cercano posible al área de lo complejo. Es responsabilidad del Gestor de Expectativas gestionar las expectativas de los interesados y procurar la máxima satisfacción del cliente. Para ello deberá celebrar y pilotar reuniones con ellos para que emerjan sus verdaderas necesidades y para priorizarlas. 4.4.1 Reunión de Recopilación de Requisitos | Construcción de la Pila del Producto Inicial 4.4.1.1 



Recopilar los requisitos del cliente y el resto de interesados en términos de características que representen unidades que tiene valor para ellos y representarlos en una pila priorizada. Determinar las condiciones de satisfacción que supondrán el éxito de la entrega de cada una de estas unidades de valor.

4.4.1.2 

 

Objetivos

Participantes

Gestor de Expectativas: deberá llevar el peso de la reunión aplicando su capacidad de comunicación, negociación, empatía, análisis y síntesis para poder traducir las necesidades del cliente y el resto de interesados a una pila priorizada de características que representan valor. Clientes: refiriéndonos a quiénes financian el proyecto y tienen el mayor poder de decisión sobre el mismo. Otros interesados: a quienes afecte el proyecto y/o puedan aportar conocimiento sobre el valor del producto.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 78 de 141

4.4.1.3 



Prerrequisitos

Es conveniente disponer de un espacio tranquilo, alejado de interrupciones, donde los participantes puedan interactuar de forma cómoda. Es esencial utilizar herramientas visuales que ayuden a comunicar y, sobre todo, que ayuden a pensar de manera colaborativa. Una pizarra o un flipchart no debería faltar. Para representar los diferentes elementos de la pila, es aconsejable usar algún medio tangible y fácil de manipular, como por ejemplo, fichas rayadas.

4.4.1.4

Organización

Un buen punto de inicio para esta reunión es asegurar que todos los participantes comparten una misma visión del proyecto. Para ello es conveniente escuchar todas las voces y llegar a un consenso que satisfaga a todos. Es importante establecer este marco común para que todos los que van a trabajar para definir el valor del producto remen en la misma dirección y se eviten discusiones innecesarias por tener un norte final diferente o ambiguo. Esta visión compartida debe estar siempre presente. No tiene por qué ser inamovible, podrá variar en función del conocimiento que se vaya generando en la reunión, pero siempre deberá ser comprendida y apoyada por los participantes. Teniendo en cuenta la visión del proyecto, el Gestor de Expectativas debe averiguar los objetivos de negocio que se pretenden conseguir, haciendo las preguntas necesarias para llegar a las verdaderas necesidades. Es vitar trascender de lo que los interesados quieren a priori y descubrir con ellos qué es lo que realmente necesitan. La búsqueda de la causa raíz de sus requerimientos permite despejar incertidumbre sobre el QUÉ y afinar mucho más el concepto de valor. El Gestor de Expectativas tiene que procurar siempre maximizar el ROI del cliente en el proyecto. Identificar correctamente el valor de los requerimientos es indispensable para lograrlo. Durante la reunión, el Gestor de Expectativas debe ir guiando a los participantes a concretar sus requerimientos en una lista priorizada por el valor que les aporta. El nivel de detalle en este punto no es preciso, son requisitos de alto nivel, pero el nivel de conocimiento generado debe ser el suficiente como para caracterizar el proyecto.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 79 de 141

4.4.1.5

Técnicas

4.4.1.5.1

Historias de Usuario

4.4.1.5.1.1 Introducción Las historias de usuario son elementos de definición de requisitos de carácter informal y ligero, muy utilizada por los equipos ágiles, que lleva asociada poca carga de documentación en virtud de un gran trabajo de comunicación. El concepto de usuario hace referencia a quien utilizará el producto, servicio o resultado del proyecto. Y el concepto de historia se refiere a qué los requisitos se toman en base a una necesidad, deseo u oportunidad que tiene un contexto y un razonamiento, o lo que es lo mismo, que tiene su historia. Generalmente las historias de usuarios se escriben en fichas, tarjetas o notas adhesivas. La ficha donde se escribe cada historia de usuario no es representativa por sí misma; sólo es un recordatorio de la comunicación establecida para definirla. Con esto queremos decir que la historia no es únicamente el soporte físico, sino todo el proceso comunicativo que representa, que es lo que, al fin y al cabo, le dota de su alta eficacia como método de definición de requisitos. Las historias de usuario evolucionan a medida que el proyecto avanza, y potencian la colaboración. Según Mike Cohn (2004) Una historia de usuario está compuesta, al menos, por: 

 

Una descripción escrita de la historia usada: o Para planificar o Como recordatorio Conversaciones sobre la historia que sirven para profundizar en los detalles de la historia. Tests que transmiten y documentan los detalles de la historia y que pueden ser usados para determinar cuándo una historia está completa.

Según Jeffries (2001), debido a que normalmente las historias se escriben a mano sobre una tarjeta, llama a estos tres aspectos: 

Tarjeta: es el soporte físico donde se escribe cada historia.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 80 de 141



Conversación: es el proceso de comunicación necesario para definir cada historia y del que la tarjeta no es más que un mero recordatorio. Confirmación: condiciones cuya satisfacción hace que la historia se considere como terminada.

Son las tres claves de esta técnica, donde la tarjeta es la parte más tangible, pero no la más importante. 4.4.1.5.1.2

¿Cómo se escribe una historia de usuario?

La técnica no tiene asociada un formato específico, pero muchos autores, entre los que nos incluimos, prefieren utilizar, siempre que se pueda, un patrón como el siguiente: Como [ROL] quiero [REQUISITO] para [BENEFICIO]. El objeto de esta plantilla es “forzar” que se responda explícitamente a tres preguntas claves:  ¿QUÉ es lo que se quiere?  EXPECTATIVAS  ¿Cuál es el beneficio que se consigue?  VALOR  ¿A QUIÉN/ES beneficia?  INTERESADO/S Ahora bien, como siempre, debe imperar el sentido común. No es necesario que todas las historias se escriban con este patrón, sólo queremos poner de manifiesto que el uso del mismo aporta valor en la mayoría de los casos. Vamos a profundizar en estos aspectos: 4.4.1.5.1.3 Rol En no pocos proyectos se crean características del producto final que resultan no beneficiar a nadie y al final no son utilizadas o quedan relegadas al ostracismo. Con la declaración explícita de A QUIÉN beneficia la historia se pretende evitar este tipo de situaciones. 4.4.1.5.1.4 Requisito Esto es el QUÉ, lo que el beneficiario de la historia desea que se desarrolle. En la tarjeta aparecerá una descripción mínima que permita recordar la conversación mantenida. En muchos proyectos, se crean características de más, porque se entiende que el producto así está “más completo” o es “mejor”, olvidando que ese tipo de valoraciones ha de hacerlas quienes reciben el valor, no quienes lo crean.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 81 de 141

4.4.1.5.1.5 Beneficio Hemos dicho que en este contexto, la ejecución estará dirigida por valor. El beneficio es la razón, la causa, la necesidad, la oportunidad que da sentido a la ejecución de la historia. Es la justificación de la misma. Esto obliga a que cuando se están definiendo las historias de usuario explícitamente han de clarificarse las razones por la que se quiere desarrollar tal o cual característica, obligando a especificarlas y a debatirlas. Este debate puede derivar en muchas ocasiones, gracias al conocimiento que el propio debate genera, a rechazar historias o a incluir otras nuevas. 4.4.1.5.1.6 Formato de tarjeta Generalmente el soporte más utilizado para crear y manejar las historias de usuario es el de tarjeta, usualmente, fichas rayadas, aunque el formato de la tarjeta no es relevante. Eso sí, debe facilitar su manipulación. Además de la descripción de la historia, en la ficha suele aparecer la siguiente información:  



Un título: que sirva para darle entidad a la historia y poder referenciarla de forma breve, sin entrar en detalles. Estimación de Coste: asignación del esfuerzo necesario para desarrollar la historia de usuario. Normalmente se utilizan “Puntos de Historia” (véase Estimando Recursos y Calculando Costes). Valor o Prioridad: un campo utilizado para establecer qué lugar de la Pila de Producto le corresponde a la historia en cuestión. Hay quienes prefieren estimar cuantitativamente el valor y que la cifra de prioridad sea el cociente entre Valor / Coste, lo que informalmente llamamos ROI. Otros prefieren directamente señalar una cifra de prioridad, teniendo en cuenta la estimación de coste, sin realizar operaciones matemáticas adicionales. Existe la posibilidad de utilizar escalas determinadas (como potencias de 2 o fibonacci) pero vale con asignar valores mayores a las historias más prioritarias, donde, por ejemplo, una historia de 60 es más prioritaria que otra de 50. Pruebas de aceptación: han de aparecer todas las condiciones que se han de cumplir para considerar que una historia está acabada. Esto servirá de recordatorio al Equipo para saber cuándo debe dejar de trabajar en ella y también al Líder del Producto, a la hora de comprobar que la historia está correcta.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 82 de 141

Figura 4.5: Ejemplo de Ficha de Historia de Usuario

4.4.1.5.1.7 Características que deben tener Una buena historia de usuario debe tener las siguientes seis características, como bien apunta Bill Wake (2003a):      

Independiente Negociable Evaluable Estimable Pequeña Testeable

El citado autor propuso el acrónimo INVEST atendiendo a las iniciales de estas palabras en inglés. 4.4.1.5.1.8 Independiente Hay que procurar que las historias tengan entre ellas las menores dependencias posibles para evitar problemas a la hora de planificar y priorizar.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 83 de 141

4.4.1.5.1.9 Negociable Esto quiere decir que la tarjeta no es un contrato inamovible, sino que representa una conversación previa y que requerirá de otras conversaciones a medida que avanza su ejecución para hablar sobre detalles y dudas que vayan surgiendo. 4.4.1.5.1.10

Evaluable

Una historia representa algo que tiene valor para los interesados, por tanto, una vez desarrollada debe ser evaluable por ellos. Hay que tener en cuenta que en la mayoría de proyectos hay trabajos que no son visibles para los interesados y que por tanto, no pueden evaluar, pero que son necesarios, a veces indispensables. Por ejemplo, el diseño de una base de datos, en un software. ¿Quiere decir que hay que evitar realizar estos trabajos? No. La idea es que estos formen parte de una historia que tenga como objetivo final algo que los interesados puedan evaluar. Vamos a explicarlo con un ejemplo: en el desarrollo de software, la base de datos normalmente es algo absolutamente opaco para los interesados. No pueden evaluar el diseño de la base de datos si no tienen conocimiento específico sobre bases de datos y buscan un diseño particular y específico. Pero normalmente los interesados no están al tanto, ni necesitan estarlo, de estos detalles. ¿Quiere decir esto que hay que renunciar a la base de datos? No. Significa que habrá que ir metiéndole mano en la medida en que lo vayamos necesitando porque sea indispensable para satisfacer un requisito que sí aporta valor para el cliente. Por ejemplo, el cliente quiere el software pueda dar de alta un usuario en el sistema. Esto implica que hay que crear la base de datos y que hay que realizar las consultas precisas para llevarlas a cabo. Pero lo que evalúa el cliente no es la base de datos en sí, sino que el programa sea capaz de crear un usuario. Esto representa un cambio de paradigma importante, que separa sustancialmente el QUÉ del CÓMO, y que ilustra la importancia de las figuras diferenciadas del Gestor de Expectativas y de los Gestores de Ejecución. Seguramente, desde el punto de vista del equipo, la base de datos está muy bien hecha, es eficiente y su cota de calidad técnica es superlativa. Pero nada de esto tiene ninguna importancia si no se reflejado en VALOR para el cliente y el resto de interesados. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 84 de 141

4.4.1.5.1.11

Estimable

La historia de usuario se ha de poder estimar. Hay tres razones por las que una historia puede no ser estimable por los Gestores de Ejecución: 



Falta conocimiento respecto al problema.  Habrá que reducir la incertidumbre hablando con el Gestor de Expectativas. Faltan conocimientos técnicos respecto a la solución.  Habrá que reservar unos recursos determinados para que alguno/s de los Gestores de Ejecución adquiera/n los conocimientos necesarios para estimarla. Es demasiado grande.  Habrá que dividirla en historias que sean más sencillas de estimar.

4.4.1.5.1.12

Pequeña

Una historia debe ser concreta, con un tamaño suficiente para ser estimada y usada para planificar y priorizar. Las historias grandes se denominan épicas o epopeyas. Pueden admitirse cuando están situadas debajo de la Pila del Producto. Pero cuando emergen y han de ser resueltas, hay que dividirlas en historias más manejables y estimarlas convenientemente. Por el contrario, si una historia es demasiado pequeña no merece la pena siquiera el esfuerzo de estimarla. Es mucho más útil fusionar varias historias de este tipo en una con entidad suficiente para ser procesada. 4.4.1.5.1.13

Testeable

Las historias han de poder probarse que están correctamente desarrolladas. Esto es fundamental por varias razones: por un lado, para que los Gestores de Ejecución sepan cuándo el desarrollo de una historia ha finalizado y por otro lado, para que el Gestor de Expectativas pueda probar que efectivamente se satisfacen los requisitos representados por la historia. 4.4.1.5.2

Temas e Historias Épicas

A la hora de construir y evolucionar la Pila del Producto, no todos los elementos de la pila tienen que estar definidos al detalle. Hay dos tipos de elementos que pueden existir en la Pila del Producto y que no cumplen con las características de Historia de Usuario: los temas y las historias épicas.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 85 de 141

4.4.1.5.2.1 Tema Se denomina tema al elemento de la pila sobre el cual no se ha reducido la incertidumbre lo suficiente como para estar detallado, por ser poco prioritario en ese punto de la ejecución. Por ejemplo: “Módulo de informes”. Es útil conocer que más adelante se ha de realizar un módulo de informes, pero no es útil invertir más esfuerzos en intentar desgranar este módulo porque en el momento actual no es prioritario y porque en función del conocimiento generado durante el proyecto, la definición de este elemento puede variar drásticamente. Por tanto, este elemento se desgranará en el “último momento responsable”; es decir, cuando se pueda obtener la máxima precisión con el mínimo coste. 4.4.1.5.2.2 Historia Épica Se denomina historia épica al elemento de la pila que aunque se ha concretado y discutido sobre ello, es demasiado grande como ser considerado una Historia de Usuario. Por ejemplo: “gestión de proveedores”. 4.4.1.6

Mapa de Historias de Usuario

Esta técnica es muy utilizada para facilitar la construcción de la Pila del Producto utilizando Historias de Usuario. En lugar de plantear de inicio una estructura lineal de pila, se crea, a medida que se va conversando y van emergiendo las diferentes historias de usuario, un mapa bidimensional que aporta una mayor información sobre las necesidades y requerimientos de los interesados, enriquece la discusión y ayuda a priorizar. La idea principal de la técnica es aprovechar todo el conocimiento generado a través de las reuniones de planificación plasmándolo en una estructura que permita situar a cada historia en su contexto de interrelación con las demás historias. Al usar pilas planas, esta información adicional se pierde, al menos, de forma explícita. El Mapa de Historias de Usuario es una técnica visual basada en una herramienta para pensar y facilita el no perderle la pista a cada historia dentro del contexto del proyecto. En el proceso de creación del Mapa de Historias de Usuario se establecen básicamente dos niveles conceptuales: 

Grupo de Actividades: que son historias épicas, de gran dimensión, que representan grandes cosas que hay que hacer. Normalmente

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 86 de 141



constan de varios pasos y no siempre se puede determinar su flujo. Por ejemplo: “gestionar clientes” podría ser una actividad. Tareas de Usuario: representan acciones concretas que deberán poder llevarse a cabo para cumplir un objetivo específico. Cumplen la definición de Historia de Usuario que comentamos anteriormente. Por ejemplo: “crear una ficha de cliente” podría ser una tarea de usuario.

4.4.1.6.1 Creación de una Pila de Producto utilizando un Mapa de Historias de Usuario Visualicemos el proyecto como una gran historia, que debe ser contada por los que en este contexto llamamos “usuarios”; aquellos que van a interactuar con el producto y van a proporcionar feedback. Lo primero que tenemos que hacer es pensar en alto nivel. ¿Qué actividades o grupo de características de alto nivel son necesarias para cumplir con los objetivos del proyecto? Una vez se tienen más o menos claras se comienza a construir el mapa. Consideremos dos ejes: el horizontal simboliza la secuencia en la que se necesitarán o se usarán las características del producto (se puede considerar también como una línea temporal) y la vertical hace referencia a la prioridad de las tareas de usuario. Una vez hecho esto se dispone el grupo de tareas sobre el eje horizontal, siguiendo la secuencia de uso / necesidad.

Figura 4.6: Comenzando a crear el Mapa de Historias de Usuario

Una vez están definidas, es hora de pensar en términos de funcionalidades o características concretas que son necesarias para determinar cada actividad. Lo ideal es colocar estas características bajo las actividades en

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 87 de 141

orden de importancia o criticidad. Si son tareas alternativas, se pone una bajo la otra dependiendo de su prioridad. Si son tareas consecutivas, se pone una a la derecha de la otra.

Figura 4.7: Mapa de Historias de Usuario

Construyendo el mapa de este modo, obtenemos una información visual del proyecto muy interesante. En primer lugar, permite la identificación de partes del producto que no se han considerado. Imaginemos que queremos diseñar un avión. Viendo el mapa podríamos ver fácilmente si falta algún componente principal, como las alas. Otra ventaja importante de utilizar esta disposición es que identifica explícitamente la parte mínima de puede tener valor de mercado. La primera fila se corresponde con lo absolutamente indispensable. Es lo que Alistair Cockburn llama walking skeleton o esqueleto andante; la parte mínima de funcionalidad que dota de valor real al producto. Todavía le faltan detalles (músculos, tendones, piel…) pero la parte fundamental la forma este conjunto de características.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 88 de 141

Figura 4.8: Walking Skeleton

Además, esta disposición de historias ayuda a decidir para proyectos que admitan varios lanzamientos o releases qué características formarán parte de las diferentes releases. Es decir, es una herramienta que permite determinar el alcance.

Figura 4.9: Determinación de las diferentes releases

La Pila del Producto del proyecto (o de cada release) se forma leyendo de izquierda a derecha y de arriba abajo las historias dispuestas en el mapa. Se recomienda mantener el mapa siempre visible para que la disposición plana de la pila no pierda la información valiosa generada al construir esta herramienta. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 89 de 141

4.4.1.6.2

Ventajas de los Mapas de Historias de Usuario

En resumen, el uso de los Mapas de Historias de Usuario proporciona las siguientes ventajas:     

Hace visible la cadena de valor del proyecto Muestra las relaciones existentes entre historias Ayuda a verificar el grado de completitud de la Pila del Producto. Provee un contexto útil para la priorización. Permite dividir el proyecto en diferentes capas completas y evaluables de funcionalidad, de modo que de una forma visual se pueda ver qué entra en el presente proyecto y qué es potencialmente entregable en sucesivos proyectos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 90 de 141

4.5 Estimando Recursos y Calculando Costes La piedra angular de la planificación es la estimación. Estimar es en esencia tratar de imaginar qué va a pasar en el futuro. Pero la precisión de la estimación no es, en general, proporcional al esfuerzo que se invierte en estimar. Mike Cohn, en base a su experiencia y a la de otros colegas, sostiene que la relación entre el esfuerzo invertido en estimar y la precisión obtenida tiene un comportamiento similar a esta curva:

Figura 4.10: Relación Esfuerzo - Precisión a la hora de estimar

Y señala dos claves importantes: Independientemente del esfuerzo que se invierta en estimar:  

Nunca se conseguirá un 100% de precisión. Una estimación no es más que una estimación.

Las estimaciones fallan la mayoría de las veces, sobre todo al inicio de los proyectos y esto se produce porque las estimaciones, por definición, son mediciones imaginarias, no reales. Si fuera viable medir, no sería necesario estimar. Y no podemos aspirar al 100% de precisión, mucho menos en proyectos complejos, donde el cambio de las variables implicadas cambia continuamente el tablero de juego. El enfoque que vamos a seguir es estimar lo indispensable para poder avanzar, y como parte fundamental en la planificación, se hará no sólo al inicio, sino durante la vida del proyecto.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 91 de 141

A estimar se aprende estimando. La precisión de las estimaciones será tanto mayor a medida que el proyecto avance y se obtenga más información sobre las características del producto, del entorno y de la forma de trabajar del propio equipo. 4.5.1 Estimación Relativa Tradicionalmente las estimaciones se han venido haciendo utilizando medidas de estimación absolutas basadas en el tiempo, como hombre / día. Pone el foco de la estimación en la capacidad de quienes han de ejecutar el elemento de la pila. Sin embargo esta magnitud no deja de ser una falacia, entendiendo que dos personas no tienen el mismo rendimiento al día. Más aun, la misma persona, dos días diferentes, puede que no alcance el mismo rendimiento. Por otro lado, se presupone que esa persona trabaja el día completo en el proyecto, cosa que puede no ser cierto, y obliga a realizar cálculos de ajuste para afinar la estimación. Por ello, preferimos utilizar una medida relativa basada en el esfuerzo, tamaño o complejidad, como son los puntos imaginarios, también llamados “Puntos de Historia”. 4.5.1.1

Puntos imaginarios o “Puntos de Historia”

En un entorno de alta incertidumbre, generalmente se prefiere estimar la complejidad de los elementos de la pila en puntos imaginarios, también llamados “puntos de historia”. Son medidas subjetivas y propias de cada equipo y cada proyecto. Pone el foco de la estimación en el elemento de la pila (o historia) que se quiere resolver, por lo tanto es independiente del número de personas del equipo o de su rendimiento. Además, nos facilitará el control del cronograma además de establecer una métrica para evaluar la capacidad del equipo (la velocidad), como veremos más adelante. Generalmente se utilizan escalas para determinar la complejidad de un elemento de la pila, como pueden ser las de potencias de 2. En el presente tratado, para explicar lo relativo a estimaciones, utilizaremos la serie de Fibonacci simplificada: 

0, 1, 2, 3, 5, 8, 13, 20, 40, 100

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 92 de 141

4.5.2 Técnicas de Estimación 4.5.2.1

Juicio de Expertos

Una persona experta, en base a su bagaje, puede dar una estimación fundada. Sin embargo, su criterio tiene mucho más peso en un proyecto tradicional que un proyecto ágil debido a que en primer escenario las estimaciones se realizan sobre actividades y por el contrario, aquí se estiman características orientadas al valor del cliente, que en esencia contendrán múltiples actividades que requieren diversos perfiles para componer una estimación fundada, en lugar de la opinión de una sola persona. 4.5.2.2

Analogía

Otra técnica de estimación es hacer analogías con elementos de la Pila ya entregados. Comparaciones como “el tamaño de este elemento es como el de los anteriores juntos” pueden servir para dar una estimación con fundamento en base al conocimiento que ya se ha generado con anterioridad. 4.5.2.3

División

Esta es la aplicación de “divide y vencerás”. Si un elemento es demasiado grande o demasiado complejo como para dar una estimación satisfactoria, entonces es conveniente dividir esa elemento en otros más pequeñas y más fáciles de estimar. No es lo mismo hacer la siguiente analogía: “este elemento es dos veces este otro elemento”, a decir: “este elemento es cuarenta veces esta otro elemento”. Seguramente con tal tamaño requerirá ser dividido para poder estimarla correctamente. 4.5.2.4

Planning Poker

El Planning Poker es una técnica de estimación propuesta por Grenning (2002) cuyo uso es generalizado en los equipos ágiles, básicamente por dos razones:  

Es efectiva Es divertida

Combina las tres técnicas explicadas anteriormente: 

Juicio de Expertos

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 93 de 141

 

Analogía División

Deben participar los tres roles de gestión que integran el Equipo de Proyecto:   

Director del Proyecto Gestor de Expectativas Gestores de Ejecución

El objetivo fundamental del Planning Poker no es predecir el futuro con el máximo de precisión. Ya hemos dicho que eso es imposible en este contexto. el objetivo es obtener la mejor estimación con el mínimo esfuerzo Es importante que en el Planning Poker participen todos Gestores de Ejecución, que representen todos los posibles perfiles que colaborarán en la ejecución del proyecto para poder obtener una visión global de la complejidad de lo que se desea hacer. Cada miembro del Equipo dispone de un juego de cartas. Cada carta tiene dibujado un número que representa una posible estimación. Como anunciamos anteriormente, utilizaremos la serie de fibonacci simplificada: 

0, 1, 2, 3, 5, 8, 13, 20, 40, 100

Además se suelen añadir dos cartas adicionales:  

? : esta carta representa que no se ha comprendido bien el elemento que se quiere estimar. café: esta carta sugiere que se debería de tomar un breve receso para reponer fuerzas.

Antes de explicar la dinámica es importante conocer por qué funciona: 



Permite obtener muchas opiniones de expertos de las diferentes disciplinas implicadas en el proyecto. El conocimiento generado durante las conversaciones es muy valioso para reducir la incertidumbre acerca del elemento en cuestión. Los Gestores de Ejecución deben justificar sus estimaciones. Esto fomenta que se generen y se aporten diferentes puntos de vista y que las estimaciones se mejoren de forma incremental y fundada. Es divertido.

La dinámica del Planning Poker es muy sencilla. Una persona debe actuar como moderador. Puede ser cualquier miembro del equipo, aunque es aconsejable que sea el Director del Proyecto. No tiene asociado ningún Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 94 de 141

privilegio especial, simplemente será el que presente cada elemento de la pila para iniciar el debate. Se comienza a trabajar con la Pila del Producto priorizada, comenzando por el primer elemento. El moderador lee su descripción. Los Gestores de Ejecución hacen preguntas al Gestor de Expectativas, y éste la responde, con el objetivo de ir reduciendo la incertidumbre sobre el QUÉ. Cuando se han respondido todas las preguntas, cada Gestor de Ejecución elige la carta que representa la estimación que él considera oportuna, pero no debe ser visible por el resto aun. En el momento en el que todos ya han elegido la suya, el moderador insta a que todos muestren sus cartas a la vez. Es importante que esto se haga así para asegurar que ninguna estimación se ve influida previamente por la estimación de otros. Hay que tener en cuenta que en el equipo puede haber gente con más o menos experiencia o con más o menos seguridad en sí mismo. Se debe dar la oportunidad por tanto, de opinar sin interferencias. Normalmente, y de forma aconsejable, sobre la mesa habrá estimaciones muy diferentes. Los dos extremos (quien haya hecho la estimación más baja y quien haya hecho la más alta) deberán en este punto explicar sus estimaciones. Una vez hecho esto, el equipo puede discutir sobre el elemento y sobre sus estimaciones. El moderador controlará el tiempo, que deberá estar acotado para no fomentar discusiones interminables. Para ello es buena idea utilizar alguna herramienta visual de control de tiempo, como por ejemplo, un reloj de arena de un par de minutos. El moderador también puede anotar en el elemento de la pila alguna de las consideraciones que se hayan expuesto sobre la mesa y que crea que puedan ser útiles. Tras este período, se vuelven a utilizar las cartas para estimar. Normalmente las estimaciones convergen en segunda ronda, pero si no es así, se repite el proceso. Hay que tener en cuenta que aunque se persiga la convergencia plena de los asistentes, no es necesario estar celebrando nuevas rondas si se puede llegar a un acuerdo antes. Imaginemos que todos los estimadores asignan 8 puntos al elemento y uno le asigna 5. Si este último acepta cambiar su estimación, se puede hacer sin problemas, dejando el elemento en 8 puntos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 95 de 141

4.5.3 Otros costes El Director del Proyecto deberá considerar otros costes asociados al proyecto. Especialmente debe tener en cuenta los requisitos de comunicaciones no sólo del Gestor de Expectativas con los interesados, sino también entre los propios Gestores de Ejecución. En proyectos donde el equipo esté disperso, es un factor importante que incide, no sólo en el coste de las comunicaciones, sino también en el rendimiento del equipo.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 96 de 141

4.6 Cerrando el horizonte 1 | Alcance inicial 4.6.1 Priorización No habrá tiempo ni recursos para desarrollarlo todo. Así que hay que priorizar. Es fundamental para focalizar los esfuerzos con el objetivo de maximizar el ROI del proyecto. La responsabilidad del Gestor de Expectativas lleva implícita una dificultad considerable. Debe considerar diferentes factores, como valor de negocio, coste de desarrollo, nuevo conocimiento generado y riesgo implicado, cada uno de los cuales poseen su propia complejidad. 4.6.1.1

Valor de Negocio

Es el principal factor de priorización, y uno de los más complicados de caracterizar. ¿Cómo cuantificamos el valor de negocio? Habrá unas pocas ocasiones en que podamos cuantificar el impacto financiero de resolver un elemento, pero en la mayor parte de las veces, nos será imposible, o el tiempo necesario para hacerlo lo hace inviable. Es conveniente, por tanto, utilizar un método alternativo de estimación del valor. Lo importante no es método que se use, sino que permita comparar elementos en base al valor que su desarrollo proporciona al cliente. 4.6.1.2

Coste de Ejecución

Es otro factor importante a la hora de priorizar. Imaginemos un elemento de la pila que hace referencia a una característica del producto absolutamente fantástica, teniendo en cuenta el valor que aporta… hasta que se considera el coste necesario para ejecutarla. Conviene no olvidar, aunque sea una obviedad, que el tiempo de las personas que se dedican a ejecutar un proyecto cuesta dinero. 4.6.1.3

Riesgo

Podemos definir el riesgo como cualquier cosa que no ha pasado pero podría pasar y que puede afectar, limitar o poner en peligro el éxito del proyecto. Se podrían establecer diferentes taxonomías de los riesgos de un proyecto. Considerando las tres variables del triángulo, podemos destacar estos tres:   

Riesgos relacionados con el tiempo Riesgos relacionados con el coste Riesgo relacionados con los elementos que se van a resolver.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 97 de 141

Otra forma de clasificarlo, atendiendo a las dos dimensiones de la complejidad es:  

Riesgos relativos a la tecnología (asociados al CÓMO) Riesgos relativos al negocio (asociados al QUÉ)

A la hora de considerar el riesgo en la priorización, podríamos considerar dos extremos:  

Desarrollo dirigido por riesgo (primero el que más riesgo tiene, sin prestar atención al valor) Desarrollo dirigido por valor (primero el que más valor de negocio aporta, sin prestar atención al riesgo)

Ambas aproximaciones tienen asociadas numerosos problemas. En el primer caso se puede dar la situación de que se ejecutando un elemento que conlleva mucho riesgo y que no aporta apenas valor de negocio, algo que conceptualmente roza el absurdo. En el segundo caso, podemos estar dejando a un lado una característica que tiene un valor similar a la actual, pero cuyo riesgo aumenta con el tiempo. Ambas situaciones son indeseables. La forma más aconsejable de trabajar con ambas dimensiones se muestra en la siguiente figura:

Figura 4.11: Valor - Riesgo

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 98 de 141

Primero se desarrollan los elementos que proporcionen un alto valor y tengan un alto riesgo. Después aquellos que tienen un alto valor y poco riesgo, dejando para el último lugar los elementos que aportan poco valor y tienen poco riesgo. Como regla general, el valor prevalece a la hora de priorizar, y sólo se utiliza el riesgo para inclinar la balanza en caso de empate. 4.6.1.4

Nuevo Conocimiento

De forma iterativa e incremental, a lo largo del proyecto se irá generando nuevo conocimiento sobre:  

El producto. El proyecto.

Estas son las dos dimensiones omnipresentes en Scrum. El producto representa el QUÉ y el proyecto representa el CÓMO. Veamos cómo se plantea la reducción de la incertidumbre en ambas dimensiones siguiendo un enfoque tradicional:

Figura 4.12: Reducción de la incertidumbre - Enfoque Tradicional (adaptación de Cohn 2006)

El enfoque tradicional intenta reducir toda la incertidumbre sobre el QUÉ se va a desarrollar al inicio y luego reducir la incertidumbre sobre el CÓMO va a ser desarrollado.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 99 de 141

El problema es que en un contexto de alta incertidumbre, no es posible conocer al detalle el QUÉ al inicio. Además, los cambios estarán presentes a lo largo de la vida del proyecto, por lo que el QUÉ se irá descubriendo y definiendo de forma iterativa e incremental a medida que se va generando el nuevo conocimiento sobre el producto. Por tanto, desde un enfoque ágil, la reducción de incertidumbre se podría representar así:

Figura 4.13: Reducción de la incertidumbre - Enfoque Ágil (adaptación de Cohn 2006)

La gráfica ilustra cómo a medida que vamos avanzando en el proyecto, el nuevo conocimiento generado sobre el proyecto va reduciendo la incertidumbre de forma gradual respecto al QUÉ y respecto a CÓMO. La pendiente representa que la dimensión del CÓMO va en función de la dimensión del QUÉ. Lógico, es esencial saber QUÉ queremos hacer antes de pensar en el CÓMO. Esto se verá muy claro cuando hablemos de la planificación en cada fase. En definitiva, es importante tener en cuenta que el nuevo conocimiento generado hará variar los otros tres factores, tanto la percepción del valor por el cliente, como las estimaciones de costes y la percepción del riesgo.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 100 de 141

4.6.1.5

Utilizando los cuatro factores

Una forma intuitiva de definir el ROI es el cociente valor / coste. Este parámetro nos da un orden inicial de los elementos de la pila, situando en la parte más alta los que tengan un ROI mayor. El resto de factores son útiles para mover elementos hacia arriba o hacia debajo de la pila. Imaginemos que tenemos en la pila dos elementos de prioridad media y tenemos que decidir cuál formará parte de una entrega del producto. Comparar el riesgo necesario o el valor que aportará el nuevo conocimiento generado por ese elemento nos facilitaría tomar una decisión bien fundamentada. 4.6.2 Establecer la longitud de las Fases Generalmente, una fase suele tener una longitud entre 2 y 4 semanas. No quiere decir esto que no se pueda dar el caso de fases más grandes o más pequeños. En cualquier caso, lo primero que hay que tener en cuenta es que, como en la mayoría de las cuestiones que tratamos, no hay fórmulas mágicas para establecer la longitud idónea, pero sí existen una serie de criterios que es necesario tener en cuenta para tomar esta decisión: 



  

La incertidumbre del proyecto y la necesidad y facilidad de obtener feedback. A mayor incertidumbre, más cortas deberían de ser las fases para obtener feedback lo antes posible y minimizar el costo de los posibles errores. Los costes asociados a cada fase. Hay que tener en cuenta que una fase implica unos costes organizativos relativos a las diferentes actividades y reuniones que se deben llevar a cabo. Cuánto tiempo pueden permanecer las prioridades sin cambiar. La longitud total del proyecto. La urgencia del proyecto.

Como siempre, la inspección y la adaptación juega un papel fundamental para que los equipos vayan reconociendo sus principales factores y qué longitud suele ser la idónea para ellos en los diferentes contextos a los que se vayan enfrentando. Eso sí, es esencial que, una vez tomada la decisión respecto a la longitud de la fase, esta longitud se mantenga a lo largo de la vida del proyecto, ya que uno de los principios fundamentales que hacen que este marco de trabajo sea efectivo es que provoca un ritmo sostenible de trabajo, esencial para crear buenos hábitos y automatizar dinámicas.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 101 de 141

4.6.3 Estimar la velocidad La velocidad es la única métrica que vamos a utilizar respecto a la capacidad y desempeño de los Gestores de Ejecución. La velocidad en una fase se determina por la suma de los puntos de historia de todos los elementos de la pila que se han logrado resolver con éxito durante esa fase. Al lo largo del proyecto será determinada en función de la velocidad registrada en las fases anteriores. Pero al inicio del proyecto carecemos de este histórico. Si los Gestores de Ejecución no es la primera vez que trabajan juntos pueden utilizar su histórico de proyectos y buscar analogías con proyectos de similares características. En otro caso se tendrá que hacer una predicción de la velocidad. Y seguramente estará equivocada. Admitámoslo y contemos con ello, porque es mejor tener una mala estimación que no tener estimación e ir a ciegas. De todos modos, a medida que el equipo trabaje junto y se avance en el proyecto, la precisión de la estimación de la velocidad será mayor, y la capacidad para aumentar la velocidad a medida que se va adquiriendo destreza en el proyecto también irá creciendo. 4.6.4 Planificar las entregas Sabemos quiénes son los Gestores de Ejecución, tenemos la Pila del Producto estimada y priorizada, hemos establecido la longitud del Sprint y hemos estimado la velocidad. Por tanto, podemos estimar qué elementos de la pila pueden ser desarrollados durante el proyecto y qué características serán resueltas en las diferentes fases. Pero ojo, esto es la foto a día de hoy. El conocimiento generado a lo largo del proyecto provocará que esta ordenación de elementos varíe, en muchos casos drásticamente.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 102 de 141

4.7 Planificación de la Calidad | Orientación ISO10006 No es el ámbito del presente tratado analizar en profundidad la norma ISO 10006, pero sí poner de manifiesto la importancia de sus lineamientos claves. Uno de los principales corolarios que se extraen de la norma es que hay dos aspectos en la aplicación de la calidad en los proyectos, los referidos a los procesos y los referidos al producto. Este principio es la raíz de la norma y le da sentido. Hemos hecho especial énfasis desde el inicio del presente tratado en dos aspectos fundamentales, el QUÉ y el CÓMO. En el ámbito del proyecto, el QUÉ hace referencia al producto resultante del mismo. El CÓMO a los procesos que hacen que se llegue a ese resultado. Ambas dimensiones implican incertidumbre en el contexto objeto de estudio por el presente tratado y por tanto, durante el proyecto se ha de medir, analizar y mejorar ambos aspectos. Hemos de aprender sobre el QUÉ y hemos de aprender sobre el CÓMO. Y aplicar este nuevo conocimiento para mejorar las dos dimensiones del proyecto. Esto es estar plenamente orientado a la calidad como valor supremo. Tanto es así que planteamos dos roles que se dedican, cada uno, a una de las dimensiones. Así, el Gestor de Expectativas tiene como misión gestionar, aprender y mejorar el QUÉ, y los Gestores de Ejecución tienen como misión gestionar, aprender y mejorar el CÓMO para ejecutar cada vez mejor el QUÉ demandado por el Gestor de Expectativas. El Director del Proyecto gestionará los recursos, facilitará el trabajo al resto de miembros del equipo y derribará impedimentos. Se preocupará por que el proceso de gestión del proyecto se lleve a cabo correctamente, con fluidez y calidad. Con ello, lo que queremos transmitir es que la calidad es algo, a nuestro juicio, irrenunciable. El marco de trabajo contempla su planificación, su aseguramiento, su control y su validación de forma implícita dentro de los procesos que lo conforman, no como algo que ha de gestionarse de forma accesoria. 4.7.1 Condiciones de Satisfacción Respecto a la planificación de la calidad, es importante señalar la necesidad de comenzar definiendo qué condiciones van a determinar que el proyecto Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 103 de 141

sea un éxito o no. Normalmente se definen como una combinación de los tres factores del triángulo de hierro:   

Objetivos respecto al tiempo Objetivos respecto al coste Objetivos respecto a alcance

Pero ya vimos que entornos de alta incertidumbre no se pueden cerrar los tres y esperar que se cumplan. Sobre todo, porque el alcance no se puede definir por completo al inicio. En lugar de ignorar este hecho, bajo un enfoque ágil se pueden cerrar dos variables, pero debe haber flexibilidad en la otra. Por ejemplo, se pueden plantear un conjunto de funcionalidades con un costo determinado y plantear una fecha flexible. O fijar tiempo y costo y ser flexible con el alcance. Determinar con anterioridad los criterios de satisfacción es fundamental para tener siempre sobre la mesa las reglas del juego. En función de estos criterios se establecerá el marco legal oportuno y se evaluará el resultado del proyecto. No obstante, a lo largo del proceso, el equipo aprenderá a conocer dónde está el listón de calidad del cliente, de modo que cada vez se consiga más y mejor llegar a este listón, sin sobrepasarlo, al mínimo coste.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 104 de 141

4.8 Planificando con personas En los proyectos de alta incertidumbre, los recursos más importantes son las personas. El Director del Proyecto debe prestar un especial cuidado a la hora de seleccionar al Gestor de Expectativas y a los Gestores de Ejecución. En este entorno no sólo se necesita la excelencia técnica en sus disciplinas, sino que además es necesario disponer un alto desarrollo de las capacidades y habilidades llamadas “blandas”, como son: la capacidad de trabajar en equipo, la empatía, la autocrítica, la comunicación, la asertividad, etc. La capacidad de aprendizaje es una de las características más valoradas en este tipo de proyectos, puesto que su éxito se basa en la forma y rapidez en la que se genera conocimiento y se aplica en la mejora del producto y de los procesos que lo producen. El Director del Proyectos tiene una gran responsabilidad para con su equipo, y debe desarrollar y poner en prácticas múltiples facetas:   

Mentor Facilitador Solucionador de Problemas 4.8.1 Mentor

El Director del Proyecto debe procurar que el resto del equipo adquiera las destrezas necesarias para llevar a cabo sus responsabilidades con profesionalidad y efectividad. Para ello actuará de mentor, guiándole en el proceso y mostrándole el camino por el que pueden aumentar sus capacidades y habilidades respecto al rol que desempeñan. El Director del Proyecto debe formar al resto del equipo de forma continua, durante todo el proceso, debe conocer las capacidades y habilidades de cada uno y sus puntos de mejora y procurarle la capacitación necesaria para potenciar las que tiene y adquirir otras nuevas útiles para el proyecto. 4.8.2 Facilitador El Director del Proyecto debe actuar durante todo el proceso como un facilitador, especialmente en las reuniones y en las interacciones entre los miembros del equipo, de modo que siempre estén focalizadas, se cumplan los objetivos y la comunicación no se desvíe y provoque la pérdida de tiempo, esfuerzo y energías.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 105 de 141

El Director del Proyecto debe procurar exacerbar en el resto del equipo sus capacidades y habilidades colaborativas para que exista una interacción positiva entre sus miembros de modo que puedan actuar de facto como un Sistema Adaptativo Complejo y aumenten sus posibilidades de resolver el problema complejo en el que se basa el proyecto. 4.8.3 Solucionador de Problemas El Director del Proyecto debe ser incansable en su afán por eliminar los impedimentos que el equipo se vaya encontrando a lo largo del proyecto. Se dice de él que es un líder servicial, porque actúa al servicio del equipo, para mantenerlo focalizado y sacar el máximo rendimiento de él. Además debe procurar que el conocimiento que se genera para la mejora del producto y del proceso formen parte de las Lecciones Aprendidas del equipo y que esta información, de este y otros proyectos, está disponible para ser usada.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 106 de 141

4.9 Comunicando | El proceso La comunicación es parte fundamental que tiene un impacto directo sobre el rendimiento del equipo. Los costes asociados a una mala comunicación en muchos proyectos es su espada de Damocles. Los múltiples canales existentes y el escaso control que se ejercen sobre ellos suelen estar detrás de estos problemas derivados de una mala comunicación. La aparición de la figura del Gestor de Expectativas pretende, por un lado reducir a uno el número de canales de comunicación entre los expertos en la dimensión del QUÉ, como es el cliente y otros interesados y los expertos en la dimensión del CÓMO, que son los Gestores de Ejecución; y por otro lado, aumentar el ancho de banda disponible de este canal. Es por ello que se sistematizan las reuniones entre el Gestor de Expectativas y los Gestores de Ejecución y que se requiere la disponibilidad del primero durante la ejecución de las diferentes fases para solventar las dudas de los segundos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 107 de 141

4.10 Abrazando la incertidumbre | Gestionando los riesgos Cuando hablamos de gestión del riesgo nos referimos a reducir la probabilidad e impacto de los eventos adversos en un proyecto. El marco de trabajo que planteamos, debido a su carácter iterativo, implícitamente logra que la gestión del riesgo forme parte inherente del ciclo de vida del proyecto. Muchos autores discuten sobre si en un ambiente ágil basado en Scrum es necesaria la gestión de los riesgos explícita. Los riesgos que son externos al proyecto requieren del Director del Proyecto su identificación, análisis y planificación de la respuesta a los mismos. Pero los riesgos internos del proyecto son gestionados de forma de forma implícita por el propio proceso de gestión del proyecto. Los marcos de trabajo ágiles abrazan la incertidumbre y se mueven bien por ella, porque no pretende resolver toda la incertidumbre al principio del proyecto. En lugar de hacer esto, prefieren producir y generar conocimiento necesario para irla reduciendo de forma iterativa. Las reuniones claves del marco de trabajo, como veremos más adelante, están enfocadas para gestionar de forma implícita todos los riesgos relativos al alcance, a los recursos, al tiempo y a la comunicación. 4.10.1 Riesgos asociados al alcance En el marco de trabajo planteado es iterativo e incremental, donde el alcance no está cerrado de inicio, y se revisa sistemáticamente priorizando las características potencialmente entregables por ROI. También de forma sistemática se revisa el producto y esta información se utiliza para revisar el alcance y planificar la siguiente fase. Con la figura del Gestor de Expectativas y bajo esta dinámica de trabajo se elimina el riesgo de que el proyecto produzca un resultado que no se adecúe a las expectativas del cliente. Los elementos del marco de trabajo más relevantes de la gestión del riesgo, son es el Scrum Diario y las reuniones de Retrospectiva. En el primero se identifican los impedimentos que cada uno de los integrantes del equipo se van encontrando y en el segundo se revisa y mejora el proyecto, para lo que, entre otras cosas, se identifican impedimentos pasados, presentes y futuros para mejorar el proceso, dotándole de capacidad de adaptación y de anticipación.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 108 de 141

Capítulo 5 EJECUTANDO LA PLANIFICACIÓN

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 109 de 141

5.1 Dirección y gestión de la ejecución | Proyectos con alta incertidumbre Un proyecto ágil puede ser considerado como la generación rápida y fiable de un flujo de:   

Nuevas capacidades para el producto Nuevo conocimiento para hacer que el producto sea mejor Nuevo conocimiento para hacer que los procesos del proyecto sean mejores

Todo ello se realiza de forma iterativa e incremental. En cada fase podemos distinguir cuatro etapas:    

Planificación: en la que se prepara el trabajo para focalizar los esfuerzos del Equipo Seguimiento y Control: en la que se realizan los trabajos planificados del proyecto, midiendo y controlando su progreso Revisión: en la que se muestran los avances en el producto final y se valida el trabajo realizado. Retrospectiva: en la que los Gestores de Ejecución mejoran continuamente los procesos de gestión y ejecución obtienen lecciones aprendidas para aplicar en las siguientes fases.

Considerar el conocimiento generado como un activo fundamental es la clave para alcanzar un alto rendimiento en entornos de alta incertidumbre.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 110 de 141

5.2 Gestión de las expectativas del cliente El Gestor de Expectativas tiene un gran protagonismo antes, al inicio, durante y al final de cada fase: 



Antes: debe actualizar la Pila del Producto, reuniéndose con el cliente y el resto de interesados si es necesarios para que este artefacto refleje las expectativas actuales del cliente. Al inicio: forma parte activa en la planificación de cada fase, donde él, como responsable del QUÉ y los Gestores de Ejecución, como responsables del CÓMO, deben intercambiar conocimiento para reducir la incertidumbre sobre el trabajo que ha de hacerse durante la fase. Durante: el Gestor de Expectativas debe estar disponible siempre que los Gestores de Ejecución lo necesiten para resolver dudas (que representan incertidumbre) y aclarar las cuestiones que ellos necesiten. Al final: el Gestor de Expectativas deberá validar cada una de las características entregadas al final de la fase.

Es por ello que en este enfoque se considera que la gestión de expectativas, como pasa como otros procesos que en la gestión de proyectos tradicional son explícitos, es inherente al marco de trabajo.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 111 de 141

5.3 Control integrado de cambios Los cambios no sólo son controlados, sino que son bienvenidos. Cuando se planifica una fase, como veremos en el epígrafe siguiente, se produce un compromiso entre el Gestor de Expectativas y los Gestores de Ejecución: durante la fase no se admitirán cambios en el trabajo que está comprometido para dicha fase, a cambio, se pueden hacer cuantos cambios se deseen en el resto de la Pila del Producto (dentro del marco de acuerdo que se haya establecido entre empresa cliente y ejecutora). No obstante pueden aparecer cambios de ejecución inmediata o urgente. Si su impacto en el proyecto en la fase es grande, como por ejemplo, un cambio de normativa que haga que el trabajo planificado para la fase carezca de sentido, habrá que suspender la fase y volver a planificar. Si es un cambio que no tiene tal impacto pero no puede esperar a que finalice la fase, se estimará el esfuerzo necesario para tal cambio y se colocará dentro de la Pila de la Fase. Esto puede implicar que parte del trabajo comprometido se quede sin ejecutar al final de la iteración. En cualquier caso es necesario que el equipo defina bien qué es un cambio urgente y cómo se actuará en tal caso. Por otra parte, una de las prácticas ágiles de mayor valor, muy utilizada en desarrollo de software, pero aplicable a muchos otros tipos de proyecto es la integración continua. Es decir, el incremento de funcionalidad que se entrega tras la fase es, como hemos dicho, un incremento de las características del producto; o dicho de otro modo, es el producto integrado con un incremento de sus características. Esto lleva implícito que cualquier característica que se produzca durante la fase no estará terminada hasta que no esté integrada con el resto del producto, que no ha de perder ni desvirtuar ninguna de sus otras características ya entregadas por la adición de la nueva. En desarrollo de software existen sistemas de integración que permiten comprobar continua y automáticamente que cuando se incorpora un nuevo elemento el software sigue cumpliendo con las especificaciones.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 112 de 141

5.4 Planificación de la fase N En contextos de alta incertidumbre es fácil perderse entre la multitud de posibilidades que tienen este tipo de proyectos, tanto en el orden en el que se pueden producir las diferentes características del producto como en el modo de producirlas. La clave está en reducir la incertidumbre de forma incremental en las dos dimensiones de incertidumbres:  

En el plano del QUÉ (know what) En el plano del CÓMO (know how)

Tratándose de proyectos que resuelven problemas complejos, necesitamos hacer inspección y adaptación para aprender, es decir, en el ámbito de un proyecto complejo, aprendemos a ejecutarlo ejecutándolo. Es decir, en el inicio no contamos con suficiente información para tomar todas las decisiones relativas al QUÉ y al CÓMO. Por otra parte, si queremos conseguir el alto rendimiento de los Gestores de Ejecución necesitamos que sus esfuerzos estén focalizados, que la incertidumbre sea mínima. ¿Cómo conseguimos focalizar nuestros esfuerzos en un contexto donde la incertidumbre es tan alta? Dos palabras claves:  

Priorización Comunicación

Es decir, no vamos a reducir la incertidumbre asociada a todo el proyecto, sólo a los elementos más prioritarios de la Pila del Producto hasta que tengamos suficiente carga de trabajo para la fase actual. Y esta labor han de llevarla a cabo:  

El Gestor de Expectativas, que es el responsable del QUÉ. Los Gestores de Ejecución, que son los responsables del CÓMO. 5.4.1 Recopilar requisitos y determinar el horizonte de la fase N | Reunión de planificación de la fase

Es importante que el Gestor de Expectativas acuda a esta reunión con la Pila del Producto actualizada. Este es un trabajo previo que debe llevar a cabo el cliente y el resto de interesados para que la pila refleje los requisitos actuales.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 113 de 141

5.4.1.1 



Intercambiar conocimiento entre el Gestor de Expectativas y los Gestores de Ejecución para reducir la incertidumbre en el plano del QUÉ y en el plano del CÓMO. Definir el trabajo que los Gestores de Ejecución deberán llevar a cabo durante la fase para focalizar sus esfuerzos y conseguir un alto rendimiento.

5.4.1.2 



Participantes

Gestor de Expectativas: debe preparar con carácter previo la Pila del Producto, intercambiará conocimiento con los Gestores de Ejecución y tomará decisiones respecto a la priorización de los elementos de la pila. Gestores de Ejecución: deberán intercambiar conocimiento con el Gestor de Expectativas, deberán plantear los riesgos posibles en su ejecución, tienen la responsabilidad de estimar el esfuerzo necesario para producir cada una de las características potencialmente entregables, y decidirán la carga de trabajo que son capaces de asumir durante la fase. Director del Proyecto: deberá ejercer de facilitador, en todo momento debe mantener el foco de la reunión, controlar los tiempos de cada parte y facilitar la comunicación entre todos los participantes. Adicionalmente, de forma opcional, pueden asistir otros interesados en el proyecto, pero no pueden participar a no ser que se les pregunte. El Director del Proyecto debe procurar que nadie rompa el flujo de comunicación entre el Gestor de Expectativas y los Gestores de Ejecución.

5.4.1.4 

Duración

Típicamente, una jornada de 8 horas dividida en dos partes de 4 horas cada una.

5.4.1.3 

Objetivos

Prerrequisitos

Es fundamental que asistan tanto el Gestor de Expectativas como los Gestores de Ejecución. Si el Gestor de Expectativas no pudiera asistir, deberá delegar esta función en alguien de su confianza que tendrá las mismas funciones y obligaciones que él mismo en su ausencia, y por tanto sus decisiones serán vinculantes en el proyecto.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 114 de 141



El Director del Proyecto ha de asegurarse previamente que se dispone de un espacio suficiente como para que los participantes puedan interactuar de forma cómoda. El Gestor de Expectativas debe llegar a la reunión con la Pila del Producto priorizada.

5.4.1.5

Organización

La reunión de Planificación de la Fase consta de dos partes:  

Primera Parte o Planificación del QUÉ (4 horas). Segunda Parte o Planificación del CÓMO (4 horas).

5.4.1.5.1

Primera Parte: Planificación del QUÉ

El objetivo de esta primera parte es determinar qué características van a ser producidas durante la fase. Es decir, determinar qué elementos de la Pila del Producto van a conformar el incremento de valor que se entregará al final de la fase. El Gestor de Expectativas habrá de exponer los elementos de la Pila del Producto, comenzando por el más prioritario. Para cada uno de ellos los Gestores de Ejecución le harán las preguntas necesarias para comprender realmente QUÉ se quiere producir, lo suficiente como para poder estimar el esfuerzo necesario para hacerlo. Por otro lado, el Gestor de Expectativas deberá comprender la complejidad y los posibles impedimentos, riesgos e implicaciones asociados la producción del elemento, lo cual puede hacer que tome la decisión de cambiar la prioridad de la pila debido a esta nueva información. Esta parte de la reunión es un acto de comunicación entre el Gestor de Expectativas (el QUÉ) y los Gestores de Ejecución (el CÓMO) de modo que ambas partes aporten la información necesaria para reducir la incertidumbre hasta el punto de que sea manejable. Es una conversación en la que se negocia en base a argumentos. Los Gestores de Ejecución tendrán que valorar el esfuerzo que pueden asumir durante la fase. De modo que, cuando el conjunto de elementos de la Pila del Producto procesados cubra el cupo del esfuerzo máximo que ellos estiman para cada fase, la primera parte de la reunión se da por concluida. La técnica del Planning Poker es muy efectiva y divertida para dinamizar este tipo de reuniones.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 115 de 141

El resultado de esta reunión es la selección del segmento de la Pila del Producto que será transformado durante la fase en un incremento de valor entregable. 5.4.1.5.2

Segunda Parte: Planificación del CÓMO

En la segunda parte de la reunión los Gestores de Ejecución tendrán que definir, para cada elemento de la Pila del Producto las tareas necesarias para poder desarrollarlo, con la suficiente granularidad como para que cada tarea pueda ser resuelta por una persona en un tiempo determinado. Los elementos de la pila que se van a producir junto con las tareas en las que se divide cada elemento forman la Pila de la Fase, que representa el trabajo que los Gestores de Ejecución tienen que llevar a cabo durante la iteración. Respecto a la estimación de las tareas, se puede seguir, entre otras, estas estrategias:   

Estimarlas No estimarlas Dimensionarlas de modo que todas las tareas requieran más o menos el mismo esfuerzo. Con esta estrategia, el esfuerzo restante en la fase es directamente proporcional al número de tareas que quedan.

Cada equipo debe encontrar la estrategia que mejor le convengan. Hay quienes prefieren no estimarlas, porque consideran que no aporta un valor adicional, puesto que ya se ha estimado el elemento de la pila. Por el contrario hay quienes opinan que estimar las tareas ofrece un mayor control sobre el proyecto y permite aplicar técnicas de gestión de tares. Todo dependerá de la naturaleza del proyecto y de las necesidades del equipo. En este aspecto, inspección y adaptación vuelven a ser fundamentales. 5.4.2 Planificación de las comunicaciones en la Fase N Los principales puntos de comunicación entre el Gestor de Expectativas y los Gestores de Ejecución se llevan a cabo al inicio, en la Reunión de Planificación de la Fase, y al final, en la Reunión de Revisión. No obstante, el Gestor de Expectativa debe estar disponible durante la fase para resolver cualquier duda que pueda surgirles a los Gestores de Ejecución.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 116 de 141

Asimismo, durante la fase, el Gestor de Expectativa tendrá que comunicarse con el cliente y el resto de implicados para aportarles feedback y seguir trabajando en la captación de requisitos. El Director del Proyecto deberá crear las condiciones idóneas y disponer de los medios necesarios para que la comunicación entre los Gestores de Ejecución sea fluida. Especialmente es importante cuando el equipo no comparte localización. Los puntos más notables de comunicación entre los Gestores de Ejecución durante la fase son la Reunión de Sincronización Diaria y la Retrospectiva, pero no debemos olvidar que la comunicación entre ellos debe ser constante, porque es su interacción (véase Capítulo 1, cuando hablamos de los Sistemas Adaptativos Complejos) donde son capaces de llegar a buenas soluciones con un alto rendimiento. 5.4.3 Planificación de la Gestión de Riesgos en la Fase N Como señalamos anteriormente, el Director del Proyecto deberá tener identificados los riesgos externos al proyectos, analizados y establecido su plan de respuesta. Respecto a los riesgos internos, serán gestionados implícitamente en el marco de trabajo. Particularmente, como veremos, la Reunión de Sincronización Diaria y la Retrospectiva son los elementos del marco de trabajo que actúan directamente sobre los riesgos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 117 de 141

5.5 Gestión de la Calidad en la Fase N 5.5.1 Calidad del Producto En la planificación de la fase, los Gestores de Ejecución deben incluir en la Pila de la Fase las tareas que sean necesarias para asegurar la calidad de cada una de las características que producen y de su integración en el producto final, para considerar que un determinado elemento de la pila está terminado. De este modo, el aseguramiento de la calidad del entregable es continuo. Al final de la fase, en la reunión de Revisión, el Gestor de Expectativas valida la calidad de las características entregadas. 5.5.2 Calidad de los Procesos Durante la ejecución se celebran Reuniones de Sincronización Diarias para, entre otras cosas, poner de manifiesto cuáles son los impedimentos que los Gestores de Ejecución se van encontrando en el ejercicio de su trabajo. El Director del Proyecto debe actuar como solucionador de problemas y dedicarse a eliminar todas estas barreras. También llevará un registro de impedimentos que pondrá sobre la mesa en la Reunión de Retrospectiva, donde los Gestores de Ejecución analizarán los procesos del proyecto para detectar puntos de mejora y solucionarlos, de modo que con el conocimiento adquirido se mejoran para la siguiente fase y el resto del proyecto. Estas mejoras serán registradas en un archivo de lecciones aprendidas.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 118 de 141

5.6 Gestión de las Personas en la Fase N La mayoría de organizaciones cuentan con múltiples proyectos y múltiples personas dedicadas a esos proyectos. También hay proyectos que cuentan con personas de múltiples organizaciones. En cualquier caso estos recursos deben ser inteligentemente gestionados. Esto implica que es posible que durante el proyecto haya incorporaciones y salidas de personas dentro del equipo de Gestores de Ejecución. Lo recomendable en este tipo de entornos es que estas salidas o entradas de personas no afecten a la fase, y que se realicen antes o después, pero nunca durante. Eso es así por la importancia de que planifiquen el trabajo aquellos que lo van a ejecutar. Cuando una incorporación, el Director del Proyecto debe ejercer de mentor para acelerar en la medida de lo posible su integración en el equipo.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 119 de 141

5.7 Control y Seguimiento En este punto, teniendo claro el plan de trabajo que hay que seguir durante la fase, es tiempo de trabajar en la producción de las características elegidas para la presente iteración. No es objeto del presente tratado entrar en cuestiones técnicas relativas al CÓMO. Cada disciplina tiene unos conocimientos, técnicas y métodos específicos que confieren al Equipo de la excelencia técnica necesaria. Nos ocuparemos, como adelantamos en los capítulos introductorios, de la capa de dirección y gestión. 5.7.1 Monitorizar y controlar los riesgos Uno de los principios que hacen de Scrum un marco de trabajo de alto rendimiento es su afán explícito porque los problemas, errores, impedimentos emerjan cuanto antes, de modo que su coste sea el menor posible y que se conviertan de facto en puntos de aprendizaje que generen conocimiento de valor sobre el producto o sobre el proyecto. Imaginemos un escenario donde dos miembros del Equipo están trabajando en diferentes características del proyecto. Llamémosles María y Pablo. Pongámonos en la situación de que María tiene un problema que le está trayendo quebraderos de cabeza. Pablo por su parte se ha encontrado con otro problema muy similar al de María. ¿No sería interesante que ambos lo supieran para ayudarse mutuamente? Imaginemos que uno de los dos lo ha logrado resolver y el otro ni se entera. ¿Cuánto retrabajo evitable se estaría produciendo? Es necesario que esta información fluya. Es necesario que se sincronicen los esfuerzos para que el retrabajo sea mínimo, y todo el esfuerzo y todas las energías se inviertan en actividades que aportan realmente valor. Por otra parte, cuando una persona trabaja dentro de un equipo de trabajo puede tender a pensar que los demás no trabajan o no se esfuerzan como ella. En cualquiera de los dos casos la clave está en la comunicación. Este es el sentido de celebrar cada día una Reunión de Sincronización, acotada en el tiempo y en contenido, y enfocada a transmitir la información más relevante para comenzar la jornada, que facilita información sobre el desempeño de cada cual así como de los impedimentos que se tienen.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 120 de 141

5.7.1.1

Reunión de Sincronización

5.7.1.1.1

Objetivos

  

Sincronizar los esfuerzos de los Gestores de Ejecución Revisar el avance hacia los objetivos de la fase Identificar impedimentos

5.7.1.1.2  

Gestores de Ejecución. Deben estar todos. Director del Proyecto. Debe conducir la reunión y tomar nota de los impedimentos puestos de manifiesto durante la reunión para facilitar su resolución durante la jornada.

5.7.1.1.3   

Participantes

Prerrequisitos

Celebrar esta reunión en el mismo lugar y a la misma hora todos los días, para logar instaurar correctamente el hábito. Debe existir máxima puntualidad. No debe exceder de los 15 minutos.

5.7.1.1.4

Organización

La dinámica es muy sencilla: cada uno de los Gestores de Ejecución responde a tres preguntas:   

¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Qué impedimentos tengo?

No es una reunión para discutir. Es una reunión para comunicar. No se debate, no se juzga, no se interrumpe. Cuando todos los miembros del equipo las han respondido, finaliza la reunión. La primera consecuencia es que, tras la reunión, todos tienen consciencia del trabajo de todos y de cada uno. Es muy humano el pensar que nosotros somos los que más trabajamos en los proyectos y que los demás parecen no hacer nada. Con la Reunión de Sincronización se tiene conciencia explícita del esfuerzo, el desempeño y el compromiso de todos, aumentando la confianza en el Equipo y favoreciendo el sentimiento de pertenencia y de unidad. La segunda consecuencia es que se ha compartido conocimiento importante sobre los impedimentos. Por un lado, el Director del Proyecto tomará nota Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 121 de 141

de los impedimentos y trabajará durante la jornada para solucionarlos. Por otro lado, impedimentos a nivel técnico son compartidos para facilitar que interactúen entre los Gestores de Impedimentos para resolverlos. Esta labor de comunicación es absolutamente esencial para conseguir un ritmo de trabajo fluido y sincronizado. 5.7.1.2

Reunión de Retrospectiva

El otro punto importante de control de riesgos es la Reunión de Retrospectiva, donde los Gestores de Ejecución ponen de manifiesto todos los puntos de mejora en los procesos que han detectado durante la fase y se establece un plan de acción para solucionarlos. Hablaremos sobre estas reuniones en el presente capítulo, en la sección de Mejora Continua. 5.7.1.3

Monitorizando y controlando otros riesgos

Durante la fase, el Director del Proyecto tendrá que resolver los impedimentos que vayan apareciendo durante la ejecución y deberá seguir atentos a los riesgos externos del proyecto, actualizando la lista de riesgos o los planes de contingencia si es preciso como consecuencia progreso del proyecto y el nuevo conocimiento generado. 5.7.2 Monitorizar y controlar el trabajo En la planificación de la fase, los Gestores de Ejecución configuran la Pila de la Fase, artefacto que será utilizado durante la fase para gestionar el trabajo que deben desempeñar. Para visualizar y actualizar la Pila de la Fase, se utiliza una herramienta de gestión visual llamada Panel de Tareas. 5.7.2.1

Panel de Tareas

La Pila de la Fase, como ya se ha hablado, consta de los “n” primeros elementos de la Pila del Producto y su descomposición en tareas. Esta herramienta sirve para visualizar y gestionar esta información de un modo sencillo. Consta de:  

Una columna en la que se sitúan los elementos de la Pila del Producto seleccionados para la presente fase. Varias columnas para albergar las tareas y sus diferentes estados. Típicamente se suelen incluir tres estados para las tareas: o Pendiente: Esta columna alberga inicialmente las tareas en la que se descompone cada elemento de la Pila. o W.I.P. (work in progress) o “en progreso”: cuando una tarea comienza a ser ejecutada, se coloca en esta columna.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 122 de 141

Algunos equipos limitan el número de tareas que se pueden colocar aquí, tal como se hace en Kanban, para evitar que existan demasiados frentes abiertos y forzar a que se resuelvan los impedimentos que hacen que ese trabajo en ejecución no se haya finalizado. Terminado: Este es lugar para las tareas que se han finalizado completamente. Cuando todas las tareas de un elemento de la Pila se han terminado y se cumplen los criterios de satisfacción de ese elemento, se puede trasladar la ficha que simboliza el elemento de la pila a esta columna, para mostrar que se ha terminado su ejecución.

Figura 5.1: Diseño básico de un Panel de Tareas

Sea por medios físicos o por medios digitales, lo ideal es que el panel esté visible en todo momento y sea sencillo interactuar con él. Algunos equipos añaden más estados, en función de la naturaleza de su trabajo, como por ejemplo “en pruebas”. Lo ideal es que cada equipo pruebe diferentes configuraciones hasta encontrar el diseño que le sea más útil. El Panel de Tareas ofrece mucha información con un solo vistazo. En el panel de la figura vemos, cómo ya se ha entregado un elemento de la pila, actualmente hay tres tareas en progreso y queda mucho trabajo todavía pendiente. Pero, dada esta información, ¿el equipo va bien o va mal respecto a lo planificado? Necesitamos una herramienta adicional para Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 123 de 141

cruzar la información de progreso con el tiempo, y esa el diagrama de quemado (o burndown) de la fase, que explicamos en el siguiente epígrafe. 5.7.3 Controlar el desempeño

cronograma

Seguimiento

del

La información del panel es rica, pero en términos de seguimiento y control, nos falta un dato importante para llevar las riendas de la fase. Y es el tiempo. Sería interesante cruzar la carga de trabajo terminada con el tiempo restante para conocer el progreso real respecto al tiempo. 5.7.3.1

Diagrama de quemado o burndown

La información del panel es rica, pero en términos de seguimiento y control, nos falta un dato importante para llevar las riendas de la fase y del proyecto. Y es el tiempo. Sería interesante cruzar la carga de trabajo terminada con el tiempo restante para conocer el progreso real respecto al tiempo. Para ello, utilizamos el diagrama de quemado o burndown. En el eje vertical se sitúa el trabajo restante, típicamente medido en puntos de historia. En el eje horizontal se sitúa el tiempo. Entre ambos ejes se traza una línea que indica el progreso ideal.

Figura 5.2: Diagrama de quemado o burndown

Al final de cada jornada, se actualiza el burndown. Si la gráfica está por encima de la línea de progreso ideal (en el ejemplo, en los cuatro primeros días), nos indica que nos estamos retrasando respecto a lo planificado. Si la

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 124 de 141

gráfica está por debajo (en el ejemplo en el sexto día), indica que nos estamos adelantando. Si la distancia entre la gráfica y la línea ideal es muy acusada, y eso nos hace prever que no vamos a entregar lo planificado durante la fase o que vamos a finalizar el trabajo antes de tiempo, es momento de informar al Gestor de Expectativas para aclarar las expectativas cuanto antes. En el segundo caso, cuando se prevé tiempo de trabajo adicional, se pide que el Gestor de Expectativas confirme la prioridad de la Pila del Producto, para aprovechar el tiempo restante avanzando en la producción de más características. 5.7.4 Controlar los costes El Director del Proyecto debe mantener un estrecho control sobre los costes de gestión del proyecto y comprender por qué aumentan o disminuyen sobre el presupuesto aceptado. Asimismo, el Gestor de Expectativas debe llevar a cabo su responsabilidad de priorizar las características potencialmente entregables teniendo en cuenta los costes asociados a la producción de cada una de estas características. Los Gestores de Ejecución deben informar cuando el valor real del coste necesario para producir una característica sobrepasa el estimado en tal medida que influirá en el trabajo comprometido para la fase. De este modo se toman decisiones tempranas de adaptación respecto a las expectativas de entrega. 5.7.5 Asegurando la calidad A la hora de producir una característica, los Gestores de Calidad no pueden darla por terminado hasta que no se aseguran que cumple las condiciones de satisfacción acordadas para esa característica y que su integración con el resto del producto es correcta y no impacta negativamente en el mismo. 5.7.6 Comunicaciones Entre los Gestores de Ejecución debe existir el mayor ancho de banda posible para favorecer su interacción. Los principales puntos de comunicación entre el Gestor de Expectativas y los Gestores de Ejecución se sitúan al principio y al final de la fase, en la Reunión de Planificación de la Fase y en la Reunión de Revisión. No obstante, el Gestor de Expectativas debe estar disponible durante la ejecución de la fase. El Director del Proyecto debe asegurar la fluidez y la efectividad de estas interacciones para reducir los costes asociados a la falta de información y los malentendidos. Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 125 de 141

5.8 Cierre de la Fase N 5.8.1 Control y cierre de la calidad Se ha finalizado la fase y todo el esfuerzo del equipo ha cristalizado en un entregable que supone un incremento de la funcionalidad del producto final, representado por una serie de características que se planificaron en la Reunión de Planificación de la Fase y que en al finalizar la misma están terminadas. Para validar el trabajo realizado se convoca la reunión de Revisión, donde los Gestores de Ejecución presentan al Gestor de Expectativas el fruto de su trabajo, para que éste compruebe que cumple las condiciones de evaluación. Son muy importantes estas reuniones porque permiten al equipo descubrir dónde está el umbral de calidad aceptable del Gestor de Expectativas (y por ende, del cliente); es decir, el límite en el que se le ofrece justo la calidad que quiere con el mínimo coste. En otras palabras, aquí se revisa el QUÉ, con objeto de mejorar el producto. 5.8.1.1 



Presentar el resultado de la fase. Esto implica validar la calidad del producto entregado verificando que se cumplen las condiciones de satisfacción. Obtener feedback para mejorar el producto en las siguientes fases.

5.8.1.2 

 



Duración

Típicamente 4 horas como máximo.

5.8.1.3 

Objetivos

Participantes

Gestor de Expectativas. Será quién valide las características entregadas. Gestores de Ejecución. Presentaran el su trabajo durante la fase. Director del Proyecto. Se asegurará de que la comunicación es fluida y de que se cumplen los objetivos marcados para la reunión en el tiempo destinado para ello. Otros interesados. Sus opiniones son valiosas a la hora de evaluar el producto.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 126 de 141

5.8.1.4 



Prerrequisitos

Disponer de un espacio suficiente como para que los participantes puedan interactuar de forma cómoda y para que la muestra del incremento de valor entregado se pueda llevar a cabo. Todas las características presentadas en la revisión cumplen la condición de “terminado”. Nada que no esté terminado se mostrará en la revisión.

5.8.1.5

Organización

Es una reunión con un marcado carácter informal. Es decir, se deja a un lado la solemnidad para que todos trabajen juntos en colaboración para mejorar el producto y generar conocimiento aplicable al resto del proyecto. Característica por característica, se van evaluando las condiciones de satisfacción y se van vertiendo opiniones sobre el resultado final del trabajo. Las características que no han pasado la revisión deberán de situarse de nuevo en la Pila del Producto. 5.8.2 Informes de Desempeño El Director del Proyecto debe conocer cuál es el desempeño del equipo en cada fase y el progreso del proyecto respecto al trabajo planificado. Para ello, se utiliza un diagrama de quemado o burndown para el proyecto. El eje vertical mide el trabajo restante en todo el proyecto, y el eje vertical representa las diferentes fases. Se traza una línea uniendo la cifra de trabajo planificado inicialmente para el proyecto con el número que representa las fases inicialmente planificadas, dando como resultado una línea de progreso ideal. Después de cada fase, se actualiza el diagrama. Al igual que en el diagrama de fase, si la gráfica se sitúa por encima de la línea de progreso ideal, es que nos estamos retrasando respecto al progreso ideal. Por el contrario, si la gráfica se sitúa por debajo, vamos adelantados. Esta información facilita la toma de decisiones. 5.8.3 Mejora continua | aprendiendo Una vez hecha la revisión y antes de comenzar la siguiente fase, se celebra una de las reuniones más importantes del proyecto: la Reunión de Retrospectiva. Se trata, en este caso de revisar el CÓMO, con objeto de mejorar los procesos implicados en la ejecución del proyecto. Si el conocimiento extraído de la Revisión nos permite desarrollar cada vez un

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 127 de 141

mejor producto, el conocimiento generado en la Retrospectiva nos permite mejorar el proceso por el que lo producimos. La disposición con la que los Gestores de Ejecución encaran esta reunión clave marca la utilidad y el aprovechamiento de la misma. El reconocimiento del error, la aceptación del hecho de que todos somos vulnerables y la voluntad de aprendizaje cobran su mayor sentido en la Retrospectiva. 5.8.3.1 

Mejorar el proyecto consiguiendo el máximo impacto de mejora con el mínimo esfuerzo.

5.8.3.2 



Participantes

Gestores de Ejecución: que son los responsables del CÓMO y quienes mejor conocen el proyecto y sus procesos. Director del Proyecto: que debe facilitar la comunicación y la participación de todos los Gestores de Ejecución y asegurarse que se actualiza el registro de lecciones aprendidas.

5.8.3.4 

Duración

Típicamente, 3 horas.

5.8.3.3 

Objetivos

Prerrequisitos

Disponer de un espacio suficiente como para que los participantes puedan interactuar de forma cómoda. Debe celebrarse entre la reunión de Revisión de una fase y la reunión de Planificación de la siguiente.

5.8.3.5

Organización

Independientemente de las técnicas utilizadas, una Retrospectiva tiene generalmente las siguientes etapas:     

Apertura Recopilación de datos Comprensión del problema Establecimiento de un Plan de Acción Cierre

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 128 de 141

5.8.3.5.1

Apertura

En esta fase, el Facilitador debe situar a los miembros del equipo de trabajo en el contexto de la retrospectiva, procurando crear y mantener un ambiente de participación y colaboración. Se repasan los objetivos de la reunión, las fases de la retrospectiva y el tiempo disponible. Lo que el Facilitador tratará en esta etapa es que todos se enganchen cuanto antes a la dinámica de la reunión teniendo en cuenta el proceso y la limitación en tiempo. 5.8.3.5.2

Recopilación de Datos

En esta etapa el reto principal es que los Gestores de Ejecución generen la mayor cantidad de información sobre problemas e impedimentos encontrados durante la fase. Hay diversas formas de llevar esta labor a cabo, pero en cualquiera de ellas, los puntos de mejora son la materia prima para el resto del proceso de retrospectiva. Es importante que de forma individual y de forma colaborativa, los participantes tengan tiempo para pensar y para opinar sobre los diferentes puntos de mejora detectados. Para refrescar la memoria, el Director del Proyecto puede poner sobre la mesa los impedimentos claves detectados durante las Reuniones de Sincronización. Al final de esta fase los Gestores de Ejecución priorizarán los puntos de mejora para focalizar las energías, el tiempo y los recursos limitados en resolver los más prioritarios. 5.8.3.5.3

Comprensión del Problema

Una vez se ha priorizado y decidido por tanto dónde se va a poner el foco de la mejora, los esfuerzos se destinan a comprender bien la dimensión de los problemas que se están tratando para intentar localizar su/s causa/s raíces, de modo que puedan formular la mejor solución posible y evitar la aparición de problemas derivados. Es un proceso diagnóstico que admite la analogía con el ambiente médico. Lo interesante no es únicamente mitigar los síntomas que se manifiestan, sino identificar, localizar y erradicar la enfermedad que los provoca. 5.8.3.5.4

Establecimiento de un Plan de Acción

Es el momento de pensar en términos de solución. De aunar experiencia, conocimiento y creatividad y aplicarlos a la resolución de problemas, de forma colaborativa, con la participación de todos.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 129 de 141

Para ello, los Gestores de Expectativas habrá de proponer posibles soluciones y seleccionar la mejor propuesta para llevarla a cabo. A partir de ahí, tendrá que planificar cómo, quién y cuándo se van a implementar las soluciones propuestas. La etapa finaliza con el compromiso de todos los participantes respecto al plan de acción elaborado. 5.8.3.5.5

Cierre

En esta última fase se repasa la reunión, los objetivos y cómo ha ido evolucionando la sesión a medida que se han ido sucediendo las diferentes etapas y aplicando el conocimiento generado. El Director del Proyecto debe agradecer el esfuerzo de los miembros del equipo y felicitarles por los objetivos logrados. Por último, es conveniente hacer una dinámica de mejora continua de la retrospectiva, para poder mejorar también este proceso.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 130 de 141

Capítulo 6 CIERRE DEL PROYECTO

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 131 de 141

6.1 Cierre Administrativo del proyecto y sus fases Muchos proyectos sufren el síndrome del proyecto eterno. Continúan en el sistema de gestión del portfolio de las empresas, consumiendo recursos, sólo porque no se ha hecho un correcto cierre o se ha dejado morir cuestiones abiertas. Cerrar el proyecto implica finalizar todas las actividades de la dirección de proyectos para completar formalmente el proyecto. Cuando el proyecto se cierra, el Director del Proyecto deberá revisar toda la información anterior procedente de los cierres de las fases previas para asegurarse de que todo el trabajo del proyecto está completo y de que el proyecto ha alcanzado sus objetivos. Si el proyecto se ha dado por terminado antes de su culminación, se deberán documentar y analizar las razones las acciones emprendidas. Deberán actualizarse la información de procesos de la organización:  



Los archivos del proyecto Los documentos de cierre del proyecto o fase. Los documentos de cierre del proyecto o fase, que consisten en la documentación formal que indica la terminación del proyecto o fase y la transferencia de los entregables del proyecto. La información histórica y la de las lecciones aprendidas, para que formen parte de la base de conocimientos de la organización para su uso en el futuro, entre la que se incluye información sobre riesgos y sobre técnicas y prácticas que han funcionado bien durante el proyecto. Hemos dicho en varias ocasiones en el presente tratado que el este tipo de proyectos genera no sólo el entregable final, sino también conocimiento sobre el mismo y sobre los procesos implicados que gracias a su registro pasan a formar parte de los activos de la organización.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 132 de 141

Capítulo 7 COMPLEMENTANDO EL CONOCIMIENTO

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 133 de 141

7.1 Contratos Ágiles Las reglas del juego en este tipo de proyectos se acuerdan libremente por ambas partes para crear mejores condiciones posibles para finalizar con éxito el proyecto. El contrato es un documento que refleja estas reglas del juego. En demasiadas ocasiones los contratos representan una competición en la cual el objetivo de cada una de las partes es dejar en desventaja a la otra parte, especialmente cuando las cosas van mal. Muchas organizaciones públicas y privadas, sobre todo de tamaño considerable, tienen condiciones manifiestamente injustas que deben aceptarse para comenzar a trabajar con ellos. Incluso los contratos que parten de una negociación previa no siempre intentan llegar a una situación ganar-ganar. Un contrato distribuye el riesgo y refleja la confianza entre las partes. ¿Qué ocurre cuando algo sale mal? ¿Quién paga cuánto si el proyecto es más difícil de lo esperado? ¿Quién se beneficia si el proyecto se termina antes de lo planificado? Usar las reglas incorrectas puede ser perjudicial para el éxito del proyecto. Las reglas malas llevan a precios irrealistas, tiempos imposibles o expectativas que no se cumplen. Los juegos ganar-perder suelen ser un cáncer para el éxito del proyecto. La calidad casi siempre sale perjudicada. Hay que pensar muy cuidadosamente qué grado de presión es la adecuada para el proveedor. 7.1.1 Evaluación de los contratos Hay que poner especial atención a estas cuestiones:    

¿Cómo está estructurado el contrato? ¿Cuáles son las reglas básicas para el alcance de las entregas y la factura por ingresos? ¿Cómo se reparte los Riegos y las Recompensas entre el cliente y el proveedor? ¿Cómo se gestionan los cambios? ¿Qué modelo de relación con el cliente fomenta: competitividad (ganar-perder), cooperación (ganar-ganar), indiferencia (no me importa si pierdes) o dependencia (si sale bien yo gano, si no tú pierdes)?

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 134 de 141

7.1.2 Información que debe incluirse en el contrato La necesidad de escribir en el contrato es inversamente proporcionar a la confianza entre el cliente y el proveedor. A mayor confianza, menos habrá que especificar. No obstante siempre es conveniente que aparezca en el contrato las siguientes cuestiones:      

Objetivos del proyecto y de la cooperación entre las organizaciones. Un resumen de la estructura del proyecto – marco de trabajo procesos, roles clave y atribuciones. Personal clave y que se necesita de estas personas. Pagos y facturación, incluyendo las cláusulas de bonus y penalizaciones. Terminación normal y temprana del contrato. "Detalles legales". Dependiendo de las leyes locales y costumbres legales, es posible que tenga que limitarse la responsabilidad civil, especificar la ganancia, o incluir otros textos que se necesiten legalmente.

Determinar el alcance en el contrato lo hace inflexible. Es mejor idea especificar cómo se va a gestionar el alcance dejar los detalles fuera. 7.1.3 Algunos enfoques contractuales 7.1.3.1

Todo el riesgo para el proveedor: “Todo cerrado”

Esta base contractual es típica en concursos públicos o licitaciones, en los que el cliente es una corporación con un poder considerable que cierra las reglas del juego. Aquí se fijan los tres vértices del triángulo de hierro. Este enfoque no admite cambios. Todo el riesgo lo asume el proveedor y no hay ningún elemento que incentive al cliente a dar por finalizado el proyecto. 7.1.3.2

Todo el riesgo para el cliente: “Tiempo y materiales”

En este enfoque el cliente paga por tiempo y materiales sin fijar un compromiso de alcance ni tope de coste, por lo que finalizado el tiempo contratado es posible que ni siquiera se haya generado un entregable. El proveedor no tiene ningún incentivo para entregar cuanto antes. Todo el riesgo lo soporta el cliente. Es una base utilizada en proyectos de outsourcing, aunque con este enfoque, sin ninguna modificación, puede salir más rentable emplear personas. El desequilibrio de riesgo es tan desfavorable para el cliente que tiene sentido si existe mucha confianza con el proveedor.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 135 de 141

7.1.3.3

Riesgo cerrados”

limitado

para

cliente:

“Tiempo

coste

Este es otro enfoque en el que la confianza entre cliente y proveedor es esencial. En este caso se establece una priorización en el alcance y se contrata un tiempo determinado con un coste fijo. Esto no quiere decir que se vaya a entregar todo el alcance, sólo que el proveedor trabajará en él, siguiendo la prioridad establecida, sin ningún compromiso de hasta dónde puede llegar a desarrollar. Esta base es utilizada en proyectos ágiles, pero requiere una gran confianza del cliente respecto al proveedor. 7.1.3.4

Riesgo limitado y decreciente para el cliente: “Tiempo y materiales por fases”

Se trata del enfoque “tiempo y materiales” con la limitación de que la ejecución se realiza por fases incrementales, de modo que tras finalizar cada fase el cliente tendrá un incremento del producto con valor para el cliente. Limita el riesgo porque, aunque no existe un compromiso respecto al alcance que se entregará en cada fase, al menos el cliente se asegura la entrega en el tiempo fijado. A medida que el proyecto avanza y aplica el conocimiento generado sobre el producto y sobre los procesos, afinando las estimaciones y entregando a tiempo, la percepción de riesgo soportado por el cliente va decreciendo. 7.1.3.5

Riesgo progresivo”

limitado

compartido:

“Tiempo

cerrado

Es una variante del “todo cerrado” muy simple. Se trata de dividir el proyecto en varias partes. Se plantea un “todo cerrado” para la primera y se evalúan los resultados. Con lo aprendido hasta la fecha se redefine la siguiente parte. Esto permite aplicar los conocimientos generados en el proyecto para las sucesivas planificaciones, con mejores estimaciones gracias al aprendizaje. 7.1.3.6

Riesgo compartido: “target cost”

Este enfoque está especialmente recomendado para los proyectos con una ejecución incremental por fases. Para su desarrollo es necesaria una gran colaboración entre cliente y proveedor. Básicamente se toma como base una planificación inicial del proyecto. Al tratarse de un proyecto con alta incertidumbre, se asume que la estimación inicial estará equivocada. Por tanto, para poder establecer un precio objetivo se calcula el coste en tiempo que tendría la ejecución del proyecto, sin olvidar el factor de foco (es decir, hay que añadir tiempos de reuniones y otras actividades necesarias). A Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 136 de 141

partir de aquí se establecen tres umbrales. Un tiempo estimado objetivo, un tiempo optimista y un tiempo pesimista. Si el proyecto finaliza entre el umbral optimista y el tiempo objetivo, se comparten los beneficios. Si acabara entre el tiempo objetivo y el tiempo pesimista, se comparten los costes. Por debajo del tiempo optimista, el riesgo es del cliente. Por encima del tiempo pesimista, el riesgo es del proveedor.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 137 de 141

7.2 Claves de la comunicación La comunicación efectiva es uno de los principios armónicos de este marco de trabajo. Que se produzca de manera fluida, y sobre todo, efectiva, impacta gravemente sobre el devenir del proyecto. Su importancia suprema hace que merece la pena que en este punto hablemos un poco más del proceso de comunicación desde el punto de vista de la efectividad. Se le atribuye a Jaques Lacan la frase “toda comunicación es un malentendido”. Y no es ajena a la verdad, ni mucho menos, porque en todo proceso comunicativo entre personas existe pérdida de información. El emisor IMAGINA el mensaje, luego lo EMITE, se TRANSMITE por el canal y se RECIBE por el receptor, que lo INTERPRETA para procesarlo. Muchísimas veces el mensaje que el emisor imagina no coincide (en muchos casos ni se le parece) con el que el receptor interpreta. Y esto es algo tan obvio que es obviado, aun cuando sabemos que los problemas de comunicación son unos de los factores de fracaso más frecuentes en los proyectos. Vamos a esbozar el proceso comunicativo para tener en cuenta las claves necesarias para reducir la probabilidad de malentendidos en las comunicaciones de nuestros proyectos. A todos nos enseñaron en la escuela que el proceso de comunicación existe un emisor, un receptor y un canal.

Figura 7.1: Esquema de Comunicación

En primer lugar, vamos a poner el foco en el canal y luego en dos operaciones básicas que podemos hacer sobre él. 7.2.1 El Canal y su Ancho de Banda El ancho de banda hace referencia a la cantidad de información que podemos transmitir sobre el canal. En función del canal que utilicemos, tendremos un ancho de banda u otro.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 138 de 141

No es lo mismo comunicar algo por carta que hacerlo en persona. Generalmente, aumentando el ancho de banda del canal disminuimos la probabilidad de que existan malentendidos y se ahorra mucho esfuerzo y tiempo para lograr la efectividad en la comunicación. De este modo, de una comunicación por carta, escrita y asíncrona, podemos ir subiendo el ancho de banda, pasando por el email, el chat, el teléfono, la videoconferencia, el cara a cara. A nuestro juicio, el mayor ancho de banda que se puede lograr en las comunicaciones entre las personas es cara a cara con elementos visuales, porque se aúna el lenguaje verbal, gestual con el escrito y con el figurativo. Es por eso que en los ambientes ágiles son tan importantes las reuniones y los elementos de gestión visual, porque siempre se intenta procurar las mejores condiciones para la comunicación, de modo que sea lo más efectiva posible. 7.2.2 Comprender Para comprender hace falta llevar a cabo correctamente una actividad para la que la mayoría de las personas apenas hemos sido entrenadas: escuchar. Hablamos de escuchar de verdad, no sólo de poner la oreja. Hablamos de la escucha empática. El ser humano trabaja con patrones a la hora de percibir la realidad. Y esto es una gran ventaja en muchas situaciones. Si vemos por primera vez un objeto con cuatro patas, asiento y respaldo, no nos hace falta haber visto antes ese modelo para saber que es una silla. Esta asombrosa habilidad nos permite procesar una gran cantidad de información al instante para poder tomar decisiones (como por ejemplo, reconocer el peligro para oír o enfrentarse a él). Sólo tenemos que fijarnos de forma inconsciente en una serie de claves, y en base a nuestra experiencia anterior reconocemos el objeto o la circunstancia. La escucha empática es tan difícil porque supone deshacernos conscientemente de esta gran habilidad de reconocimiento de patrones para comprender realmente el mensaje que otra persona nos transmite como si estuviéramos en el pellejo de esa persona (de ahí lo de empática). Covey (1989) señala cuatro trampas en las que todos solemos caer en nuestros procesos de escucha: 

Interpretación: esta es la primera de ellas. Imaginemos que una amigo nos cuenta que ha tenido problemas con su jefe y le contestamos: “ah, ya, no me digas más, yo también he pasado por

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 139 de 141



eso”. Hemos cortado la comunicación, no hemos hecho más esfuerzo por comprender realmente qué le pasó. Sólo oímos que ha tenido problemas con su jefe, esta información la pasamos por el filtro de nuestra experiencia y nuestra mente completa la historia. Sondeo: se produce cuando hacemos preguntas a nuestro interlocutor no para conocer realmente los detalles de su historia, sino para confirmar la película que hemos interpretado en nuestra mente. Consejo: como tenemos claro nuestra película, nos permitimos dale a la otra persona consejo sobre cómo debería actuar en base a nuestra experiencia (sin conocer realmente el problema). Esto es como prescribir una receta antes de diagnosticar la enfermedad. Evaluación: por supuesto, nos tomamos la licencia de asentir o disentir lo que dice o hace sin haberlo comprendido realmente.

El Director del Proyecto, como facilitador tiene que poner todo su esfuerzo para hacer que cada uno de los miembros de su equipo sepa escuchar. Esto evitará retrabajo, malentendidos, conflictos, impedimentos y energías desaprovechadas. 7.2.3 Ser Comprendidos Covey (1989) cita la filosofía griega para explicar cómo procurar ser comprendido, con tres conceptos secuenciales:   

Ethos: credibilidad personal, confianza que inspiramos. Pathos: empatía, el lado emocional. Logos: lógica, argumentos, parte racional.

Lo cierto es que nos enseñan a elaborar buenos argumentos en nuestras exposiciones para convencer a nuestra audiencia. Pero cada vez más los líderes empresariales trabajan los otros dos aspectos que son la base para influir en otras personas.

Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

Pág. 140 de 141

Tratado para la Dirección y Gestión Ágil de Proyectos, en entornos de alta incertidumbre Base de conocimientos para certificaciones SMA, SMP y SMT

las

Versión 3.2 Tratado para la Dirección y Gestión Ágil de Proyectos… Versión 3.2

1-6-2011 Pág. 141 de 141