tratado para la dirección y gestión agil de proyectos, en entornos de alta incertidumbre

Tratado para la Dirección y Gestión Ágil de Proyectos, en entornos de alta incertidumbre Base de conocimientos para las

certificaciones SMA, SMP y SMT

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… Pág. 1 de 141

Versión 3.2

SMPartners®, todos los derechos reservados.


Versión 3.2

Í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


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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


Versión 3.2

Í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


Versión 3.2

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.


Versión 3.2

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

http://www.scrummanagementpartners.org/


Versión 3.2

Capítulo 1

INTRODUCCIÓN


Versión 3.2

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.


Versión 3.2

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ú.


Versión 3.2

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:


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.”


Versión 3.2

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


Versión 3.2

complejidad, factor que hemos analizado anteriormente y que da sentido al

presente tratado.


Versión 3.2

Capítulo 2

CULTURA ORGANIZACIONAL


Versión 3.2

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.

Funcional

Matricial

Débil

Matricial

Equilibrada

Matricial

Fuerte

Orientada

a

Proyectos

Autoridad del

Director del

Proyecto

Poca o

Ninguna Limitada

Baja a

Moderada

Moderada a

Alta

Alta a Casi

Total

Disponibilidad

de recursos

Poca o

Ninguna Limitada

Baja a

Moderada

Moderada a

Alta

Alta a Casi

Total

Quién controla

el Presupuesto

del Proyecto

Gerente

Funcional

Gerente

Funcional Mixta

Director del

Proyecto

Director del

Proyecto

Dedicación del

Director del

Proyecto

Parcial Parcial Completa Completa Completa

Dedicación del

Personal

Administrativo

de la Dirección

de Proyectos

Parcial Parcial Parcial Completa Completa

Figura 2.1 Características de Estructuras de las Organizaciones


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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 de la cultura de mercado son:


Versión 3.2

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.


Versión 3.2

2.3 La gestión del cambio y de la transición

2.3.1 El cambio como evolución | El cambio como

revolución

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.

Figura 2.3: Pirámide de Maslow

•creatividad

•aceptación de hechos

• resolución de problemas

Autorrealización

•autorreconocimiento

•confianza

• respeto

•éxito

Reconocimiento

•amistad

•afecto

• intimidad sexual

Afiliación

• física

•de empleo

•de recursos

Seguridad

• respiración

•alimentación

•descanso

Fisiología


Versión 3.2

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


Versión 3.2

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 co-

responsabilidad 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.


Versión 3.2

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

Mejora

económica a corto plazo

Mejora de las

capacidades de la

organización

Enfoque combinado

Objetivos

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

Liderazgo 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


Versión 3.2

Enfoque/concentración Centrado en la estructura y

sistemas

Cultiva la cultura

organizacional

Focalizar de

manera simultánea en

ambos

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


Versión 3.2

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.


Versión 3.2

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,


Versión 3.2

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


Versión 3.2

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:

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

Figura 2.5: Matriz liderazgo / dirección

0

0 ++


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

Capítulo 3

LA PLANIFICACIÓN Y SUS PERSPECTIVAS


Versión 3.2

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”.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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,


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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 Adicionales de Planificación de

Calidad

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


Versión 3.2

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.


Versión 3.2

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?


Versión 3.2

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 de Probabilidad e Impacto de los

Riesgos

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


Versión 3.2

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.


Versión 3.2

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 de la Calidad de los Datos sobre

Riesgos

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

Capítulo 4

ORGANIZANDO EL HORIZONTE


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

4.1.5 Los Roles (Director del Proyecto, Gestor de

Expectativas y Gestor de la Ejecución)

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:


Versión 3.2

• 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


Versión 3.2

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 de recopilación de requisitos

• Reunión de planificación inicial

• Reunión de planificación de fase

• Reunión diaria de sincronización

• Reunión de revisión del entregable

• Reunión 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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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 Objetivos

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 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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

Capítulo 5

EJECUTANDO LA PLANIFICACIÓN


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

5.4.1.1 Objetivos

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 Duración

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

horas cada una.


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.


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.


Versión 3.2

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.


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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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 Participantes

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 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


Versión 3.2

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.


Versión 3.2

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.

o 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


Versión 3.2

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 cronograma | Seguimiento del

desempeño

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


Versión 3.2

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.


Versión 3.2

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 Objetivos

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.


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.


Versión 3.2


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.


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


Versión 3.2

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 Objetivos

Mejorar el proyecto consiguiendo el máximo impacto de mejora con

el mínimo esfuerzo.

5.8.3.2 Duración

Típicamente, 3 horas.


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.


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.


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


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

Capítulo 6

CIERRE DEL PROYECTO


Versión 3.2

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.


Versión 3.2

Capítulo 7

COMPLEMENTANDO EL CONOCIMIENTO


Versión 3.2

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)?


Versión 3.2

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.


Versión 3.2

7.1.3.3 Riesgo limitado para el cliente: “Tiempo y coste

cerrados”

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 limitado y compartido: “Tiempo cerrado

progresivo”

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


Versión 3.2

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.


Versión 3.2

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.


Versión 3.2

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


Versión 3.2

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.


Versión 3.2

Tratado para la Dirección y Gestión Ágil de Proyectos, en entornos de alta incertidumbre Base de conocimientos para las

certificaciones SMA, SMP y SMT

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 agil de proyectos, en entornos de alta incertidumbre

Documents