manual (4)

PROJECT MANAGEMENT PRÁCTICO:Técnicas, herramientas y documentos

Elaborado por:

J. Eduardo Caamaño

Edición: 1.0

No está permitida la reproducción total o parcial de esta obra bajo cualquiera de sus formas gráficaso audiovisuales sin la autorización previa y por escrito de los titulares del depósito legal.

Impreso en España - Printed in Spain

Índice

C1. Introducción a la gestión de proyectos ....................................................... 9

1.1. Las técnicas y las herramientas ..........................................................................................12

1.2. La documentación ............................................................................................................12

1.3. Entradas y salidas .............................................................................................................13

1.4. ¿Qué es un proyecto? .......................................................................................................14

1.5. ¿Por qué los proyectos fallan? ...........................................................................................16

1.6. ¿Qué es el Project Management? ......................................................................................16

1.6.1. Ventajas y factores de éxito del Project Management .............................................17

1.6.2. ¿Cómo se implementa el Project Management en la organización? ........................18

1.7. Los stakeholders del proyecto ...........................................................................................19

1.7.1. Stakeholders internos ...........................................................................................20

1.7.2. Stakeholders externos ..........................................................................................20

1.7.3. La gestión de los interesados ...............................................................................21

C2. Procesos de dirección de proyectos ........................................................ 25

2.1. El ciclo de vida del proyecto ..............................................................................................27

2.1.1. Características del ciclo de vida del proyecto ........................................................28

2.1.2. La triple restricción del proyecto ............................................................................29

2.1.3. Las líneas base de un proyecto ............................................................................31

2.2. Los procesos y fases de un proyecto.................................................................................32

2.2.1. Inicio ....................................................................................................................34

2.2.2. Planificación .........................................................................................................38

2.2.3. Ejecución .............................................................................................................42

2.2.4. Seguimiento y control ...........................................................................................42

2.2.5. Cierre ..................................................................................................................43

4

PROJECT MANAGEMENT PRÁCTICO: Técnicas, herramientas y documentos

2.3. Las actividades del proyecto ..............................................................................................45

2.4. Los entregables del proyecto .............................................................................................45

2.4.1. La lista de entregables del proyecto ......................................................................45

2.5. Caso Práctico ...................................................................................................................46

C3. Áreas de conocimiento ............................................................................ 49

3.1. El Project Manager, ¿nace o se hace? ...............................................................................54

3.2. Las responsabilidades de un Project Manager ....................................................................54

3.3. Las habilidades del Project Manager ..................................................................................54

C4. Dirección de la integración ....................................................................... 57

4.1. Desarrollo del acta de constitución del proyecto (proceso que corresponde a la fase de inicio del proyecto) ............................................................................................................60

4.1.1. Técnicas y herramientas .......................................................................................60

4.2. Desarrollo del plan de proyecto (proceso que corresponde a la fase de planificación del proyecto) .....................................................................................................................61


4.3. Gestión y ejecución del plan de proyecto (proceso que corresponde a la fase de ejecución del proyecto)......................................................................................................62


4.4. Monitorización y control del trabajo del proyecto (proceso que corresponde a la fase de control del proyecto) ..........................................................................................................65


4.5. Control integrado de cambios (proceso que corresponde a la fase de control del proyecto) .65


4.6. Cierre del proyecto o fase (proceso que corresponde a la fase de cierre del proyecto) .........74


C5. Dirección de la integración ....................................................................... 75

5.1. Recopilar requisitos (proceso que corresponde a la fase de planificación del proyecto) ........78


5.2. La definición del alcance (proceso que corresponde a la fase de planificación del proyecto) .83


5.3. Creación de la EDT (proceso que corresponde a la fase de planificación del proyecto) ........86


5.4. Verificación del alcance (proceso que corresponde a la fase de control del proyecto) ...........91


5.5. Control de cambios del alcance (proceso que corresponde a la fase de control del proyecto) 93


5

Índice

C6. Dirección de plazos .................................................................................. 95

6.1. Definición de las actividades (proceso que corresponde a la fase de planificación del proyecto) 100

6.1.1. Técnicas y herramientas .....................................................................................100

6.2. Secuenciación de actividades (proceso que corresponde a la fase de planificación del proyecto) ...................................................................................................................101


6.3. Estimación de los recursos de las actividades (proceso que corresponde a la fase de planificación del proyecto) ................................................................................................113


6.4. Estimación de duración de actividades (proceso que corresponde a la fase de planificación del proyecto) ................................................................................................116


6.5. Desarrollo del cronograma del proyecto (proceso que corresponde a la fase de planificación del proyecto) ................................................................................................122


6.6. Control del cronograma (proceso que corresponde a la fase de control del proyecto) ........131


C7. Dirección de costes ............................................................................... 133

7.1. Estimación de costes (proceso que corresponde a la fase de planificación del proyecto) ...137


7.2. Establecimiento del presupuesto (proceso que corresponde a la fase de planificación del proyecto) ...................................................................................................................141


7.3. Control de costes (proceso que corresponde a la fase de control del proyecto) .................141


C8. Dirección de calidad ............................................................................... 151

8.1. Planificación de la calidad (proceso que corresponde a la fase de planificación del proyecto) 155


8.2. Aseguramiento de la calidad (proceso que corresponde a la fase de ejecución del proyecto) 163


8.3. Control de calidad (proceso que corresponde a la fase de control del proyecto) ................165


C9. Dirección de RRHH ................................................................................ 187

9.1. Desarrollo de los recursos humanos (proceso que corresponde a la fase de planificación del proyecto) ................................................................................................191


9.2. Adquisición de personal (proceso que corresponde a la fase de ejecución del proyecto) ...195


6


9.3. Desarrollo del equipo (proceso que corresponde a la fase de ejecución del proyecto) ........198


9.4. Gestión del equipo (proceso que corresponde a la fase de ejecución del proyecto) ...........202


C10. Dirección de RRHH ................................................................................ 207

10.1. Identificación de los interesados (proceso que corresponde a la fase de inicio del proyecto) 217


10.2. Planificación de las comunicaciones (proceso que corresponde a la fase de planificación del proyecto) ................................................................................................217


10.3. Distribución de la información (proceso que corresponde a la fase de ejecución del proyecto) 221


10.4. Gestión de las expectativas de los interesados (proceso que corresponde a la fase de ejecución del proyecto)....................................................................................................222


10.5. Informes de rendimiento (proceso que corresponde a la fase de control del proyecto) .......223


C11. Dirección de riesgos ............................................................................... 225

11.1. Planificación de la dirección de riesgos (proceso que corresponde a la fase de planificación del proyecto) ................................................................................................233


11.2. Identificación de riesgos (proceso que corresponde a la fase de planificación del proyecto) 233


11.3. Análisis cualitativo de riesgos (proceso que corresponde a la fase de planificación del proyecto) ..................................................................................................................245


11.4. Análisis cuantitativo de riesgos (proceso que corresponde a la fase de planificación del proyecto) ...................................................................................................................252


11.5. Plan de respuesta al riesgo (proceso que corresponde a la fase de planificación del proyecto) 259


11.6. Supervisión y control de riesgos (proceso que corresponde a la fase de control del proyecto) 264


7

Índice

C12. Dirección de compras ............................................................................ 267

12.1. Plan de compras y contratos (proceso que corresponde a la fase de planificación del proyecto) ..................................................................................................................270


12.2. Conducción de compras (proceso que corresponde a la fase de ejecución del proyecto) ..272

12.2.1. Ciclo de compras ...............................................................................................272

12.3. Administración del contrato (proceso que corresponde a la fase de control del proyecto) ...276


12.4. Cierre del contrato (proceso que corresponde a la fase de cierre del proyecto) ..................278


Bibliografía ...................................................................................................... 281

8


C1Introducción a la gestión de proyectos

C1Introducción a la gestión de proyectos

10


1.1. Las técnicas y las herramientas1.2. La documentación1.3. Entradas y salidas1.4. ¿Qué es un proyecto?1.5. ¿Por qué los proyectos fallan?1.6. ¿Qué es el Project Management?

1.6.1. Ventajas y factores de éxito del Project Management1.6.2. ¿Cómo se implementa el Project Management en la organización?

1.7. Los stakeholders del proyecto1.7.1. Stakeholders internos1.7.2. Stakeholders externos1.7.3. La gestión de los interesados

11

Eric Verzuh, en su libro The Fast Forward MBA in Project Management, hace una mención a un texto bíblico que podemos, de alguna forma, relacionarlo con el Project Management. En el Libro de Lucas, capítulo 14 (28-30), se encuentra el siguiente texto:

“Porque ¿quién de vosotros, queriendo edificar una torre, no se sienta primero y calcula los gas-tos, a ver si tiene lo que necesita para acabarla? No sea que después de que haya puesto el cimiento, y no pueda acabarla, todos los que lo vean comiencen a hacer burla de él, diciendo: «Este hombre comenzó a edificar y no pudo acabar»”.

Este pasaje bíblico nos demuestra que en aquella época ya había inquietudes muy similares a las que afrontamos hoy en día. Desde tiempos muy remotos, algunas tribus se reunían para construir abrigos y cultivar la tierra, labores que, aunque primitivas, exigían un mínimo de planificación. Desde hace más de cinco mil años, el hombre construye templos monumentales como las pirámides del antiguo Egipto, la gran muralla China o los acueductos romanos, emprendimientos que seguramente contaban con la coordinación de alguna figura muy similar al Project Manager de nuestros días. Es casi seguro que Imhotep, el primer arquitecto conocido en la historia, responsable de la construc-ción de la primera gran pirámide, la “pirámide escalonada de Saqqara”, sufrió los problemas típicos de un Project Manager moderno: la pirámide necesitó la extracción, acarreo y montaje de miles de toneladas de piedra; desafío notable, ya que nunca se había usado anteriormente en grandes cons-trucciones. Tuvo que organizar todo el proceso de construcción, controlando el trabajo y a cientos de obreros, y muy probablemente tuvo problemas de plazos y recursos, sin contar la presión ejercida por su patrocinador, el faraón Necherjet.

Fue a partir del siglo XX cuando el Project Management empezó a definir los estándares que cono-cemos actualmente, principalmente a partir de la década de los 50, durante la guerra fría, donde se desarrollaron proyectos militares de gran complejidad, como fueron los espaciales y de defensa. El proyecto Manhattan, que culminó en la fabricación de la primera bomba atómica de la historia, es re-conocido como el primer proyecto que utiliza técnicas modernas de Project Management. En aquella época, se evidenció la necesidad de coordinar los equipos y las disciplinas diferentes que trabajaban de forma simultánea en un mismo proyecto que requerían el trabajo concurrente y sincronizado.

Bernard Schriever, un general de la fuerza aérea estadounidense que se encargó, durante los años 50 y 60, de competir y ganar la batalla a la Unión Soviética en la construcción de misiles de medio y largo alcance, y de trasladar al espacio la carrera armamentística entre las dos superpotencias, es consi-derado como uno de los padres del Project Management actual, por haber desarrollado durante la guerra fría el concepto de concurrencia, integrando todos los elementos del plan de desarrollo en un solo programa y presupuesto, ejecutándolos y controlándolos en paralelo y no secuencialmente. De esta forma, logró reducir considerablemente los tiempos de ejecución de los proyectos militares que eran realizados en aquel entonces, como era el proyecto Thor (sistema de armas ideado para disparar proyectiles cinéticos desde la órbita terrestre para dañar objetivos en el suelo).

12


Con el tiempo, estas técnicas y herramientas fueron siendo mejoradas y aplicadas de acuerdo con el tipo de proyecto desarrollado y con cada estructura organizacional. Siguiendo los pasos de la indus-tria militar, la industria automovilística comenzó a aplicar las técnicas del Project Management, con el objetivo de coordinar equipos funcionales diferentes.

Comenzaron entonces a surgir las técnicas que conocemos actualmente, como la descomposición de tareas (EDT – Estructura Detallada de Trabajo), los cronogramas y los histogramas. La propia tec-nología naturalmente fue colaborando en la optimización y el uso apropiado del Project Management mediante programas informáticos que realizan cálculos y simulaciones y que gestionan una cantidad ingente de documentos de un proyecto.

Actualmente, el Project Management ha emergido como una metodología de administración esencial para la organización, sobre todo en las empresas cuyas políticas se enfocan a la planificación y el control de sus actividades. Prácticamente, todos los objetos que forman parte de nuestro día a día, como los móviles, ordenadores, coches, entre otros, son diseñados y desarrollados bajo las técnicas del Project Management. Los proyectos, además, forman parte de nuestro cotidiano. Es un esfuerzo que tenemos que invertir para generar un resultado que puede ser tanto profesional como personal.

Infelizmente, las estadísticas muestran que la gran mayoría de los proyectos termina después del plazo definido, consumiendo mucho más que los presupuestos adjudicados y, en muchos casos, aportan-do una calidad inferior a la deseada. Algunos proyectos ni siquiera llegan a su fin, son simplemente abandonados porque no llegaban a ningún sitio.

Es por estas y otras razones por lo que, desde los egipcios hasta la actualidad, ha sido necesario de-sarrollar, de alguna manera, una metodología que pudiese integrar todas las necesidades de un em-prendimiento, sea cual fuese, de forma que los objetivos pudiesen ser alcanzados satisfactoriamente.

1.1. Las técnicas y las herramientas

La palabra técnica tiene origen del griego τέχνη, y es un conjunto de conocimientos prácticos utili-zados para obtener un resultado concreto, en el campo del arte, de la ciencia, de la tecnología o en cualquier otra actividad. El dominio de una determinada técnica requiere una destreza que puede ser manual o intelectual y que, generalmente, depende de la utilización de herramientas.

La herramienta, por su parte, es definida por la Real Academia Española como “instrumento, por lo común de hierro o acero, con que trabajan los artesanos”. El origen de la herramienta está íntima-mente ligado al origen de la humanidad. Una de las primeras herramientas utilizadas por el hombre fue el mazo, que fue evolucionado a través del tiempo, hasta convertirse en el martillo, tal y como lo conocemos a día de hoy. Han pasado los siglos, el hombre ha evolucionado y, con él, también han evolucionado las herramientas. Ambas, tanto las técnicas como las herramientas, fueron las responsa-bles, mediante el conocimiento del hombre, de las grandes hazañas de la humanidad, desde la cons-trucción de los primeros hogares de la antigüedad, hasta la llegada del hombre a la luna, en 1969.

1.2. La documentación

Uno de los factores de éxito de un proyecto es el desarrollo de una documentación completa y bien estructurada, desde la fase inicial hasta su cierre. La documentación es crítica para todo el equipo que desarrolla el proyecto y fundamental para el cliente. Además, una vez finalizado el proyecto, su docu-mentación será una valiosa fuente de consulta, de donde se podrá extraer informaciones importantes, como las previsiones realizadas a determinadas actividades, planes, estimaciones, etcétera.

13

C1

Son muchos los documentos que forman parte de un proyecto y cada uno tiene su importancia, acor-de con el momento que es aplicado. Juntos constituyen una herramienta poderosa, que dará respaldo a todas las acciones realizadas por el Project Manager y su equipo, y se convertirá en una importante base histórica de consulta para futuros proyectos similares. La documentación también sirve para:

– Referencia para futuros cambios: Aunque el proyecto esté completo y entregado, el cliente podrá solicitar en el futuro un upgrade del proyecto original, añadiendo nuevas funciones o me-joras que, en su momento, no existían. Son casos que suelen ocurrir, por ejemplo, en proyectos tecnológicos. La documentación podrá, por lo tanto, servir como base para la planificación de un nuevo proyecto.

– Datos históricos para estimaciones de plazos y costes: Proyectos completados con éxito son una excelente fuente de información para proyectos futuros siempre que su documentación esté completa y haya sido desarrollada adecuadamente. La estimación de costes y plazos, por ejem-plo, no suele ser una tarea sencilla, y la posibilidad de poder acceder a estimaciones anteriores podrá ser de gran valor para realizar nuevas estimaciones más realistas.

– Apoyo al Project Managers novatos: La carrera del Project Manager es fundamentada a base de mucho estudio. Un Project Manager es un profesional que se dedica al desarrollo de muchas áreas de conocimiento y la documentación de un proyecto siempre será una excelente fuente de estudio. ¿Cómo se ha desarrollado la EDT de un determinado proyecto? ¿Cómo se llegó a esta decisión? ¿Por qué ha sido necesario realizar un cambio tan significativo en una fase tan avanzada? Estas, entre otras cuestiones que se encuentren correctamente registradas en la do-cumentación de un proyecto, serán muy útiles a las nuevas generaciones del Project Managers.

– Apoyo al equipo del proyecto: Como referencia, la documentación del proyecto podrá ayudar al equipo ejecutor a lidiar con situaciones inesperadas. Un problema similar puede haber ocurrido en algún proyecto anterior y su documentación podrá aportar aclaraciones importantes.

– Referencia para evaluaciones: En muchas organizaciones, se utiliza la documentación para evaluar la performance del Project Manager y de su equipo en proyectos similares.

1.3. Entradas y salidas

El PMBOK® basa su metodología de gestión de procesos en entradas, herramientas y salidas. Po-demos imaginar cada proceso como si se tratara de una máquina que recoge las entradas (la informa-ción recopilada para el proyecto) y la transforma en salidas, a través de herramientas (fórmulas mate-máticas, gráficos, estimaciones...). Las salidas darán el soporte necesario para que el proyecto avan-ce sin incidencias (cronogramas, líneas base, estimaciones, planes de contingencia, análisis de ries-go...). Todos los procesos del Project Management basados en la guía PMBOK® poseen entradas, herramientas y salidas.

Figura 1: Entradas y salidas de un proyecto

14


– Entradas: Toda y cualquier información recopilada en reuniones, datos históricos, entrevistas, entre otros.

– Técnicas y herramientas: Procedimientos y recursos utilizados para procesar las entradas reci-bidas que serán posteriormente transformadas en salidas.

– Salidas: La documentación o los recursos que serán utilizados para dar soporte al Project Ma-nager y a su equipo a lo largo del ciclo de vida del proyecto (planes, cronogramas, estimaciones, presupuestos, manuales...).

1.4. ¿Qué es un proyecto?

Un proyecto es una actividad que puede desarrollarse tanto en el ámbito personal como en el empresarial. Se trata de un intento de lograr un objetivo específico mediante la ejecución de de-terminados trabajos previamente planificados, bajo un estricto seguimiento y control de fases inter-dependientes. Para que un emprendimiento pueda ser considerado un proyecto, debe poseer las siguientes características:

– Ser un emprendimiento temporario: Un proyecto se caracteriza por tener un comienzo y un fin definidos. Aunque ambas fechas puedan cambiar por razones ajenas, llegará el momento en que el proyecto será iniciado y tendrá que tener su fin formalizado. Normalmente, el final se alcanza cuando se ha logrado el objetivo del proyecto y los interesados acepten, formalmente, su finalización.

– Sin embargo, en algunos casos, desgraciadamente muy frecuentes, un proyecto puede ser “for-zado” a terminar cuando su ejecución no alcanza el resultado esperado, o cuando el proyecto empieza a consumir una cantidad de recursos muy superior a la inicialmente establecida, y la inversión realizada deja de ser viable. La duración de un proyecto puede variar desde unos pocos días, como, por ejemplo, la reforma de una cocina, o puede llegar a varios años, como fue el caso del proyecto que llevó el hombre a la luna. Además, todo proyecto debe empezar con alguna documentación inicial, que declara el inicio de su ciclo de vida.

– Tener limitaciones: Los proyectos normalmente cuentan con recursos limitados. Estos pueden ser financieros, de plazo, de personal o de maquinaria. La cantidad de recursos dedicada a un proyecto dependerá, sobre todo, de la capacidad financiera de la organización o de la disponibi-lidad de los recursos dentro de la organización.

– Ser realizado por personas: Y son emprendidos en todos los niveles de una organización. Pue-den ser desarrollados por una única persona o por todo un departamento. Pueden involucrar a una pequeña oficina o pueden cruzar fronteras afectando a decenas de empresas. Normalmente, el equipo formado para realizar un proyecto raramente se mantiene tras su cierre. La mayoría de los proyectos son ejecutados por un equipo creado con el propósito único de acometerlos, y es disuelto cuando se completa el proyecto.

– Ser realizado para crear un producto o servicio único: Llevar a cabo un proyecto conlleva hacer algo que no ha sido hecho antes y que no será hecho otra vez (bajo las mismas condicio-nes) y por esta razón es considerado “único”. Aunque muchos proyectos poseen características muy similares, siempre habrá algún factor que los distinga. Podemos imaginar, por ejemplo, la construcción de una urbanización de diez edificios que tendrán la misma estructura y fachada. La construcción de cada edificio es un proyecto único, aunque todos los edificios sean iguales y estén ubicados sobre el mismo terreno. Eso porque cada edificio podrá ser construido en dife-rentes épocas: uno en el verano, el otro en el invierno; por personal distinto: unos más eficientes y capacitados que otros, y en diferentes condiciones económicas o financieras, lo que obliga a que la construcción de cada edificio necesite de un plan de proyecto específico.

15

C1

– Ser elaborado de forma progresiva: El concepto de elaboración progresiva es la forma por la cual los proyectos son desarrollados bajo los estándares del Project Management. El plan di-señado para el proyecto es ejecutado paso a paso, progresando a través de incrementos y es realizado cuidadosa y detalladamente. Un proyecto es definido en principio de forma muy gené-rica y se van incrementando los detalles a medida que el equipo del proyecto desarrolle mejor el entendimiento del servicio o producto resultante. De esta forma, el plan de proyecto recibirá un flujo constante de información renovada y, sobre todo, más precisa y completa.

– Tener un objetivo definido: Todo proyecto intenta lograr un objetivo final. Para el cliente, lo que realmente importa es que el proyecto diseñado resulte en un producto o servicio cuya calidad cumpla con sus requisitos. Para la empresa ejecutora, el objetivo primario es entregar el proyecto dentro del plazo y presupuesto estimados y que los resultados alcanzados favorezcan su posición en el mercado.

Generalmente, el objetivo de un proyecto se define en función del alcance, tiempo y coste. Como ejemplos de proyectos podemos incluir:

– El desarrollo de un nuevo producto o servicio.

– La realización de una boda.

– El diseño de un nuevo avión.

– La reforma de un local.

– La construcción de un puente.

– La implantación de un nuevo sistema de telefonía.

– La realización de un espectáculo.

– El rodaje de una nueva película.

Todos los proyectos poseen un grado de incertidumbre (o riesgo), que, como se podrá apreciar en el capítulo 11, Dirección de riesgos, pueden ser confrontados, reducidos, transferidos o evitados, todo dependerá de la política de la organización y del estilo de gestión del Project Manager asignado.

Normalmente, el equipo del proyecto realiza una planificación antes de la fase de ejecución del pro-yecto. Esta planificación es preparada en base de ciertos supuestos y estimaciones, como, por ejem-plo, el coste, el tiempo y la disponibilidad de los recursos necesarios para la ejecución del proyecto. Basado en las experiencias de proyectos anteriores se podrá también estimar la probabilidad y el impacto de incidencias que pueden ocurrir durante su ejecución.

Conforme avanza el proyecto, si las actividades programadas son ejecutadas sin grandes incidencias, el grado de incertidumbre suele disminuir, puesto que muchas de las suposiciones iniciales serán reemplazadas por hechos reales. Por ejemplo, una vez que se termina la programación del primer mó-dulo de un programa informático, se podrá estimar mejor la cantidad de tiempo y esfuerzos necesarios para iniciar el siguiente módulo. Sin embargo, aunque el grado de incertidumbre sea menor en fases más avanzadas del proyecto, el nivel de riesgo se verá incrementado, ya que el impacto causado por una incidencia importante repercutirá de forma más contundente.

*Nota del autor: Existe un concepto equivocado de que un proyecto es algo muy complejo y de difícil gestión, y por ello se han desarrollado tantas herramientas, técnicas y documentos. Pero, si nos paramos un momento a pensar, estamos, a veces sin darnos cuenta, planificando y ejecutando una serie de pequeños proyectos todos los días, tan sencillos como salir de compras un sábado por la tarde. Para ello, es necesario planificar la hora en la que pretendemos salir de casa, qué medio de transporte utilizaremos, si llevamos el coche, cuál será el recorrido elegido, si hay gasolina suficiente y dónde aparcaremos. Además, para salir de compras un sábado por la tarde, hay que tener en cuenta un presupuesto orientativo de gastos los posibles riesgos implicados en este sencillo paseo vespertino (lluvia, dificultades de aparcar, atascos...).

16


1.5. ¿Por qué los proyectos fallan?

Un estudio realizado por las empresas Gartner Inc en 2002 nos revela que un proyecto tiene una gran pro-babilidad de no cumplir satisfactoriamente las estimaciones realizadas. Sus resultados acusan lo siguiente:

– El 90% de los proyectos ejecutados son entregados con retraso.

– El 50% son entregados con un presupuesto mayor que el previsto.

– El 50% no cumple sus objetivos.

– El 30% son cancelados antes de su conclusión.

De acuerdo con uno de los autores más conocidos del Project Management, el doctor. J. Davidson Frame, los proyectos fallan mayoritariamente por dos razones: a) fallos de estimaciones, y b) fallos en la implementación. Jason Charvart, autor del libro Project Management Methodologies, nos revela otras de las principales razones de fracaso en los proyectos:

– El coste y los plazos inicialmente estimados no son revisados.

– Los planes no son seguidos correctamente.

– El Project Manager no tiene formación suficiente.

– El alcance del proyecto cambia sin control.

– La metodología aplicada no es la correcta.

– La comunicación es escasa.

– No se realizan suficientes pruebas.

– La teoría del Project Management no es aplicada correctamente.

1.6. ¿Qué es el Project Management?

La situación que describiré a continuación no es exclusiva del Project Management. Infelizmente, ocurre en muchos ámbitos, como el derecho, la economía o, aún peor, en la medicina. Hay mucha gente que piensa que puede gestionar un proyecto comprando un programa o leyendo un par de libros. El Project Manager es una profesión que, aunque todavía no esté totalmente reconocida en España, tiene un peso importantísimo en EEUU y en varios países de Europa. La profesión de Project Manager exige mucha preparación y, sobre todo, experiencia suficiente para aplicar correctamente sus conocimientos y habilidades a las actividades del proyecto para satisfacer sus requisitos. Es un proceso por el cual se planifica, se ejecuta y se controla, buscando alcanzar los resultados deseados. Es un trabajo que normalmente involucra:

– Demandas contrapuestas sobre alcance, tiempo, coste, riesgos y calidad: Como veremos más adelante, un proyecto es un sistema dinámico que tiene que mantenerse constantemente en equilibrio. Gestionar un proyecto es un esfuerzo que conlleva a administrar una serie de ac-tividades integradas. Si una determinada actividad no produce los resultados esperados, podrá afectar a otras áreas del proyecto. Un cambio en el alcance, por ejemplo, casi siempre afectará el coste del proyecto, así como la reducción del plazo de entrega de un producto, y por ello, podrá repercutir negativamente en su calidad.

17

C1

– Interesados con diferentes expectativas y necesidades: Los interesados, según explica la sección 1.7, tienen diferentes intereses en el desarrollo de un proyecto y poseen diferentes ne-cesidades y expectativas. La expectativa de un interesado normalmente es subjetiva y, a veces, difícil de satisfacer, puesto que cada individuo posee diferentes niveles de valor. Por esta razón es importante, desde la fase inicial del proyecto, poner las cosas muy claras a los interesados, definiendo correctamente sus requisitos, de forma que sus expectativas se transformen en nece-sidades identificadas y reales.

– Planificación, control y organización de las actividades que forman parte del proyecto: Es imprescindible que se realice un seguimiento y un control del proyecto durante su ejecución. Suena demasiado obvio, pero son muchas las organizaciones que nunca han hecho un plan y, en algunos casos, hay empresas que poseen la triste mentalidad de que “hacer un plan es un trabajo añadido innecesario”. Por otro lado, no tiene sentido exagerar en la planificación de un proyecto, si este no lo necesita. La planificación tiene que ser siempre proporcional al tamaño y sobre todo a la complejidad del proyecto. Por ejemplo, un proyecto muy pequeño puede nece-sitar tan solamente de una buena planificación hecha en Excel, donde se establezcan las líneas bases mínimas necesarias.

1.6.1. Ventajas y factores de éxito del Project Management

Podemos decir que un proyecto bien sucedido es aquel que ha sido desarrollado dentro de las expectativas de tiempo, coste y calidad. Además, el cliente debe sentirse satisfecho con el trabajo realizado y/o el producto/servicio entregado. Conforme avancemos, nos daremos cuenta de la can-tidad de planificación que implica la puesta en marcha de un proyecto. De hecho, planificar, aunque sea fundamental, no es suficiente para lograr buenos resultados. Para lograr el éxito en los resultados establecidos por la organización, es imprescindible contar también con:

– La información correcta, completa y actualizada para poder planificar, ejecutar y controlar un pro-yecto de forma adecuada.

– La comunicación eficaz, exacta y distribuida a las personas correctas en el tiempo apropiado.

– El compromiso de las personas involucradas para hacer las cosas bien, evitando conflictos y trabajando en sinergia.

Entre los beneficios que nos puede aportar el Project Management podemos destacar:

– Reducción del ciclo de desarrollo.

– Reducción de costes.

– Decisiones más eficaces.

– Menos improvisación.

– Cumplimento de plazos.

– Anticipación de problemas.

– Creación de un producto/servicio de calidad.

– Comunicación eficaz.

18


No obstante, históricamente, los proyectos tienen una tasa de éxito muy baja. Cerca del 25% de los proyectos son concluidos con éxito. Es decir, el 75% de los proyectos no logra alcanzar los objetivos establecidos. No obstante, existen algunas reglas básicas que pueden minimizar el riesgo de que un proyecto sea incluido en esta triste estadística:

– Tener los objetivos claramente definidos: Incluido el compromiso del equipo para alcanzar todas las metas definidas.

– Un proyecto necesita planificación: De la misma manera, es imprescindible que se realice un control del proyecto durante su ejecución.

– Contar con un Project Manager competente: Un profesional que desarrolle esta función debe tener las habilidades inherentes de su puesto, que es el principal responsable del proyecto.

– Apoyo de la dirección: Es muy importante que la dirección de la organización sea consciente de la importancia del proyecto y proporcione todos los medios necesarios para asegurar su buen desarrollo.

– Tener un equipo de proyecto competente: Un proceso de selección bien planificado y la inver-sión en formación son factores clave para un proyecto bien desarrollado ya que su éxito depende de la buena labor del equipo.

– Disponibilidad suficiente de recursos: Si existe un factor que puede arruinar un proyecto es la falta de recursos, sean financieros, de personal o de equipos. Antes de empezar, el Project Manager debe asegurarse de que podrá disponer de los recursos suficientes para desarrollar un proyecto.

– Canales de comunicación adecuados: La información es uno de los factores clave de éxito, que deberá fluir de una forma controlada que alcance a las personas correctas en el momento adecuado.

– Mecanismos de control: Un proyecto no puede sufrir demasiadas desviaciones que modifiquen la estructura del plan original. El Project Manager debe contar con mecanismos e instrumentos que le permitan mantener el proyecto dentro de la línea base establecida.

– Feedback constante: Todos los involucrados en el proyecto deben intercambiar opiniones, su-gerencias, experiencias o cualquier otra información que colabore con el avance del proyecto. Reuniones de seguimiento y elaboración de informes deben formar parte de las actividades ruti-narias del proyecto.

– Respuestas inmediatas al cliente: Es fundamental mantener al cliente siempre informado, aunque no se traten de buenas noticias. El cliente puede ser un gran aliado, pero, al mismo tiempo, puede tornarse un gran escollo. Todo dependerá de la relación que el Project Manager mantenga con él.

– Mecanismos que permitan afrontar los problemas: Todo proyecto necesita de un plan de con-tingencia (descrito en la sección 11.5.1.3) o cualquier otro mecanismo que permita que el equipo reaccione y aplique la respuesta más adecuada.

1.6.2. ¿Cómo se implementa el Project Management en la organización?

– Diseminando en toda la organización sus principios y metodologías: Para poder desarrollar de manera eficaz el Project Management en las empresas, es necesario, principalmente, adoptar una cultura volcada en la gestión integrada de proyectos, involucrando y capacitando sus equi-pos de trabajo y disponiendo de personal cualificado que comprenda y que, ante todo, valore el Project Management.

19

C1

– Desarrollando individuos y formando equipos de proyecto: Trabajar utilizando la metodología del Project Management es, sobre todo, trabajar en equipo. Los individuos involucrados en cada proyecto deben trabajar en sinergia, creando resultados que maximicen las cualidades de cada uno de los recursos asignados al proyecto.

– Implementando normas y procedimientos: Otro factor importante en el Project Management es disponer de herramientas que puedan soportar de forma adecuada las gestiones desarrolladas por el Project Manager. El mercado dispone de una serie de soluciones a las empresas que per-miten aumentar la eficacia de su gestión, integrando los departamentos de la empresa y unifican-do la información. De este modo, se puede obtener, en minutos en lugar de días, la información necesaria para tomar sus decisiones en función de la situación real de un determinado proyecto, principalmente en lo que conlleva a afrontar un determinado grado de riesgo.

1.7. Los stakeholders del proyecto

También conocidos como “interesados”, son individuos y/u organizaciones que están involucradas en el proyecto, tienen intereses en su desarrollo y poseen diferentes necesidades y expectativas. El cliente, el Project Manager, el equipo del proyecto y el patrocinador obviamente pertenecen a este grupo. Sin embargo, cualquiera que se vea afectado positiva o negativamente con los resultados producidos por el proyecto es un potencial interesado. No obstante, los interesados más importantes del proyecto son el cliente, que se convertirá en el usuario del servicio y/o producto generado, y el patrocinador, que es el que invierte recursos financieros al proyecto. Sin ellos, el proyecto difícilmente seguirá adelante.

Los interesados pueden ejercer una fuerte influencia en el proyecto. Por esta razón es fundamental:

– Identificarlos: Cada proyecto está formado por un grupo de interesados distintos, que podrán tener un grado de influencia más importante que en otros. Normalmente, son cinco los interesa-dos clave: el Project Manager, el equipo del proyecto, el patrocinador, la dirección y el cliente. Sin embargo, en algunos proyectos, pueden existir otros interesados importantes, cuya identificación, a veces, no resultará sencilla. La mejor forma de identificar a los interesados de un proyecto es haciéndose la siguiente pregunta: “¿quién contribuye al proyecto?”.

– Definir sus funciones: El Project Manager, por ejemplo, es la persona responsable de realizar un proyecto, coordinando el equipo y trabajando para que los resultados sean los esperados. El equipo del proyecto realiza el trabajo necesario para que se alcancen los objetivos definidos, y la dirección toma algunas decisiones importantes, generalmente en los momentos más críticos. Otro interesado importante es el patrocinador, que es quien invierte recursos financieros al proyec-to y que, a veces, tiene la última palabra acerca de su alcance y de otras variables.

– Identificar su grado de influencia: El grado de influencia de un interesado normalmente está vinculado a su cargo o posición en el proyecto. Dependiendo del cargo que ocupe, su opinión puede tener una repercusión importante en el proyecto, colaborando para su progreso o, incluso, determinando su cierre.

– Determinar sus requisitos: En términos del Project Management, los requisitos son condicio-nes que deben ser satisfechas o que pueden proporcionar a un sistema, servicio o producto, la capacidad de producir un determinado resultado.

*Nota del autor: El Project Management es un tema que se está volviendo muy difundido por su flexibilidad. Los conceptos de “proyecto” y de “Project Management” pueden ser aplicados en cualquier segmento empresarial, en cualquier industria, y pueden incluso ser utilizados en el ámbito personal. Una boda, por ejemplo, puede perfectamente ser considerada como un proyecto. Conlleva la dirección de costes, de plazos, de recursos humanos y, sobre todo, la gestión de un cierto grado de riesgo. Todos los proyectos tienen características conceptuales parecidas. Todas ellas poseen, de alguna forma, una fase inicial, una fase de planificación, control, ejecución y una fase de cierre.

20


– Garantizar su satisfacción: Se suele decir que “el cliente siempre tiene la razón”, pero el Pro-ject Manager tiene un lema distinto: “Lo que realmente importa es cumplir con las expectativas de los interesados”. El Project Manager debe preocuparse por satisfacer a cada interesado del proyecto, y es importante tener claro que los interesados también pueden aportar mucho en tanto que a ellos les interesa que el proyecto se desarrolle correctamente.

Los interesados de un proyecto pueden ser básicamente de dos tipos, internos o externos:

1.7.1. Stakeholders internos

– La dirección: Los directores de la empresa podrán o no estar directamente involucrados en un proyecto. En grandes proyectos de mucha visibilidad, la dirección suele implicarse con más fre-cuencia, lo que incrementa la comunicación con el Project Manager y facilita la adquisición de re-cursos materiales y contratación de personal cualificado. Por otro lado, si el proyecto se desarrolla de forma problemática, sus debilidades estarán muy expuestas, y el soporte inicial de la dirección se volverá en presión que muchas veces será muy perjudicial para el ambiente del proyecto.

– El Project Manager: Resultaría injusto decir que el Project Manager es el principal interesado del proyecto, porque la verdad es que nadie lo es. La puesta en marcha de un proyecto depende de todos los interesados, ya que cada uno realiza su aportación acorde con el papel que ocupa. No obstante, se puede decir que el Project Manager es el interesado más involucrado, puesto que participa directamente de todo el proyecto, desde la fase inicial hasta su cierre.

– La organización ejecutante: Es el ámbito donde un proyecto será desarrollado o por lo menos una parte importante de él. Es la organización ejecutante la que provee los medios materiales, tecnológicos, financieros y de recursos humanos para la puesta en marcha del proyecto.

– Los integrantes del equipo del proyecto: Son los recursos asignados y quienes trabajaran directamente en el desarrollo de los entregables del proyecto. El equipo de proyecto es normal-mente formado por profesionales con diferentes conocimientos, experiencias y habilidades que puedan asegurar la buena ejecución del proyecto.

1.7.2. Stakeholders externos

– El cliente: Es la persona, grupo de personas o empresas que se beneficiarán directamente del producto o servicio desarrollado por la empresa ejecutante. Generalmente, están altamente involucrados en la planificación y ejecución del proyecto y es quien formalmente acepta o no la entrega de cada fase prevista, hasta que se alcance la totalidad del proyecto contratado.

– El gobierno: Muchos proyectos son desarrollados con fondos públicos, a través de concursos y/o licitaciones. Además, en algunos sectores, los proyectos son desarrollados de acuerdo con algunas normativas, como es el caso, por ejemplo, de la industria farmacéutica. El Project Mana-ger tendrá que estar atento a ciertas restricciones impuestas por las normativas que afecten a su proyecto. Los proyectos que son resultantes de una licitación pública normalmente tienen todo su alcance, plazos, presupuestos y procedimientos atados a un concurso público, que deberá ser respetado.

– Los proveedores: Muchos proyectos dependen bastante de los servicios prestados por buenos proveedores, como suele ocurrir, por ejemplo, en los proyectos de construcción: la buena calidad de los materiales (hormigón, ladrillos, parqués...) y de mano de obra (fontaneros, electricistas, en-cofradores...) son esenciales para que el proyecto cumpla con los requisitos mínimos de calidad. La dependencia no se limita solamente en lo que se refiere a la calidad de los productos y/o a los servicios prestados por los proveedores. Una entrega tardía o temprana de los productos contra-tados, o un incremento del coste de la mano de obra, podrá comprometer seriamente el proyecto.

21

C1

– Terceros: A veces, una organización no tiene suficiente personal propio para ejecutar los trabajos previstos. Esta situación suele ocurrir en grandes proyectos, como son los del sector de la cons-trucción y de las telecomunicaciones. En este caso, es común contratar mano de obra externa. El Project Manager deberá conocer todas las cláusulas que forman parte del contrato establecido con empresas externas, para que no existan divergencias que comprometan el desarrollo del proyecto.

– El patrocinador: Todo proyecto tiene un patrocinador. Normalmente, el patrocinador del proyecto es alguien perteneciente a la organización, que identifica la necesidad de poner en marcha un proyecto para lograr un resultado determinado, sea estratégico, financiero o tecnológico. Cuando el proyecto es demandado por un cliente fuera de la organización, el patrocinador ejercerá el rol de interlocutor en-tre el cliente y la empresa ejecutora del proyecto. En resumen, es la persona que apuesta por el pro-yecto y que proveerá el soporte necesario para que su inversión alcance los objetivos determinados.

También podemos incluir en este grupo a los acreedores, sindicatos, prensa, organizaciones no gu-bernamentales o la opinión pública, entre otros.

Lograr una armonía entre los interesados del proyecto es otro factor de éxito importante y un gran desafío para el Project Manager. Lograr esta armonía es posible si el Project Manager es capaz de incentivar la participación de los interesados, creando un ambiente de colaboración. Se trata de una complicada labor, puesto que, normalmente, los interesados tienen objetivos diferentes que pueden entrar en conflicto. Por ejemplo:

– El director técnico solicita un cambio en el alcance del proyecto que puede comprometer las fe-chas planificadas por el equipo técnico para la finalización de alguna fase.

– El proyecto puede ser afectado por alguna ley que sea aprobada durante su desarrollo.

– Un integrante clave del equipo técnico puede dejar la empresa.

– El cliente puede solicitar un cambio importante en alguno componente del proyecto que compro-meta toda la planificación realizada.

La participación de los interesados del proyecto debe ser siempre positiva, añadiendo conocimiento y valor al proyecto. Uno de los grandes desafíos del Project Manager es resolver los conflictos que se produzcan durante el proyecto, encontrando la solución apropiada.

1.7.3. La gestión de los interesados

Es notoria la fuerte influencia que los interesados ejercen sobre un proyecto, ya que algunos de ellos tienen en su poder el control de muchos recursos de la organización, y, por esta razón, el Project Manager deberá ser capaz de administrar eficazmente sus relaciones. Como figuras importantes que son, y además con intereses conflictivos (aunque casi todos desean que el proyecto termine exitosamente), se hace necesario identificar sus expectativas y desarrollar una gestión que permita mantenerlos de nuestro lado, como verdaderos aliados del proyecto, puesto que, en algunos casos, cualquier interesado puede echarlo todo a perder.

Su gestión conlleva seguir los siguientes pasos:

– Identificar quiénes son.

– Identificar su papel.

– Identificar el impacto que el proyecto tendrá para los diferentes interesados.

– Valorar su influencia en el proyecto.

– Identificar las relaciones entre los interesados y sus objetivos en común.

22


Una gestión eficaz de los interesados traerá beneficios al proyecto, por ejemplo:

– Facilitará la toma de decisiones.

– Mejorará la fluidez de la información y de la comunicación.

– Incrementará el nivel de satisfacción.

– Aportará estabilidad al proyecto.

Su adecuada gestión podrá realizarse con el auxilio de la primera herramienta de esta obra, presen-tada a continuación.

1.7.3.1. Técnicas y herramientas

1.7.3.1.1. Matriz poder/interés (Power/interest matrix)

Como he dicho anteriormente, existen interesados que controlan los recursos críticos de la organiza-ción, así como hay interesados que, incluso, pueden llegar a influenciar directamente en la estabilidad emocional del Project Manager (por ejemplo, la familia). Cada interesado es dotado de un determina-do grado de influencia y poder sobre un proyecto. Este grado es medido por la capacidad que cada uno tiene de ejercer una presión sobre otros.

La tabla que hay a continuación, llamada de matriz poder/interés y desarrollada por Gerry Johnson y Kevan Scholes, clasifica a los distintos interesados en función de su poder y grado de interés que pueden mostrar en un determinado proyecto. Esta matriz nos puede ayudar a establecer la relación que se debe mantener con cada uno de los interesados.

Nivel de interés

Bajo Alto

Poder

Bajo(A)

Trabajadores Asoc. Empresariales

(B) Sociedad

Alto(C)

Gobierno Proveedores

(D) Socios Cliente

Figura 2: Matriz interés/poder

Como se podrá apreciar en el ejemplo, los interesados del grupo “D” son los que más presión pueden ejercer sobre los demás y, por ello, se hace necesario desarrollar estrategias de negociación y toma de decisiones que nos permitan tener a este grupo involucrado de forma positiva en el proyecto.

Por otro lado, el grupo “C” tiene el poder directo de parar de ejecutar sus labores o dejar de su-ministrar algún producto o servicio necesario para el buen desarrollo del proyecto. Por esta razón, se puede considerar que la organización debe conocer el nivel exacto de interés que muestran los interesados de este grupo, para asegurar una negociación eficaz en el caso de que surja algún tipo de conflicto.

23

C1

1.7.3.1.2. Diagrama de Venn (Venn´s diagram)

El diagrama de Venn recibe este nombre de su creador, John Venn, matemático y filósofo británico. Estos diagramas son normalmente utilizados en las matemáticas, y son conocidos como “teoría de conjuntos”: diagramas utilizados para ilustrar la relación entre conjuntos, representados por círculos. La forma en que estos círculos se sobreponen entre sí muestra las posibles relaciones lógicas entre los conjuntos que representan. En este caso, utilizaremos este diagrama para representar las relacio-nes entre los interesados del proyecto:

Figura 3: Diagrama de Venn

Cada conjunto ilustrado en este diagrama representa a un interesado del proyecto. El área donde los círculos se superponen representa el objetivo en común que tienen los interesados que se relacionan directamente. Aunque en casi todos los casos, todos los interesados tienen objetivos en común, mu-chas veces, durante el desarrollo del proyecto; algunos de estos interesados pueden tener objetivos específicos, muchas veces determinados por la relación directa que mantienen. En el diagrama, el patrocinador no tiene una relación directa con el cliente; sin embargo, tiene objetivos en común con la gerencia y con el Project Manager.

1.7.3.1.3. Matriz de los interesados (Stakeholder´S matrix)

La matriz de los interesados es muy similar a la matriz de responsabilidades (descrita en la sección 9.1.1.3) y sirve para determinar la relación entre los interesados y sus funciones en cada fase del pro-yecto. La naturaleza y el alcance de cada fase asignarán la función de cada interesado.

Participante Opinión requerida Revisión requerida Responsable

Inicio PM, EP, GE CL CL GE

Planificación PM, EP EX PM PM

Ejecución PM, EP EX PM PM, EP

Control PM, EP CL PM PM

Cierre PM, EP EX CL PM, EP

CL: Cliente, PM: Project Manager, EP: Equipo del Proyecto, GE: Gerencia, EX: Experto

Figura 4: Matriz de participación de los principales interesados

CLIENTE

EQUIPO

PROVEEDOR

PROJECT MANAGER

PATROCINADOR

GERENCIA

24


C2Procesos de dirección de proyectos

26


2.1. El ciclo de vida del proyecto2.1.1. Características del ciclo de vida del proyecto2.1.2. La triple restricción del proyecto2.1.3. Las líneas base de un proyecto

2.2. Los procesos y fases de un proyecto2.2.1. Inicio2.2.2. Planificación2.2.3. Ejecución2.2.4. Seguimiento y control2.2.5. Cierre

2.3. Las actividades del proyecto2.4. Los entregables del proyecto

2.4.1. La lista de entregables del proyecto2.5. Caso Práctico

27

Todos los proyectos tienen un fin vinculado a la obtención de un resultado, que puede ser un producto o un servicio, generado a través de la ejecución de una serie de actividades previamente planificadas. Algunas de estas actividades se agrupan en fases para facilitar su gestión. Al conjunto de estas fases se le denomina “ciclo de vida”.

El ciclo de vida de un proyecto contiene cuatro elementos básicos que serán profundizados a continuación:

– Fases.

– Actividades.

– Entregables.

– Procesos.

2.1. El ciclo de vida del proyecto

Como he comentado anteriormente, los proyectos son un emprendimiento único que conlleva un cierto grado de incertidumbre y riesgo. Por esta razón, normalmente, un proyecto es dividido en fases puntuales para tornar su control más efectivo. A este conjunto de fases le llamaremos, tal y como he dicho antes, “ciclo de vida del proyecto”.

El ciclo de vida representa el progreso lineal de un proyecto, desde la fase inicial hasta su cierre, como ilustra la figura 5:

Figura 5: Estructura de la gestión de proyectos

Implementación

Pruebas

Desarrollo

Proyecto Técnico

Definiciones

Requisitos

GESTION DEPROYECTOS

Inicio

Planificación

Cierre

Control

Ejecución

IntegraciónAlcance

TiempoCalidad

Coste

Comunicación

Recursos Humanos

Ciclo de Vida delProyecto

Procesos de Gestión

Responsabilidades

28


2.1.1. Características del ciclo de vida del proyecto

El ciclo de vida también define el comienzo y el fin de un proyecto. Además, determina las acciones posteriores a su conclusión, es decir, que es útil para vincular el proyecto con las operaciones conti-nuas de la organización.

Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy detalladas. Cuanto más detalladas, mejor estructuradas estarán documentalmente, proporcionando al proyecto una im-portante base documental donde se guardaran los trabajos realizados y sus resultados.

Figura 6: Influencias durante los procesos de un proyecto

Normalmente, el ciclo de vida de un proyecto posee las siguientes características:

– El coste y el personal involucrado son bajos al comienzo, aumentan según avanza el proyecto y caen súbitamente cuando el proyecto se aproxima de su cierre.

– Cuando un proyecto se encuentra en su fase inicial, la probabilidad en completarlo con éxito es muy baja y, por lo tanto, el riesgo y la incertidumbre son altos. Conforme el proyecto avanza, la probabilidad de terminar con éxito aumenta progresivamente.

– Los interesados en el proyecto ejercen mucha influencia en el comienzo del proyecto. Su poder de influencia disminuye progresivamente a medida que el proyecto avanza.

Aunque muchos ciclos de vida contengan elementos y fases similares, pocos son idénticos. Algunos proyectos presentan cuatro o cinco fases, otros pueden llegar a presentar más de diez fases. Todo dependerá del sector empresarial donde el proyecto es desarrollado, la forma en que la organización ejecuta sus proyectos o cómo serán las características del producto o servicio que será entregado. Sin embargo, todos los ciclos de vida tienen una cosa en común: todos tienen una fase inicial, una fase final y, por lo menos, una fase intermediaria.

Costes y Recursos HumanosRiesgosInfluencia de los interesados

INICIACIÓN PLANIFICACIÓN EJECUCIÓN / CONTROL CIERRE

29

C2

Una fase es concluida cuando se terminan los trabajos necesarios para llevar a cabo la obtención de uno o más entregables. Un entregable es el producto o servicio resultante del trabajo realizado durante una determina fase, como, por ejemplo, la colocación del pavimento en una obra es el resultado de una de las fases de construcción de un edificio.

Cuando se finaliza una fase, es recomendable revisar todo el trabajo realizado y evaluar los resultados obtenidos, sobre todo en lo que se refiere al cumplimiento del plazo y el uso de los recursos finan-cieros y humanos. Esta evaluación será útil para asegurar el buen rendimiento en la siguiente fase de ejecución del proyecto. Normalmente, los entregables de la fase precedente son aprobados antes del comienzo de la siguiente. Existen proyectos en los que las fases se superponen, es decir, que una fase puede iniciar antes de que termine la precedente. De todas formas, la evaluación general del proyecto entre sus fases o en los periodos de transición es importante para su buen desarrollo.

Dividir un proyecto por fases conlleva los siguientes beneficios:

– Permiten controlar mejor el avance de todo el proyecto.

– Disminuye su complejidad.

– Reducen la incertidumbre y el nivel de riesgo.

2.1.2. La triple restricción del proyecto

Un proyecto es un sistema dinámico que tiene que mantenerse constantemente en equilibrio. Gestio-nar un proyecto es un esfuerzo que conlleva administrar una serie de actividades integradas. Si una determinada actividad no produce los resultados esperados, podrá afectar a otras áreas del proyecto. El cambio del alcance casi siempre afectará el coste del proyecto, así como la reducción del plazo de entrega de un producto, podrá repercutir negativamente en su calidad.

El Project Management busca resolver estas interacciones de forma activa. En esta materia se men-ciona con mucha frecuencia la triple restricción del proyecto (Project Triple Constraint), que represen-ta la interacción entre el alcance, el plazo y el coste en la forma de un triángulo:

Figura 7: La triple restricción del proyecto

– Alcance: El término “alcance” representa el trabajo necesario para producir exactamente los requi-sitos establecidos por el cliente. En el desarrollo del proyecto es muy probable que el cliente solicite alguna modificación en relación al alcance original, lo que, normalmente, se traduce en añadirle más requisitos, que podrán provocar un incremento en los costes y en los plazos de entrega del proyecto.

30


– Tiempo: Es la duración prevista para completar el proyecto. De acuerdo con un estudio rea-lizado por las empresas Gartner Inc, el 90% de los proyectos ejecutados son entregados con retraso, lo que nos lleva a pensar que el plazo es una variable muy difícil de estimar y extrema-damente complicada de cumplir, por ello se hace necesario dedicar un tiempo importante de planificación y control.

– Coste: El 50% de los proyectos son entregados con un presupuesto mayor que el previsto, se-gún el mismo estudio realizado por las empresas Gartner. Esto ocurre normalmente porque no se ha tenido en cuenta una serie de costes internos, externos, fijos y variables que un proyecto puede contemplar.

Es importante resaltar que, durante todo el desarrollo del proyecto, el Project Manager tendrá el desafío de mantener la triple restricción del proyecto equilibrada constantemente. Si el cliente decide cambiar una de las restricciones, las otras dos, seguramente, serán afectadas.

Equilibrar este triángulo es una de las claves para obtener los resultados esperados de un proyecto. La búsqueda de este equilibrio está en saber priorizar el elemento más importante del proyecto, y eso dependerá, sobre todo, de la organización que lo gestiona, del propio Project Manager, de los patro-cinadores y de las características del proyecto.

Decidir es una labor constante para el Project Manager. En muchos casos, las decisiones serán tomadas atendiendo a las prioridades de la triple restricción del proyecto. Si el cliente establece una fecha determinada como prioridad, el Project Manager intentará hacer lo posible para que esta fecha sea respetada, reduciendo, por ejemplo, el alcance del proyecto, muchas veces comprometiendo su calidad. Para garantizar la entrega del proyecto en la fecha determinada por el cliente, esta acción probablemente incrementará el coste.

Teóricamente, parece sencillo, pero, en la práctica, puede representar un serio problema al Project Manager. Priorizar uno de los componentes de la triple restricción casi siempre provoca un impacto negativo en los demás componentes. Estos cambios de prioridad muchas veces no son planificados y casi siempre conllevan serios problemas.

*Nota del autor: Para acabar este apartado, presentaré una anécdota que encontré en cierta ocasión en internet, sobre un ejecutivo que estaba obsesionado en reducir los costes de los proyectos en detrimento de su calidad.

Se cuenta una historia de un gerente que, no pudiendo aprovechar sus entradas para un concierto donde se escucharía la sinfonía inconclusa de Franz Schubert, se las entregó al director financiero de su empresa, que era famoso por su agresiva postura de reducción de costes; una obsesión que muchas veces causaba problemas en la ejecución de algunos proyectos llevados a cabo por la empresa donde trabajaba. El lunes siguiente, el gerente recibió del director financiero el siguiente informe:

Tras asistir atentamente la sinfonía inconclusa de Franz Schubert, si tuviera la oportunidad, recomendaría los siguientes puntos al director de la orquesta:

– Durante lapsos considerables, los cuatro músicos que tocaban oboe no tenían nada que hacer. Ellos podrían ser eliminados y su trabajo dividido entre toda la orquesta.

– Cuarenta violines tocando notas idénticas. Esto me parece una duplicación innecesaria, y esa parte de la orquesta debería ser drásticamente reducida. Para obtener mayor volumen de sonido, podrían ser usados amplificadores electrónicos.

– Fue absorbido mucho esfuerzo en la ejecución de bemoles y sostenidos. Esto parece un refinamiento excesivo, recomiendo que todas las notas sean redondeadas a la próxima nota simple. Si esto se hiciera, sería posible usar becarios y operadores no especializados.

– No veo ninguna finalidad práctica en la repetición por los metales de los mismos pasajes que ya fueron ejecutados por las cuerdas. Si todos estos pasajes redundantes fuesen eliminados, el concierto podría reducirse a veinte minutos.

– Según este análisis, puedo afirmar que si el compositor Franz Schubert hubiera conocido la reingeniería, definitivamente habría podido concluir su sinfonía y ser más eficiente en el uso de la orquesta y el tiempo.

Por suerte, esta historia es ficticia, pero todos los días son ejecutados centenares de proyectos con presupuestos muy re-ducidos, que, ciertamente, culminarán en un resultado de muy baja calidad. Es por esta razón que existen edificios que se desploman en la primera tormenta, programas que no funcionan y negocios que no prosperan. Recuerde: Uno de los factores de éxito en el Project Management es el equilibrio.

31

C2

2.1.3. Las líneas base de un proyecto

Las líneas base de un proyecto son un conjunto de fechas de inicio y fin, duraciones de trabajo pla-nificadas y los costes previstos durante la fase inicial del proyecto. Se trata de una “fotografía” del proyecto en el momento en que se realizaron las primeras estimaciones. Además, representan el plan original aprobado por los interesados.

Estas informaciones serán la referencia principal por donde se realizarán las mediciones y eventuales desviaciones que se produzcan a lo largo del ciclo de vida del proyecto.

Un seguimiento correcto de las líneas base permitirá al Project Manager poner en marcha acciones pre-ventivas o correctivas que posibiliten poner en proyecto otra vez dentro de la línea base original establecida.

Conforme el proyecto avance, las líneas base serán contrastadas con la situación actual del proyecto, que proveerá las desviaciones reales en función de los planes establecidos. Estas comparaciones son realizadas en momentos puntuales del proyecto, normalmente durante la finalización de una fase o en el momento en que el proyecto alcance uno de sus hitos. Sin embargo, forma parte de las buenas prácticas verificar la evolución de la línea base en las reuniones que se celebran con los integrantes del equipo ejecutor.

Un proyecto cuenta normalmente con tres líneas base, que son las de alcance, coste y plazo.

– La línea base del alcance (scope baseline): Representa la suma de todos los entregables del proyecto. Además, refleja todo el trabajo necesario para concluir un proyecto. Es representada por la EDT (descrita en la sección 5.3).

– La línea base del plazo (schedule baseline): Determina el tiempo total necesario para desarrollar todos los entregables definidos en la línea base del alcance. Puede ser representada por el cro-nograma del proyecto (descrito en la sección 6.5).

La línea base del coste (cost baseline): Es el presupuesto del proyecto (descrito en la sección 7.2). Representa la inversión monetaria total necesaria para desarrollar todos los entregables definidos en la línea base del alcance. La línea base del coste no incluye un eventual presupuesto de contingencia o cualquier otra reserva monetaria.

La línea base del alcance es normalmente la primera en ser desarrollada; luego se suceden las líneas base de plazo y coste. A partir de entonces, el proyecto ya cuenta con una línea base general definida. En algunos casos puede existir una limitación importante de tiempo y recursos financieros. Cuando esto ocurre, se establecen primero las líneas base de coste y plazo, y a continuación se define la línea base de alcance en función de los recursos disponibles.

Figura 8: La línea base de un proyecto

LINEA BASE

FASES

32


Cualquiera de las líneas base del proyecto pueden sufrir modificaciones conforme el proyecto avanza. Toda vez que se introduzcan cambios, la línea base anterior es abandonada y toda la monitorización será realizada en función de la nueva línea base. Siempre que se produzcan cambios en una de las líneas base del proyecto, las otras líneas deberán ser reajustadas. De todas formas, aunque se abandonen las líneas bases anteriores, es importante comparar las desviaciones producidas durante el desarrollo del proyecto.

Para diseñar una línea base es importante disponer, principalmente, de los siguientes datos:

– Las estimaciones de coste del proyecto, desglosados por fase o por actividades, desde la fase inicial hasta el cierre del proyecto.

– El cronograma original del proyecto, desglosado por fases o por actividades.

– También se pueden diseñas líneas base del consumo de recursos disponibles para el proyecto (materia prima, instalaciones, maquinaria, equipos, personal, entre otros).

2.2. Los procesos y fases de un proyecto

Como los proyectos suelen tener un grado de incertidumbre muy alto, se hace necesario organizarlo en fases para que, de esta forma, sea posible administrar mejor su evolución, reducir la incertidumbre y, por consiguiente, los riesgos involucrados.

Una fase es un conjunto de actividades relacionadas con el objetivo de obtener un resultado previa-mente esperado. Cada proyecto, dependiendo de su naturaleza y complejidad, tendrá sus fases divi-didas y organizadas de forma que mejor permita su gestión. Sin embargo, para desarrollar una admi-nistración eficaz, es importante realizar, en cada fase, cuatro procesos básicos imprescindibles: inicio, planificación, ejecución/control y cierre.

Figura 9: Procesos del proyecto

– Inicio: Se inicia tras la asignación del Project Manager a través del acta de constitución del pro-yecto. El inicio del proyecto es la primera etapa de su ciclo de vida e incluye las primeras activida-des tras la aprobación formal del proyecto. En este proceso, se definen los objetivos, el alcance, las propuestas y los entregables que serán producidos.

– Planificación: Es un proceso muy importante y, desafortunadamente, muy despreciado por las empresas. Es el momento donde se realizan las estimaciones del proyecto, se confecciona el plan de proyecto y se define su estrategia de ejecución, además de los procedimientos de control. Existen organizaciones que suelen fundir este proceso con el anterior, lo que no es aconsejable.

REC

UR

SOS

inicio planificación ejecución cierre

33

C2

– Ejecución/control: Es el proceso que pone en marcha todo lo planificado anteriormente. Normal-mente, el 90% de los recursos son consumidos en esta fase, que termina cuando el objetivo del proyecto ha sido completamente alcanzado.

– Cierre: Suele ser el proceso más corto del proyecto y, sin embargo, uno de los más importantes. En esta etapa, el producto o servicio desarrollado es puesto en marcha, el cliente realiza las prue-bas de aceptación y, una vez comprobado que los requisitos establecidos se cumplen, el pro-yecto es formalmente finalizado, lo que suele suceder mediante la firma de una aceptación formal.

Si trasladamos estos conceptos a un proyecto personal, como, por ejemplo, las vacaciones de verano, podremos observar cómo estos procesos marcan de forma muy clara el ciclo de vida de un proyecto:

– Inicio: Se determinan cuántos días de vacaciones disponemos, qué tipo de vacaciones queremos organizar (playa, montaña...), qué distancia pretendemos recurrir y la cantidad de dinero que podemos invertir. Además, se buscan informaciones acerca de la ciudad, las tarifas de los hoteles, la disponi-bilidad de vuelos o la ruta y las distancias que deberán ser recorridas en el caso de viajes de coche.

– Planificación: En función de los resultados obtenidos, se determinan la duración de las vacacio-nes, la asignación un presupuesto y los recorridos realizados, acorde con el calendario previsto.

– Ejecución/control: Empiezan las vacaciones. Si el traslado es realizado en avión, se tratará de llegar puntualmente al local de embarque. Si viajamos de coche, intentaremos cumplir la ruta en los tiem-pos planificados. En la ciudad, disfrutaremos del hotel y de las atracciones de las que la ciudad ofre-ce. Si surgen incidencias (el hotel no satisface las exigencias mínimas, el coche sufre alguna avería, el vuelo ha sido cancelado...), se ponen en marcha las acciones correctivas correspondientes.

– Cierre: La vuelta a casa. Se guardarán las fotos y los recuerdos del viaje y se pagarán las facturas referentes a las reservas, compras y dietas realizadas durante las vacaciones.

Para proyectos pequeños, estos procesos representan toda la vida del proyecto. No obstante, en proyec-tos muy grandes, podrán repetirse en cada fase de su ciclo de vida, según se ha ilustrado en la figura 10.

Figura 10: Fases y procesos de un proyecto

PLANIFICACIÓN

FASE

1

INICIO

CIERRE EJECUCIÓN

CONTROL

PLANIFICACIÓN

FASE

2

INICIO

CIERRE EJECUCIÓN

CONTROL

PLANIFICACIÓN

FASE

3

INICIO

CIERRE EJECUCIÓN

CONTROL

34


No existe un proceso más importante, aunque uno consuma más tiempo y recursos que otro. Cada proceso tiene su importancia y el proyecto depende del buen desarrollo de cada uno para alcanzar sus objetivos. Si un proceso no es bien realizado, seguramente el siguiente sufrirá sus efectos nega-tivos, y así será sucesivamente, provocando daños que podrán ser irreparables.

Figura 11: Ciclo de vida representativo de un proyecto de desarrollo de software

Organizar un proyecto en fases nos puede aportar una serie de beneficios, entre ellos:

– Facilita el control del proyecto: Al dividir el proyecto por fases, se permite al Project Manager y al equipo tener un enfoque más restrictivo. De esta forma, el control del proyecto se vuelve más sencillo, ya que todas las atenciones están volcadas a la fase que se está desarrollando.

– Disminuye la complejidad del proyecto: Proyectos complejos, como son los de la construc-ción, suelen contener muchas actividades e involucrar a grandes equipos, y por ello, su adminis-tración pude ser muy complicada. Mediante la organización de un proyecto por fases, su gestión se torna más sencilla, puesto que las metas estarán enfocadas al término de la fase en curso, no del proyecto como un todo.

– Reduce la incertidumbre: La falta de información es la principal razón del aumento de la pro-babilidad de riesgo en un proyecto. Realizando una gestión de proyectos por fases, se dedica una atención especial a los riesgos específicos de la fase que se está ejecutando, facilitando su supervisión y control.

2.2.1. Inicio

Es el proceso de autorizar formalmente un nuevo proyecto. Generalmente, los proyectos son autori-zados como resultado de una o más de las siguientes causas:

– Una demanda de mercado: Una empresa de informática autoriza un proyecto para desa-rrollar un sistema de gestión para un segmento de mercado que todavía no cuenta con una herramienta eficaz.

– Una necesidad de negocio: Una organización autoriza un proyecto para poner en marcha la creación de una nueva unidad de negocio para la obtención de nuevos clientes.

POR

CEN

TAJE

REA

LIZA

DO

REQUISITOS ANALISIS DISEÑO DESARROLLO PRUEBA

Estudio

Decisión

Puesta enmarcha

Versiónbeta

Versióncomercial

FASE 1 FASE 2 FASE 3 FASE 4 FASE 5

35

C2

– Requisito del cliente: Una constructora autoriza un proyecto para construir una urbanización de viviendas en la zona vieja de la ciudad.

– Un avance tecnológico: El gobierno autoriza un proyecto para el desarrollo de un satélite que pueda monitorizar la sequía que compromete el ecosistema de una determinada región.

– Una necesidad legal: Un establecimiento comercial autoriza un proyecto para implantar unos procedimientos exigidos por una nueva ley que les afecta directamente.

– Una necesidad social: Una organización no gubernamental autoriza un proyecto para desarrollar una forma alternativa de suministrar energía eléctrica a pueblos muy aislados de un determinado país.

Aunque esta fase parezca la más “corta” de un proyecto, no podemos subestimarla, dado que, en esta fase, se asientan las bases fundamentales de un proyecto, como, por ejemplo:

– Las necesidades y requisitos del cliente.

– Los objetivos del proyecto.

– Las restricciones y supuestos.

– Los contratos y presupuestos.

– Los hitos.

– La identificación de los interesados.

– La asignación del Project Manager y su equipo.

Esta es, además, la fase donde el riesgo se encuentra en su nivel más alto, ya que son muchas las incertidumbres, y la organización cuenta con muy poca información. Es una fase en que también se produce un elevado número de cambios.

Existen varias formas de empezar un proyecto. La más correcta es mediante la publicación del acta de constitución del proyecto (project charter). Se trata básicamente del primer documento desarrollado para un proyecto ya aprobado y que formaliza su inicio e identifica los grupos de interés, el equipo que se encargará de su desarrollo. Pero, sobre todo, es el documento que concederá autoridad al Project Manager para desempeñar sus funciones.

Además del acta de constitución del proyecto, es importante empezar desde esta fase la identificación de las restricciones y supuestos del proyecto. Las restricciones suelen limitar las opciones del Project Manager y de su equipo, pero, por otro lado, son importantes para determinar hasta dónde se puede llegar. Los supuestos, por su lado, reflejarán la disponibilidad del equipo adjudicado, las fechas de comienzo de actividades, las cláusulas contractuales, entre otros. Los supuestos son importantes, pues dan el norte al proyecto. Si no se formalizan, el proyecto no empezará, o si llega a empezar, evolucionará sin un rumbo claramente definido. El concepto más amplio de restricciones y supuestos está descrito a continuación:

Las restricciones del proyecto

Una restricción es un factor que impone un determinado límite al desarrollo de una determinada acti-vidad. Las restricciones tradicionales de un proyecto son las siguientes:

– De coste: Un proyecto puede ser cancelado por falta de recursos económicos que le permitan seguir adelante, ya que su puesta en marcha depende de múltiples variables financieras, como, por ejemplo, los costes de mano de obra, materiales o infraestructuras.

36


– De tiempo: En algunos casos, el plazo es la principal restricción de un proyecto. En la década de los 90, muchas empresas de software tuvieron que afrontar el problema del año 2000, más conocido como el “Efecto 2000” o “Year 2000 Problem - Y2K”. Sus aplicaciones informáticas corrían el riesgo de parar de funcionar si no se implantasen las correcciones adecuadas. Bancos, empresas de telefonía y multinacionales de grande porte invirtieron millones de dólares para evitar que ocurriese una “catástrofe electrónica”, que felizmente no llegó a ocurrir. Fueron realizados proyectos cuyo límite era el milenio que se acercaba. El año 2000 no podría ser postergado.

– De alcance: Son los requisitos del proyecto. Un proyecto se considera finalizado cuando el resul-tado alcanzado corresponde a los requisitos especificados por el cliente.

Un proyecto puede tener otras restricciones importantes:

– Tecnológicas: Durante toda la historia de la humanidad, muchos científicos lograron descubrir inventos que tuvieron que esperar años, y muchas veces siglos, para ser puestos en marcha, simplemente porque no existía la tecnología necesaria para realizarlos. La genialidad de Leonardo Da Vinci le llevó a diseñar una infinidad de aparatos ingeniosos, desde instrumentos científicos hasta maquinas voladoras. El helicóptero de Da Vinci fue diseñado en el siglo XV, que, lógica-mente, por limitaciones tecnológicas no pudo ser puesto en práctica hasta comienzos del XX, quinientos años más tarde.

– De recursos humanos: Disponer del equipo adecuado en el momento oportuno. Desafortuna-damente, esta regla es muy difícil de lograr. Una empresa puede disponer recursos financieros y tecnológicos para desarrollar el proyecto que se proponga; no obstante, si no dispone de los recursos humanos adecuados, pocas serán las posibilidades de éxito. Muchos proyectos son puestos en marcha con equipos incompletos, tanto en cantidad como en calidad, y la conse-cuencia de esta debilidad se refleja en los resultados obtenidos.

– Legales, burocráticas y políticas: Son restricciones que están directamente asociadas a la organización ejecutante del proyecto o al país donde el proyecto será desarrollado. Las mayores dificultades en la realización de un proyecto provienen de legislaciones específicas. Los proyectos de construcción de centrales hidroeléctricas, por ejemplo, dependen de un amplio estudio de impacto ambiental que puede llevar años para ser realizado. La burocracia de algunos países que exigen una infinidad de licencias y permisos para la ejecución del proyecto o algunas cuestiones políticas son también restricciones importantes que pueden impedir que un proyecto sea desa-rrollado sin percances.

– Culturales: Algunos proyectos pueden sufrir cambios en su diseño, por determinadas razones culturales, sobre todo en lo referente a la percepción de la calidad. Es decir, satisfacer las ne-cesidades y expectativas de los clientes, que pueden ser diferentes, dependiendo de la región en que se desarrolla el proyecto. Para solventar este tipo de restricción, se realizan estudios de percepción de calidad, que constituyen un elemento fundamental para comprender la forma por la cual un determinado cliente reacciona delante de un nuevo producto o servicio.

– Organizacionales: La forma en que una empresa aprovecha sus recursos humanos, su política de compras, gastos e inversiones y su política interna.

Será el conjunto de objetivos y restricciones que definirá las primeras estrategias y el primer borrador del plan de proyecto.

Los supuestos del proyecto

El término “supuesto” en el ámbito del Project Management se refiere a los factores que son con-siderados verdaderos para realizar una planificación o estimación coherente, sin que sea necesario demostrar su fiabilidad. Por ejemplo:

37

C2

– “Los componentes importados desde China vendrán con sus manuales escritos en inglés”;

– “Cuando termine la fase de diseño, tendremos cuatro ingenieros disponibles full time”;

– “En la segunda quincena de septiembre, el 50% de las pruebas estarán realizadas”.

Es importante que estos supuestos sean acordados y documentados. Normalmente, los supuestos de un proyecto son plasmados en el acta del proyecto o en el plan de proyecto.

Estos supuestos forman parte de la elaboración progresiva de la planificación del proyecto y por po-seer un cierto grado de incertidumbre, conllevan a un cierto grado de riesgo. Es importante contar con especialistas para realizar estos supuestos, para, de esta forma, minimizar riesgos eventuales. Una vez considerados verdaderos, serán tomados en cuenta a la hora de confeccionar cronogramas y otros documentos del proyecto.

2.2.1.1. Reunión de apertura del proyecto (Kickoff meeting)

La reunión de apertura del proyecto, también conocida como Kickoff Meeting, es el momento opor-tuno de reunir al cliente, al equipo del proyecto y a los interesados para declarar formalmente el comienzo del proyecto y asegurarse de que todos los involucrados conocen sus funciones y res-ponsabilidades. Como ocurre en cualquier reunión formal, es importante tener una agenda y divulgar el acta de constitución del proyecto. Esta agenda debe incluir, por lo menos, los puntos que se expresan a continuación:

– Motivos por los que el proyecto será llevado a cabo.

– Presentación de las especificaciones del proyecto.

– Presentación del equipo del proyecto.

– Presentación del cronograma del proyecto.

– Apuntar las actividades previstas para la próxima reunión.

La reunión de apertura es una oportunidad única de empezar bien el proyecto. Formalizando todos los puntos anteriores, el Project Manager podrá asegurarse de que todos los involucrados son cons-cientes de los compromisos asumidos y de las expectativas del proyecto. Por esta razón, esta reunión debe ser bien preparada y organizada. Es importante transmitir seguridad y una buena impresión a los involucrados.

En el caso de no ser posible reunir a todos los involucrados en el proyecto, como mínimo es importan-te garantizar la asistencia de los más importantes. Toda la información recogida en esta reunión deberá formar parte de la documentación del proyecto que será distribuida posteriormente. La duración de esta reunión es proporcional a la complejidad del proyecto.

De la misma forma que una reunión de apertura puede llevar algunas horas, en algunos casos puede necesitar de uno o más días.

*Nota del autor: Hay casos en que algunos Project Managers menos experimentados simplemente ignoran la fase inicial del proyecto. Se trata de un fallo importante que, seguramente, les cobrará factura más adelante. Un proyecto no debería comen-zar sin una fase inicial formalizada con un mínimo de datos que, a posteriori, alimentarán de forma más concreta la fase de planificación. La fase de inicio es la adecuada para realizar una primera toma de datos que serán más refinados y fiables, según avance el proyecto.

Es de suma importancia que los objetivos sean claramente definidos en esta fase, aunque sufran cambios más adelante. Lo impor-tante es partir de algún objetivo concreto que sea, sobre todo, realizable.

Además, es fundamental definir las restricciones del proyecto. Una restricción es un factor que puede imponer un límite impor-tante al desarrollo de un proyecto, pudiendo, inclusive, culminar en su cancelación.

38


2.2.2. Planificación

La planificación funciona como una especie de mapa que nos aporta las instrucciones y orientaciones para que podamos llegar con éxito a un determinado lugar y es un proceso que es desarrollado du-rante todo el ciclo de vida del proyecto.

Aunque todos los procesos son importantes, planificar es fundamental. Sin embargo, en muchas ocasiones, es el proceso más olvidado por las personas que desarrollan la ejecución de un proyecto.

Hay casos, desafortunadamente muy frecuentes, en que existe la necesidad de empezar repenti-namente un proyecto para cubrir una necesidad puntual y, cuando esto ocurre, el proceso de pla-nificación a veces se reduce simplemente a confeccionar un cronograma. Planificar significa mucho más que confeccionar una sencilla tabla orientativa de fechas, que, aislada, no sirve para mucho. Un Project Manager que no sea capaz de realizar junto con su equipo una buena planificación, pasará una buena parte del proyecto “apagando fuegos”.

La mala costumbre de no planificar ocurre con frecuencia en las organizaciones. Normalmente, las personas saltan de la fase de inicio (cuando esta existe) a la fase de ejecución sin antes dedicar un solo momento a la planificación. Es decir, que, en algunos casos, la organización ya empieza un pro-yecto, ejecutándolo, de forma totalmente irresponsable e inconsecuente.

La mentalidad que a veces se aprecia es: “Si ya hemos hecho proyectos similares a este, ¿por qué tenemos que planificarlo todo otra vez?”. Como he comentado anteriormente, a pesar de que la empresa haya realizado un proyecto muy similar en ocasiones anteriores, algunos elementos o cir-cunstancias seguramente habrán cambiado y toda la planificación anterior no podrá ser totalmente aprovechada.

Figura 12: Ciclo de planificación de un proyecto

REC

UR

SOS

INICIO DELPROYECTO TIEMPO PROYECTO

FINALIZADOPROYECTOFINALIZADO

PLANIFICACIÓN MINIM

A

INVERSION EN

PLANIFICACIÓN

39

C2

2.2.2.1. Relación entre los procesos

La planificación es un proceso que tiene una interacción muy importante con el proceso de seguimien-to y control, puesto que ambos se alimentan mutuamente de los resultados obtenidos durante el proceso de ejecución. Cuando se detecta una desviación en la ejecución del proyecto, se planificará otra vez las actividades correspondientes para mantenerlo bajo control.

Figura 13: Relación entre los procesos de planificación y control

Planificar aporta una serie de beneficios, entre ellos:

– Reduce la incertidumbre: Una planificación adecuada permitirá el desarrollo de medidas preven-tivas y correctivas para que los resultados esperados sean alcanzados.

– Aumenta el entendimiento: Planificar aporta al equipo la información necesaria para que se en-tienda el proyecto de forma clara y objetiva.

Produce eficiencia: Una vez definido el plan de proyecto y los recursos necesarios para llevarlo a cabo, se podrá organizar el trabajo de forma optimizada de manera que, al final, se pueda terminar el proyecto en el plazo, dentro del presupuesto estimado y utilizando los recursos de forma adecuada. Hay casos en que es posible, incluso, terminar un proyecto antes del plazo, consumiendo menos recursos que los originalmente asignados y, lo más importante, sin afectar su calidad. Es interesante cómo en muchas empresas las personas se quejan de que no hay tiempo para planificar, pero cuando las cosas salen mal, hay que buscar tiempo adicional para rehacer todo el trabajo no planificado.

Planificar incluye, como mínimo, el alcance, el coste, el plazo, los recursos y los riesgos involucrados. En relación al alcance, es necesario desglosar las fases del proyecto en componentes más pequeños y manejables, de forma en que se pueda visualizar la dimensión total del trabajo involucrado. Con este nivel de detalle disponible, será más fácil estimar la cantidad de dinero que será invertido en cada componente, su tiempo de duración y los recursos necesarios para desarrollarlo. Una forma de hacer este desglose de forma eficaz es a través del uso de una herramienta llamada “Estructura Detallada del Trabajo – EDT” (WBS - Work Breakdown Structure), que descompone los trabajos establecidos para un proyecto, organizando y definiendo su alcance total (esta herramienta es descrita en detalle en la sección 5.3).

Inicio Planificación EjecuciónSeguimiento y

ControlCierre

40


Todas estas informaciones deberán estar reunidas en el plan de proyecto. Este documento servi-rá como una especie de “mapa” que orientará a los involucrados desde el comienzo hasta el final del proyecto.

Figura 14: Línea base x reserva

Es importante tener en cuenta que la planificación no es un evento aislado que ocurre entre el inicio del proyecto y su ejecución. Es una actividad que debe ser realizada constantemente. Planificar no es crear un plan al comienzo del proyecto y, después, dejarlo archivado en algún sitio para “echarle un vistazo” de vez en cuando. Se trata de una documentación de apoyo importante que debe ser actualizada constantemente.

2.2.2.2. ¿Cómo puedo estar seguro de que he planificado lo suficiente?

Está claro que no existe una forma sencilla de saberlo. Lo que se intenta hacer es planificar lo máximo posible para reducir el nivel de incertidumbre y poder tener más control sobre el proyecto. La pregunta entonces sería: “¿Cuánta planificación necesito?”, y la respuesta podrá encontrarse tras el análisis de los siguientes factores:

– La complejidad del proyecto: La regla es sencilla. El nivel de planificación es proporcional a la complejidad del proyecto.

– El tamaño del proyecto: Proyectos muy grandes requieren un esfuerzo importante de coordina-ción, ya que contienen una cantidad ingente de informaciones que pueden perderse fácilmente si no se realiza un control intensivo sobre ellas. Este tipo de proyecto debe tener una planificación formal y muy bien definida.

*Nota del autor: Algunos Project Managers suelen ser demasiado optimistas en el momento de planificar. Existe una tendencia en pensar que las cosas saldrán perfectas, que los plazos serán respetados, que difícilmente algún factor exterior influirá negati-vamente en el proyecto y que no habrá espacio para el surgimiento de conflictos. Este tipo de razonamiento tan solo conllevará al fracaso del proyecto, sobre todo cuando empiecen a surgir los primeros problemas.

Como consecuencia, todas las estimaciones positivas empezarán a desmontarse en una especie de “efecto dominó”, que conllevará a un ambiente bastante desfavorable.

Para evitar caer en este tipo de errores, es importante que el Project Manager intente realizar una previsión de los posibles resultados de un proyecto en distintos escenarios, normalmente en un escenario optimista y otro pesimista. Estos escenarios ayudarán al Project Manager a definir una línea base. Si acaso algún evento tienda a dislocarse a un escenario más pesimista, el Project Manager podrá contar con alguna reserva de emergencia. Esta reserva podrá ser financiera, de plazos o de recursos y será estimada acorde con los resultados de proyectos similares y, sobre todo, a través de la experiencia y juicio de expertos.

RESERVA

FASES

LINEABASE

41

C2

– El nivel de incertidumbre: Cuando el nivel de incertidumbre es alto, es común que se desarrollen planes muy elaborados utilizando técnicas sofisticadas. Esta práctica no suele obtener buenos resultados, porque si el nivel de incertidumbre es alto, el Project Manager no dispondrá de sufi-cientes informaciones que le permitan desarrollar planes precisos. Además, con escasa informa-ción acerca del futuro, cualquier plan que se elabore sufrirá varias modificaciones a lo largo del proyecto, hasta que se alcance un nivel de incertidumbre gestionable. Es importante confeccionar un plan equilibrado, acorde con la información disponible.

Cuanto más complejo y largo sea el proyecto, más planificación será necesaria para mantenerlo bajo control. Los proyectos más pequeños y más simples tienen un margen de riesgo más pequeño. De todas formas, todo es una cuestión de sentido común. Como normalmente no se puede estar pen-diente constantemente de la evolución de un proyecto en conjunto, es importante determinar las fases clave y los hitos más importantes y estar atento a sus resultados. Los hitos, también conocidos como milestones, son puntos utilizados en el cronograma que, normalmente, señalizan un evento importan-te del proyecto, la conclusión de una determinada actividad, decisión o fase.

2.2.2.3. Las estimaciones

Según Tom DeMarco, “Una estimación es una predicción que tiene la misma probabilidad de estar por encima o por debajo del valor actual”.

Una estimación, por definición, busca determinar un resultado cuantitativo aproximado. Para que un proyecto pueda ejecutarse dentro del plan establecido, es muy importante saber la duración de las actividades, cuánto costará desarrollarlas y qué recursos serán necesarios para llevarlas a cabo. Para ello, es fundamental realizar buenas estimaciones. De lo contrario, el proyecto se tornará un “agujero negro”, absorbiendo todo lo que encuentra, sin proporcionar los resultados esperados. Sin embargo, realizar estimaciones no es una tarea nada fácil, todo lo contrario. En el comienzo del proyecto, si no fuesen identificados todos los entregables, algunos interesados pueden cambiar algún punto en con-creto y, generalmente, el tiempo para realizar estimaciones suele ser muy limitado.

Para poder contar con una estimación realista, es necesario contar básicamente con dos factores:

– Experiencia del equipo y de expertos: Se trata de un recurso importante para realizar es-timaciones más o menos precisas. Esta colaboración puede venir tanto de un especialista como de un grupo de personas con mucha experiencia y formación especializada. Entre ellos, podemos incluir consultores veteranos, integrantes del equipo del proyecto, proveedo-res especializados...

– La documentación de proyectos anteriores similares: Un proyecto debe disponer de una documentación completa en la que figuren todas las gestiones, planes, estimaciones y cualquier otro registro que el Project Manager considere relevantes.

Una documentación bien estructurada servirá de soporte en la comunicación entre los integrantes del equipo, provee de soporte a los departamentos involucrados y servirá en el futuro como una base histórica fiable de consulta.

*Nota del autor: Existe un detalle importante que puede afectar a los resultados de las estimaciones de un proyecto: el carácter del equipo, de los interesados y del propio Project Manager. Hay casos en que existe una cierta tendencia pesimista u optimis-ta que influye a la hora de estimar costes y plazos. Un proyecto puede tener estimaciones de plazo muy optimistas que serán difíciles de cumplir, como puede también tener estimaciones pesimistas que necesitarán de una reserva financiera importante, que podrá dificultar eventuales aprobaciones para su puesta en marcha.

Además, como las estimaciones normalmente cruzan datos de plazo y coste, hay un margen enorme de arruinar cualquier plan. En estimaciones demasiado optimistas, los plazos son reducidos y no se incrementan los costes, cuando, normalmente, los costes aumentan cuando los plazos son acortados.

42


Las estimaciones normalmente fallan

Uno de los factores de fracaso más comunes en el proyecto son las actividades “subestimadas”, que conllevan a un incremento importante de presupuesto y a un incumplimiento del cronograma. Esto ocurre normalmente por las siguientes razones:

– Demasiado optimismo por parte de las personas involucradas.

– No se tienen en cuenta el tiempo consumido por reuniones o las tareas administrativas, entre otros factores.

– No se prevén posibles bajas laborales.

– No se tienen en cuenta los días festivos, vacaciones o periodos estivales.

– No se realizan consultas a las lecciones aprendidas de proyectos anteriores similares.

– En algunos casos, el equipo no conoce totalmente el alcance del proyecto.

– Falta de experiencia por parte del Project Manager, del líder técnico o del propio equipo.

2.2.3. Ejecución

Es la fase en que se pone en marcha todo el plan de proyecto. En este momento, el Project Manager estará monitorizando el desarrollo de las actividades planificadas y establecidas en las fases anteriores.

Durante esta fase, el equipo estará plenamente dedicado al desarrollo del proyecto. Es también la fase donde la comunicación deberá fluir constantemente. Además, en esta fase es importante realizar reuniones de seguimiento para recopilar informaciones sobre su progreso. En este momento, el Pro-ject Manager conducirá el proyecto estrictamente acorde con el plan. Si acaso, por algún motivo, el resultado producido no es el esperado, el equipo deberá documentar todas las incidencias para que se puedan realizar las oportunas valoraciones y estudiar posibles cambios y/o acciones correctivas.

2.2.4. Seguimiento y control

Controlar es una palabra que muchas veces nos lleva a pensar en autoritarismo. No obstante, cuando hablamos del Project Management, controlar no es sinónimo de ser autoritario. Se trata de verificar si el equipo está haciendo bien las cosas y cumpliendo con el plan. Simplemente consiste en mantener el pro-yecto dentro de su curso. Haciendo una analogía, es como un conductor que está en una carretera y por un despiste, sale de su carril, pero corrige su trayectoria y luego vuelve a estar centrado en su recorrido.

Básicamente, el control del proyecto se resume en analizar los resultados y las variaciones de la ejecu-ción de los trabajos y asegurarse de que sus objetivos están siendo cumplidos. Además, se realizan las mediciones necesarias que puedan identificar posibles variaciones con respecto al plan y, conse-cuentemente, tomar las acciones correctivas adecuadas o, lo que sería lo mejor, las acciones preven-tivas para anticiparse a posibles problemas. Por ejemplo, si una fecha de conclusión de una actividad se acerca, pero todavía está lejos de terminar, el Project Manager deberá incluir horas extra, aumentar el número de recursos dedicados a la actividad o, si es posible, reajustar el cronograma del proyecto.

La mejor manera de hacer una medición adecuada es observar la evolución de una actividad en su detalle. Es decir, si una determinada actividad necesita de diez acciones, se medirá la conclusión de cada acción por separado. De esta forma, se obtendrá el porcentaje del trabajo realizado en esta actividad. Haciendo una simple analogía, un Project Manager no puede observar la evolución de un bosque en conjunto. Es necesario acompañar el desarrollo de cada árbol, teniendo en cuenta que la debilidad de un árbol puede afectar el crecimiento de los demás, comprometiendo así el desarrollo de

43

C2

todo el bosque. La esencia del Project Management es la búsqueda constante del equilibrio. No se puede adoptar una postura de negligencia de cara al control de un proyecto, pero tampoco el Project Manager tiene que llevar la gestión al nivel de una obsesión.

Estar soportado por una buena documentación y, sobre todo, escuchar la palabra de expertos y de personas con experiencia en la gestión de proyectos similares también son factores que contribuirán para el control eficaz del proyecto.

Existen algunas acciones que, realizadas de forma adecuada, contribuirán positivamente en un control efectivo del proyecto:

– Reconfirmar el plan de proyecto: Antes de empezar una fase importante, es elemental revisar con los miembros del equipo si los trabajos propuestos todavía son posibles de ponerse en mar-cha de la forma en que establece el plan de proyecto.

– Registrar toda la información relevante: Durante la fase ejecución, es muy importante que el equipo registre todas las informaciones que consideren útiles para el proyecto en curso y/o para proyectos futuros similares, como, por ejemplo, resultado de pruebas, fechas reales de comienzo y conclusión de las tareas del proyecto y el número de horas consumidas en cada tarea. Los resultados colectados serán confrontados con los resultados previstos en el plan.

– Realizar acciones correctivas: Siempre que se comparan los resultados obtenidos con los previstos se obtendrán informaciones que darán al Project Manager la oportunidad de poder, en tiempo, realizar acciones correctivas que eviten que el proyecto pierda su dirección.

– Mantener al equipo informado: La comunicación es otro factor crucial en el control del proyecto. Mantener al equipo informado, a través reuniones de seguimiento e informes de estado, aportará seguridad a todos e incrementará la coordinación entre los involucrados.

2.2.5. Cierre

El cierre es un proceso que básicamente asegura que todas las actividades que forman parte del proyecto han sido correctamente finalizadas. Normalmente, esta fase exige una aceptación escrita del cliente formalizando la correcta recepción de todos los entregables previstos en el proyecto.

Todos los proyectos tienen que llegar a la fase de cierre. Es verdad que, en algunos casos, un proyec-to termina de forma abrupta y prematura, y eso suele ocurrir cuando las cosas no han salido bien y se decide terminarlo antes que se produzca un desastre. No obstante, cuando se decide por la puesta en marcha de un proyecto, se espera que este finalice acorde con el plan establecido, con todas las actividades desarrolladas, y los productos y servicios producidos entregados correctamente al cliente. Tan importante como empezar bien un proyecto es terminarlo de forma adecuada. Normalmente, el equipo del proyecto está muy motivado en hacer las cosas bien cuando se empieza un nuevo proyec-to, sin embargo, la motivación no es la misma en su cierre. El desgaste provocado por los problemas y conflictos ocurridos o las perspectivas generadas hacia nuevos proyectos son algunas de las causas que perjudican su buen cierre.

En ocasiones muy frecuentes, el equipo es disuelto inmediatamente tras su conclusión. Cuando esto ocurre, se pierde una valiosa oportunidad de recoger información sobre las lecciones aprendidas, las conclusiones y las recomendaciones al equipo que dará posteriormente soporte al proyecto.

Incluso, en los proyectos en que no se hayan producido los resultados esperados, se pueden recoger informaciones que ayudarán a evitar que se produzcan los mismos errores en un emprendimiento similar.

En la fase de cierre se realiza, además, una evaluación general de los trabajos realizados, suministran-do información que servirá de consulta para la planificación y la ejecución de proyectos futuros. Esta información es almacenada en un documento llamado Libro de Notas del Proyecto.

44


2.2.5.1. Entrega de todos los productos y/o servicios del proyecto

– Documentación: La documentación muchas veces es vista como un simple papeleo burocráti-co, dado el tiempo que se invierte en dejarla actualizada conforme el proyecto avanza. Realmente, mantener la documentación de un proyecto es un esfuerzo importante, además de todo el trabajo que implica ejecutar un proyecto acorde con su plan. Sin embargo, en muchas ocasiones, el equipo o el Project Manager echan de menos la documentación de un proyecto anterior cuando están buscando alguna solución para un problema determinado. Toda la documentación confec-cionada durante el proyecto debe tener un fin acordado por todos los interesados. Basado en este acuerdo, algunos documentos serán archivados en carpetas y otros son destruidos. Mucha documentación servirá como base para proyectos futuros. Además, es importante respetar el contenido confidencial de los documentos.

– Cierre de los contratos: Normalmente, un proyecto es estructurado en función de varios con-tratos entre los interesados (proveedores, clientes, socios...). Como parte importante del proce-so de cierre, es fundamental realizar una revisión final en los contratos acordados, con el fin de certificar que no existen puntos pendientes. Igual que los contratos, es importante realizar esta misma revisión en el plan de proyecto y en las actas de reunión. Además, es elemental consultar el departamento financiero la eventual existencia de facturas no pagadas.

– Aceptaciones: Es el cliente quien decide si el proyecto ha terminado y es el Project Manager quien deberá demostrar que el producto o servicio contratado ha sido entregado dentro de las especificacio-nes solicitadas. Es importante obtener todas las aprobaciones pendientes, siempre de forma escrita. Normalmente, todas estas aceptaciones culminan con una aceptación final, que confirma que no exis-te ningún trabajo pendiente que deba ser realizado. En algunos casos, el cliente aceptará el final del proyecto tras realizar algunas verificaciones puntuales a través de pruebas. Se suelen crear listas de verificación (checklists, descrita en la sección 8.3.1.5) que irán a pautar los puntos en que el producto no puede fallar. El resultado de esta lista de verificación determinará la aceptación final del proyecto.

– Cierre Formal del Proyecto: Todos los proyectos deben contar con un cierre formal que deberá estar reflejado en el cronograma del proyecto.

El Project Manager, los representantes del equipo, los patrocinadores, los clientes y otros grupos de interés deberán fijar una reunión que formalmente cierre el proyecto. La agenda de esta reunión deberá describir principalmente:

– Un breve resumen histórico del proyecto.

– Los objetivos cumplidos y no cumplidos.

– Los beneficios del proyecto para el cliente.

– Las lecciones aprendidas.

Además, es importante asumir el éxito o el fracaso de un proyecto. Muchas veces es evidente que un proyecto ha sido concluido de forma exitosa o no. En algunos casos, puede que algo haya ocurrido de forma no planificada y, como consecuencia, que se produzca algún factor que perjudique el proyecto.

Por ejemplo, un programa puede haber sido entregado en la fecha planificada, pero algunos pueden haber sido entregados con fallos importantes. Los resultados de éxito o fracaso de un proyecto serán muy útiles como “lecciones aprendidas”, que aportarán valiosos conocimientos para futuros proyectos.

Es de responsabilidad del Project Manager formalizar el cierre de las fases, contratos, cobros y toda la documentación del proyecto. Estas gestiones deben ser realizadas en el tiempo oportuno, antes de que el equipo sea deshecho y reasignado a otros proyectos.

Es importante también divulgar a toda organización el cierre formal del proyecto. El equipo será oficial-mente disuelto para ser asignado a nuevos proyectos y, a la vez, los departamentos de compras, con-tabilidad y administración realizarán las gestiones correspondientes al cierre final. La documentación generada desde el inicio deberá ser debidamente archivada para eventuales consultas.

45

C2

2.3. Las actividades del proyecto

Una actividad es un componente del proyecto que, organizado de forma integrada con otras activi-dades, forma el trabajo total para la realización de un proyecto. Una actividad tiene un identificador propio, un tiempo de ejecución estimado, un coste presupuestado y un pool de recursos asignados.

2.4. Los entregables del proyecto

Todos los proyectos culminan en un resultado concreto. Este resultado puede ser un producto, un servicio o la combinación de ambos. Los elementos individualmente generados en cada fase del pro-yecto son conocidos como “entregables”.

Existen dos tipos de entregables: internos y externos. Los entregables internos son aquellos produci-dos para auxiliar el avance del propio proyecto. Normalmente, son los resultados de una actividad que son necesarios para poder empezar la actividad siguiente (por ejemplo, la producción de un diseño es necesaria para poder montar un prototipo). Los entregables externos son aquellos que serán entrega-dos a algún interesado externo del proyecto (el cliente, el usuario final, el patrocinador, entre otros.) Los entregables externos deben ser claramente definidos por los interesados, que serán los encargados en su aprobación en el momento de la entrega.

2.4.1. La lista de entregables del proyecto

Es muy importante, antes de definir el alcance del proyecto, conocer cuáles serán exactamente los entregables que este proyecto generará. Muchos proyectos invierten mal sus recursos en entregables que no aportarán lo que realmente el cliente necesita. Esto se traduce en un desperdicio de tiempo y dinero, además de provocar una mala sensación. Para evitar esta situación, se confecciona una lista de entregables. Su procedimiento de desarrollo es muy sencillo y resulta bastante eficaz.

Una de las formas más sencillas de definir los entregables de un proyecto es a través de la organiza-ción de una reunión entre todos los interesados del proyecto y cada uno de ellos escribirá en una hoja de papel cuáles son sus deseos en relación al proyecto que se desarrollará. Esta “lista de deseos” es libre y muchas veces será muy extensa, lo que ya demuestra cómo muchos proyectos empiezan con una sobrecarga de entregables innecesaria.

Cada interesado entrega su hoja y, utilizando el sentido común, se van eliminando todos los deseos innecesarios. Es importante registrar la justificativa por la cual el deseo fue eliminado. Un listado de deseos rechazados y sus justificativas correspondientes podrán ser utilizados en proyectos futuros.

Los artículos que no fueron eliminados dejarán de ser deseos y ganaran el estatus de “entregables potenciales”. A partir de este momento, estos entregables potenciales pertenecerán a una lista de requisitos del proyecto, donde se realizará un análisis todavía más riguroso.

Una vez realizado este filtro final, la lista de requisitos, ampliamente justificada y detallada, formará parte de la línea base de alcance (que será la EDT, descrita en la sección 5.3) y, partir de ahí, se empezarán a desarrollar las líneas base de tiempo y coste del proyecto.

En un proyecto pequeño, este filtro podrá ser realizado por todos los interesados presentes. En proyectos grandes, normalmente se forma una junta para realizar esta gestión. Esta técnica co-rresponde a un grupo de técnicas ampliamente explicada en el proceso de definición del alcance, sección 5.2, del capítulo 5.

46


2.5. Caso Práctico

Cuando hablamos del Project Management, lo primero que nos viene a la mente son los grandes proyectos tecnológicos, o de ingeniería. Como he comentado al principio, un proyecto posee carac-terísticas bien definidas que pueden encajar perfectamente tanto en emprendimientos profesionales como personales. Por esta razón, terminaremos este capítulo utilizando los conceptos anteriormente explicados (actividades, fases, procesos y entregables) en un proyecto personal muy importante: la realización de una boda. De esta forma, podremos visualizar de una forma muy sencilla dos cosas: cómo estos conceptos se aplican en la práctica y cómo un proyecto personal puede perfectamente ser administrado utilizando las técnicas del Project Management.

La boda de Jacobo y Marta

Jacobo y Marta se van a casar en verano, precisamente en el mes de septiembre. Quieren disfrutar de las agradables temperaturas del final de la estación y aprovechar las ofertas de viaje que por estas épo-cas suelen ser menos concurridas que en los meses de julio y agosto. Ambos saben que la celebra-ción de una boda conlleva a la administración de una serie de factores que incluyen, entre otras cosas:

– Un presupuesto.

– Una fecha que no puede ser aplazada.

– La contratación de profesionales que actuarán de forma coordinada en el día de la celebración de su boda.

Como es natural, los novios tienen un alto grado de expectativa en relación a este evento que, sin duda, es inolvidable en la vida de cualquiera. Para ello, contrataron el personal que formará el equipo (fotógrafo, florista, imprenta, músicos...), a través de recomendaciones muy fiables. Además, ambos tuvieron el cuidado de planificarlo todo con mucha antelación.

A partir de esta introducción, empezaremos a definir el conjunto de actividades, fases y procesos que fue-ron conceptualmente explicados anteriormente y organizarlos en el proyecto de la boda de Jacobo y Marta:

La lista de actividades

1. Planificación y definición de la fechas.

2. Búsqueda, acuerdos y contratación de la iglesia.

3. Búsqueda, acuerdos y contratación del florista.

4. Búsqueda, acuerdos y contratación de los músicos.

5. Búsqueda, acuerdos y contratación de la imprenta.

6. Búsqueda, acuerdos y contratación del modista.

7. Búsqueda, acuerdos y contratación del fotógrafo.

8. Búsqueda, acuerdos y contratación del restaurante.

9. Búsqueda, acuerdos y contratación del viaje de luna de miel.

10. Búsqueda, acuerdos y contratación del alquiler de un coche.

47

C2

11. Preparación de la lista de invitados.

12. Envío de las invitaciones.

13. Primera prueba del vestido.

14. Segunda prueba del vestido.

15. Tercera prueba del vestido.

16. Primera prueba del traje.

17. Segunda prueba del traje.

18. Llamadas de confirmación a los profesionales contratados.

19. Ejecución de la boda.

20. Celebración en el restaurante.

Podríamos tener, por lo tanto, las siguientes fases:

21. Búsqueda y contratación de profesionales.

22. Pruebas de indumentaria.

23. Gestión de invitaciones.

24. Llamadas de seguimiento y verificación.

25. Realización de la boda.

26. Celebración final.

Fases y personal implicado (interesados)

Fases Personal implicado

1Búsqueda y contratación

de profesionales

Novios, familiares, amigos y los profesionales implicados (perso-nal de la iglesia, florista, músicos, imprenta, modista, fotógrafo, personal del restaurante, alquiler de un coche y agencia de viajes)

2 Pruebas de indumentaria Novios y modista

3 Gestión de las invitaciones Novios y familiares

4Llamadas de seguimiento

y verificaciónNovios, familiares y profesionales implicados correspondientes

5 Realización de la boda Novios, familiares y profesionales implicados correspondientes

6 Celebración final Novios, familiares y profesionales implicados correspondientes

48


Distribución de las actividades en las fases

Fase Actividades Entregables

Confeccionar plan Inicial

Planificación de fechas

Plan de la bodaDimensión de la ceremonia

Búsqueda de profesionales

Realizar contrataciones

Contratación de iglesia

Contratos de servicios

Contratación de florista

Contratación de músicos

Contratación de imprenta

Contratación de modista

Contratación de fotógrafo

Contratación del restaurante

Contratación del viaje

Alquiler de un coche

Realizar las pruebas

1ª prueba del vestido

Ropas aprobadas



1ª prueba del traje

2ª prueba del traje

Ejecutar gestiones prenupciales

Confección del listado de invitados

Confirmaciones de invitados y profesionales

Envío de invitaciones

Llamada a los contratados para confirmar las gestiones oportunas

Llamada a los invitados para confirmar la recepción de invitación

Realizar la boda Realización de la ceremonia Boda realizada

Celebrar Realización de la cena Cena realizada

Viajar Viaje de luna de miel Viaje realizado

C3Áreas de conocimiento

50


3.1. El Project Manager, ¿nace o se hace?3.2. Las responsabilidades de un Project Manager3.3. Las habilidades del Project Manager

51

¿Qué tienes que saber acerca del Project Management?

El Project Management para muchos es un arte. También podemos decir que es una ciencia, una metodología, una disciplina o, incluso, una filosofía. Gestionar un proyecto conlleva, entre otras cosas, aplicar conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para satis-facer sus requisitos. Es un proceso por el cual se planifica, ejecuta y controla, buscando alcanzar los resultados deseados.

Figura 15: Los elementos del Project Management

costes

comunicaciones

alcance compras

documentación

calidad

integración

tiempo

riesgo

ProjectManager

52


Un proyecto, por su naturaleza, necesita de una figura central que pueda conducirlo al éxito, gestionar las expectativas de los interesados y proporcionar los medios y los esfuerzos necesarios para que un proyecto finalice acorde con su plan. Es una práctica bastante distinta de las llevadas a cabo por algunas organizaciones que ponen en marcha proyectos sin dueño, o “sin padre”, o con muchos dueños, cuyas responsabilidades no son claras y, a la hora de un posible éxito, todos quieren llevarse los méritos; por otro lado, cuando ocurre lo contrario, no resta nadie para asumir la responsabilidad.

La persona que buscamos para asumir todos estos compromisos es el Project Manager, que será el encargado de gestionar toda una serie de procesos y áreas de conocimiento que interaccionan entre sí y tienen grados de complejidad distintos.

En las obras publicadas en inglés, los términos Project Manager y Project Management son concep-tos muy claros y, por ello, no es frecuente que aparezcan otros términos para definir dichos concep-tos. Por otro lado, en las obras escritas o traducidas en español, el Project Manager puede aparecer como “Gerente de Proyectos”, “Gestor de Proyectos”, “Director de Proyectos” o “Administrador de Proyectos”. De la misma forma, el Project Management, a veces, es traducido como “Gerencia de Proyectos”, “Gestión de Proyectos”, “Dirección Integrada de Proyectos” o “Administración de Proyectos”. Cada uno de estos términos puede tener diferentes matices y/o interpretaciones y, por lo tanto, son muchas veces utilizados sin un criterio correctamente definido.

Para evitar confusiones, esta obrará mantendrá los términos originales del inglés de Project Manager y Project Management.

Organización de la obra

Igual que las distintas fases de un proyecto, los capítulos de este libro son independientes, pero, al mismo tiempo, se enlazan entre sí. El contenido está dividido de esta forma:

– Capítulo 1 - Introducción: Presenta los conceptos básicos del proyecto, la definición de Project Management y los personajes implicados.

– Capítulo 2 - Ciclo de vida del proyecto: El ciclo de vida del proyecto es el conjunto de acti-vidades necesarias para alcanzar el objetivo del proyecto. Estas actividades son organizadas o agrupadas en fases para facilitar su gestión.

– Capítulo 3 – Área de Conocimiento: El director de proyecto debe dominar diversas áreas de conocimiento necesarias para una gestión adecuada del proyecto. Las áreas de conocimiento son disciplinas de gestión que son aplicables a cualquier campo de la gestión empresarial y que en el caso de la dirección de proyectos son adaptadas a la naturaleza y características de esto.

– Capítulo 4 - Dirección de la integración: Incluye los procesos, técnicas, herramientas y docu-mentos necesarios para asegurar que los varios elementos del proyecto estén adecuadamente coordinados.

– Capítulo 5 - Dirección del alcance: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que el proyecto incluya todo el trabajo necesario, y solamente el nece-sario, para completar el trabajo con éxito.

– Capítulo 6 - Dirección de plazos: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar la planificación y la ejecución del proyecto en un plazo adecuado. Esta área incluye también el levantamiento de las actividades del proyecto (su definición, secuencia y duración estimada).

53

C3

– Capítulo 7 - Dirección de costes: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que el proyecto será ejecutado dentro del presupuesto aceptado. Esta área incluye también las estimaciones de los costes del proyecto, la asignación del presupuesto y el control de los costes.

– Capítulo 8 - Dirección de la calidad: Incluye los procesos, técnicas, herramientas y documen-tos necesarios para asegurar que el proyecto irá satisfacer las necesidades por las cuales fue iniciado. Esta área también incluye la planificación, la garantía y el control de la calidad.

– Capítulo 9 - Dirección de RRHH: Incluye los procesos, técnicas, herramientas y documentos necesarios para realizar el uso más efectivo de las personas involucradas en el proyecto. Esta área también incluye la planificación organizacional, la formación y el desarrollo del equipo del proyecto.

– Capítulo 10 - Dirección de comunicación: Incluye los procesos, técnicas, herramientas y docu-mentos necesarios para asegurar la adecuada generación, diseminación y almacenamiento de las in-formaciones del proyecto. Esta área también incluye la planificación y la distribución de la información.

– Capítulo 11 - Dirección de riesgos: Incluye los procesos, técnicas, herramientas y los docu-mentos relacionados con la identificación y análisis de los riesgos del proyecto. Esta área también incluye la identificación de los riesgos, su cuantificación y establecimiento de medidas preventivas y correctivas.

– Capítulo 12 - Dirección de compras: Incluye los procesos, técnicas, herramientas y documen-tos necesarios para la adquisición de bienes y servicios fuera de la organización ejecutora del pro-yecto. Esta área también incluye la confección de plan de compras, levantamiento de potenciales proveedores, licitaciones, contratación, administración y cierre de contratos.

El Project Manager

Una de las contribuciones más importantes que el Project Management pudo aportar fue la institucio-nalización de la figura del Project Manager. A partir del momento en que las organizaciones empeza-ron a encargar la gestión de sus proyectos a una figura central que fuera capaz de administrar todas sus variables, los proyectos empezaron a contar con más posibilidades de éxito.

Jack Guido y James P. Clements, en su libro Administración Exitosa de Proyectos, afirman (muy acer-tadamente): “Son las personas – no los procedimientos ni las técnicas – las que son criticas para lograr el objetivo del proyecto. Los procedimientos y las técnicas son simplemente herramientas para ayudas a las personas a realizar sus trabajos”. Un proyecto debe tener una figura central que sea el responsa-ble por su éxito y por su fracaso. Es una práctica bastante distinta de las llevadas a cabo por algunas organizaciones que ponen en marcha proyectos “sin dueño”, o “sin padre”, o con muchos dueños, cuyas responsabilidades no son claras y, a la hora de un posible éxito, todos quieren llevarse los mé-ritos. Sin embargo, en el caso de un muy probable fracaso, será difícil que alguien se responsabilice.

La responsabilidad final del Project Manager es asegurar la ejecución del proyecto dentro del plazo y de los costes estimados, garantizando la calidad de los servicios y productos entregados. Esto exige una administración eficaz de todas las disciplinas que hemos analizado en este libro: la comunicación, los recursos humanos, los contratos, el alcance, los riesgos, los costes, entre otros. Esta responsabi-lidad podrá variar en función de la complejidad del proyecto, del tipo de la organización que lo ejecuta, del interés del cliente, entre otros factores.

Además de las responsabilidades inherentes del cargo, el Project Manager también deberá ser poseedor de grandes capacidades. El Project Manager, más que nada, actúa como un integrador. Su papel, entre otras cosas es el de resolver conflictos y prestar atención a lo que dicen los patrocinadores del proyecto. En el proyecto, será el responsable en la planificación, supervisión y control de los trabajos ejecutados.

54


3.1. El Project Manager, ¿nace o se hace?

Como podremos ver a continuación, la profesión de Project Manager exige una cierta “vocación”, dada a la cantidad de talentos que el profesional debe poseer, como por ejemplo: liderazgo, capaci-dad de resolución de conflictos, capacidad de organización, planificación y en muchos de los casos, capacidad de actuar como un psicólogo. Por todo ello, la pregunta que proponemos, si un Project Manager nace o se hace, casi podemos decir que un poco de los dos. Un profesional que a lo largo de los años, acumule experiencia en proyectos y reciba una formación adecuada y completa, puede llegar a ser un excelente Project Manager. Sin embargo, existen algunas capacidades que la expe-riencia y la formación no pueden proporcionar. Si no se nace con ellas, la dificultad de asumir ciertas responsabilidades será, sin duda, mayor.

3.2. Las responsabilidades de un Project Manager

El Project Manager es un puesto de indudable importancia en el ámbito del Project Management. No lo nombraría como el principal agente de un proyecto, ya que el grado de dependencia del Project Manager en relación al cliente, a su equipo y a los patrocinadores es muy alto. No obstante, no hay duda de que un proyecto necesita de una figura central que conduzca toda la evolución de un pro-yecto. Su responsabilidad en la organización recae en tres aspectos:

– El proyecto: Es la responsabilidad más obvia de un Project Manager. Cuando asume un proyec-to, se espera que el Project Manager reúna las condiciones necesarias para gestionar correcta-mente los costes, plazos, alcances y el equipo adjudicado.

– La organización: El proyecto que será administrado por el Project Manager pretende proveer beneficios a la organización. Algunos proyectos tienen poca visibilidad y muchas veces, tienen un alcance tan sencillo, que en pocas semanas puede ser finalizado. Sin embargo, hay casos frecuentes de proyectos que generan una expectación muy grande, por su complejidad, por su importancia, pero sobre todo por las ganancias y oportunidades en el mercado que la empresa obtendrá con su desarrollo. Se espera que el Project Manager ejerza su actividad respetando la política de la empresa, los códigos profesionales de conducta y la ética (informando de forma honesta todos los resultados del proyecto, sean buenos o no).

– El equipo: El Project Manager deberá suministrar toda la información necesaria para que el equipo puede desarrollar correctamente sus actividades. Es importante que se establezca desde el principio un canal de comunicación eficaz, con dialogo abierto y oportunidades para los miembros se sientan confortables en hacer sus sugerencias y demandas. Además, es de responsabilidad del Project Manager mantener el equipo unido, motivado y con ganas de llevar a cabo el proyecto, y eso no es tarea fácil. Cada ser humano tiene expectativas, motivaciones, valores e ilusiones distintas.

3.3. Las habilidades del Project Manager

Un Project Manager de éxito debe reunir una serie de habilidades y capacidades que le permitirá con-ducir correctamente su equipo de trabajo y el proyecto por lo cual ha sido asignado. Las principales habilidades son las siguientes:

– Planificador: La clave de una exitosa ejecución de un proyecto es una buena planificación. Como planificador, el Project Manager deberá asegurar que antes de la ejecución de los trabajos, se reserve una cantidad de tiempo razonable para que se pueda preparar un plan que garantice la participación de los recursos necesarios, el desarrollo de un cronograma viable y sobre todo el consenso de todos los interesados involucrados en el proyecto.

55

C3

– Integrador: Quizás sea su principal papel. El Project Manager no puede ver solamente un árbol. Tiene que conocer toda la floresta, es decir que su enfoque tiene que ser más amplio que los demás, un proyecto es estructurado a partir de diversas variables que se interrelacionan entre si, y que muchas veces son conflictivas.

– Comunicador: Si no se desarrolla una comunicación adecuada con los interesados, será muy difícil llevar a cabo el proyecto sobre todo dentro de los plazos estimados. Además de mantener un nivel de comunicación adecuado con su equipo, el Project Manager deberá mantener este mismo nivel de comunicación con su gerente, con el cliente y con todos los interesados que ejercen una influencia directa en el proyecto.

– Líder: Para poder gestionar el proyecto de manera eficaz, es fundamental que el Project Manager sepa desarrollar su liderazgo. Conocer bien el producto o servicio que se desarrolla, conocer la política de la organización, saber negociar, mantener buenas relaciones con todos los interesa-dos y proveer información a todos son maneras de crear confianza y demostrar liderazgo en el proceso de conducción del proyecto. El liderazgo quizás sea el atributo más difícil para un Project Manager, ya que para ello es necesario casi un talento nato, un carisma que sea capaz de motivar todo el equipo de forma que todos trabajen unidos hacia un objetivo común. Existe una tendencia en el mercado de seleccionar a un Project Manager solamente por sus habilidades técnicas o por su formación académica. Si bien la experiencia y el conocimiento sean fundamentales para el desarrollo de su actividad, nunca podrán reemplazar a la función de un líder.

– Administrador del tiempo: Se suele decir que el tiempo es un bien escaso, que una vez perdido, no se recupera jamás. Para el Project Manager, el tiempo es una restricción importante y por esta razón, tendrá que saber gestionarla correctamente.

– Administrador de Personal: Administrar personas no es lo mismo que administrar materiales, costes o plazos. El Project Manager deberá establecer un ambiente adecuado donde las per-sonas puedan desarrollar sus tareas, y tendrá que estar capacitado para lidiar con los conflictos, expectativas y frustraciones que surgirán a lo largo del proyecto.

– Negociador: Negociar significa discutir con otras personas con el objetivo de alcanzar un acuer-do. Estos acuerdos pueden ser negociados directamente o a través de un intermediario. La nece-sidad de una negociación, normalmente proviene del surgimiento de un conflicto, y dependiendo de la naturaleza del conflicto de las personas involucradas en ello, es necesario establecer una determinada estrategia.

Gary R. Heerkens, en su libro Project Management, hace mención a lo que el define como “habilida-des extraoficiales”:

– Canguro: Aunque personalmente no me guste el término, esta denominación se refiere a la nece-sidad del Project Manager de dar instrucciones y supervisar al grupo, y a veces, a algunos indi-viduos de forma especial, sobre todo cuando estos no demuestran tener la autonomía suficiente para poder desarrollar su labor.

– Comercial: En muchos proyectos de índole técnica, la presencia de un Project Manager puede significar para los técnicos un supuesto incremento de documentación y burocracia en el proyec-to. El Project Manager tiene que tener la capacidad de saber “vender” su forma de trabajo y sobre todo ser capaz de ganar la confianza de los implicados en sus apuestas.

– Profesor: Project Managers veteranos pueden aportar una cantidad importantísima de “leccio-nes aprendidas” y desarrollar labores de formación que proporcionarán al grupo conocimientos, seguridad y confianza.

– Amigo: Mantener una relación profesional y de amistad dentro del entorno de trabajo es difícil. No obstante, si el Project Manager es capaz de lograrlo, podrá formar un grupo implicado entre si y volcado a los intereses principales del proyecto. Una comunicación abierta, informal y sincera aportará al Project Manager una cantidad importante de información que un sistema formal, ce-rrado y burocrático quizás no sería capaz de hacerlo.

56


C4Dirección de la integración

58


4.1. Desarrollo del acta de constitución del proyecto (proceso que corresponde a la fase de inicio del proyecto)4.1.1. Técnicas y herramientas

4.2. Desarrollo del plan de proyecto (proceso que corresponde a la fase de planificación del proyecto)4.2.1. Técnicas y herramientas

4.3. Gestión y ejecución del plan de proyecto (proceso que corresponde a la fase de ejecución del proyecto)4.3.1. Técnicas y herramientas

4.4. Monitorización y control del trabajo del proyecto (proceso que corresponde a la fase de control del proyecto)4.4.1. Técnicas y herramientas

4.5. Control integrado de cambios (proceso que corresponde a la fase de control del proyecto)4.5.1. Técnicas y herramientas

4.6. Cierre del proyecto o fase (proceso que corresponde a la fase de cierre del proyecto)4.6.1. Técnicas y herramientas

59

Algunas cosas en las que NO puedes pensar acerca de la dirección de la integración

“No podemos esperar la aprobación formal de cambios. Hazlo ya”

Un proyecto es un emprendimiento que afecta a una serie de variables integradas entre sí (costes, plazos, recursos humanos, calidad...). Uno de los grandes desafíos del Project Manager es ejecu-tar un proyecto “tal y como ha sido planificado”, y para ello, es importante evitar que se produzcan cambios. Cuando esto es inevitable, el Project Manager tendrá que hacerlo de forma planificada, documentada y aprobada por las partes afectadas, puesto que un cambio mal introducido podría desestabilizar todo el proyecto.

Introducción

La dirección de la integración consiste en asegurar la integración y coordinación de los elementos del proyecto que compiten entre sí.

Figura 16: Integración de las áreas de la aplicación en un proyecto. El objetivo principal de la dirección de la integración es coger todas las áreas de aplicación del proyecto y literalmente “integrarlas” en una gran y única pieza, como si de un engranaje se tratara.

RIESGO

TIEMPO

CALIDAD

CONTRATOSCOMUNICACIÓN

RRHHCOSTE

ALCANCE

INTEGRACIÓN

60


El Project Manager es, ante todo, un integrador, y por ello, la dirección de la integración tiene que ser la más importante desde su punto de vista, puesto que él es la única persona que debe cono-cer y tener la visión total del proyecto. Su responsabilidad reside en asegurar el buen avance del proyecto, realizando un seguimiento adecuado y poniendo en marcha las acciones preventivas y/o correctivas adecuadas.

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección de la integración de un proyecto inclu-ye procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar todos los procesos de la gestión de proyectos. Son ellos:

– Desarrollar el acta de constitución del proyecto.

– Desarrollar el plan para la dirección del Proyecto.

– Dirigir y gestionar la ejecución del proyecto.

– Monitorizar y controlar el trabajo del proyecto.

– Realizar el control integrado de cambios.

– Cerrar el proyecto o fase.

4.1. Desarrollo del acta de constitución del proyecto (proceso que corresponde a la fase de inicio del proyecto)

El objetivo de este proceso es autorizar formalmente el inicio de un proyecto o fase, documentando sus requisitos iniciales, necesidades, objetivos y expectativa de los interesados. Esta autorización nor-malmente viene de un interesado externo, como puede ser, por ejemplo, un patrocinador. La presen-cia del Project Manager en la elaboración de este documento es muy recomendada, puesto que es el documento que otorgará al Project Manager la autoridad necesaria para disponer de los recursos asignados al proyecto.

4.1.1. Técnicas y herramientas

4.1.1.1. Juicio de expertos (Expert judgement)

El juicio de expertos es muy útil para poner en marcha este proceso. Esta colaboración puede venir tanto de un especialista como de un grupo de personas con mucha experiencia o que ha asistido a alguna formación especializada y que puede aportar muchas informaciones. Entre ellos, se incluyen los consultores, los integrantes del equipo del proyecto, algún proveedor especializado...

* Nota del autor: En todas las empresas en que he trabajado, me he encontrado con profesionales que tenían siempre mucho que aportar. No existe escuela que enseñe más que la experiencia, y por ello, disponer de la opinión de un profesional experi-mentado es un recurso imprescindible para tomar la decisión correcta.

61

C4

4.2. Desarrollo del plan de proyecto (proceso que corresponde a la fase de planificación del proyecto)

Este proceso es el que define, prepara, integra y coordina todos los planes subsidiarios del proyecto (riesgos, calidad, alcance, costes...). Es quizás el documento más importante de un proyecto, puesto que contiene las estimaciones, los objetivos, las responsabilidades y todo lo que se refiere a la plani-ficación del proyecto. Su elaboración progresiva y su actualización constante lo hacen imprescindible en la gestión de cualquier proyecto.

El plan de proyecto es un documento formal y aprobado por la dirección y es utilizado principalmente para la administrar las fases, interacciones, actividades y toda la planificación de un proyecto.

El plan de proyecto, tiene fundamentalmente, los siguientes objetivos:

– Organizar el proyecto: El plan de proyecto contiene una estructura que permite localizar fácil-mente cualquier información, como el cronograma, el equipo asignado, sus funciones y respon-sabilidades, restricciones, entre otros.

– Generar documentación: Como podremos observar en los capítulos siguientes, la gestión co-rrecta de un proyecto implica en la confección de una serie de documentos que van siendo incorporados al plan de proyecto. Uno de los factores de éxito de un proyecto es la correcta confección y actualización de su documentación, que además servirá como una valiosa fuente de consulta histórica para futuros emprendimientos similares.

– Proveer información: Un plan de proyecto es un documento que se actualiza en función del avance de los trabajos, ofreciendo a cualquier interesado, una visión exacta de todas las estima-ciones realizadas y el estado actual en que se encuentran.

– Gestionar las líneas base: Cuando se inicia un nuevo proyecto, se elaboran sus líneas base, que, normalmente, son de costes, plazos y de alcance. A partir de estas líneas base, se estable-cen todas las previsiones iniciales, con lo cual es fundamental que se encuentren actualizadas y que reflejen fundamentalmente el estado actual que el proyecto se encuentra.


4.2.1.1. Metodología de planificación del proyecto (Project plan methodologies)

Cualquier enfoque estructurado que permita guiar el equipo hacia un plan sostenible y eficaz es válido para el desarrollo del plan de proyecto. No importa si la metodología es sencilla, como la utilización de formularios o plantillas estándar, o compleja, como, por ejemplo, el uso de un software del Project Management integrado (descrito en la sección 6.3.1.4). Normalmente, una organización utiliza una serie de técnicas combinadas que les auxilia en la elaboración de un plan de proyecto eficiente, como las que son presentadas en este libro.

No obstante, uno de los recursos más valiosos que una organización puede tener es su “capital in-telectual”. Los conocimientos y habilidades de los involucrados en el proyecto son cruciales para el buen desarrollo del plan de proyecto (ver sección a continuación).

4.2.1.2. Conocimientos y habilidades de los interesados (Stakeholder´S knowledge and habilities)

Un plan de proyecto incluye una serie de estimaciones de costes y de plazos, además de un análisis de los riesgos del proyecto, entre muchas otras cosas. La confección de un plan de proyecto eficaz dependerá sobre todo de los conocimientos y habilidades de su equipo, de los patrocinadores o de cualquier persona que esté involucrada. El Project Manager debe proporcionar los medios para que los interesados puedan desarrollar y aportar las informaciones adecuadas.

62


4.2.1.3. Sistema de información de gestión de proyectos (Project management information system – PMIS)

El Project Management information system (PMIS) es una herramienta utilizada en el Project Mana-gement para recoger, tratar y distribuir la información a través de medios electrónicos o manuales. Un ejemplo de PMIS es el Microsoft Project que ayuda a estar al día y controlar el trabajo, la programa-ción y el presupuesto de los proyectos. Otro programa que se encaja en este ámbito, es el Microsoft Outlook que administra el tiempo, el calendario, los contactos y la información enviada y recibida por las personas involucradas en el proyecto.

4.2.1.4. Valor del trabajo realizado (Earned value management)

Descrito en la sección 7.3.1.1.



4.3. Gestión y ejecución del plan de proyecto (proceso que corresponde a la fase de ejecución del proyecto)

Este es el proceso que pone en marcha todo lo definido en el plan de proyecto y que realiza la implantación de cualquier cambio resultante de acciones correctivas y/o preventivas. Este proceso incluye, además, los esfuerzos necesarios para alcanzar los resultados determinados por el plan de proyecto.

La ejecución de un plan de proyecto eficaz conlleva al desarrollo de las siguientes actividades:

– Concluir con éxito las actividades que forman parte del proyecto.

– Alinear el equipo con los objetivos del proyecto.

– Gestionar el progreso de los trabajos.

– Incentivar la fluidez de la comunicación entre los involucrados.

– Desarrollar acciones preventivas.

– Utilizar técnicas y herramientas de gestión.

– Realizar reuniones periódicas.

– Identificar y monitorizar desvíos.

– Poner en marcha acciones correctivas, cuando sea necesario.

Estas son tareas típicas de la fase de ejecución y control, que es la fase en que el plan de proyecto es, de hecho, puesto en marcha.

63

C4


4.3.1.1. Habilidades de gestión en general (General management hability)

La responsabilidad final del Project Manager es asegurar la ejecución del proyecto dentro del plazo y de los costes estimados, garantizando la calidad de los servicios y productos entregados. Esto exige una administración eficaz de todas las disciplinas que hemos analizado en este libro: la comunicación, los recursos humanos, los contratos, el alcance, los riesgos, los costes, entre otros. Esta responsabi-lidad podrá variar en función de la complejidad del proyecto, del tipo de la organización que lo ejecuta, del interés del cliente, entre otros factores.

4.3.1.2. Conocimientos acerca del producto y/o servicio (Knowledge on the product and/or service)

Como ya hemos comentado, unas de las características más importantes del Project Manager es la de líder. No obstante, para ejercer el liderazgo y defender su posición en momentos críticos del proyecto, el Project Manager tiene que ser capaz de hablar con los involucrados más importantes del proyecto (el cliente, el equipo, el patrocinador...) con mucha propiedad, y para ello, es imprescindible tener am-plios conocimientos acerca del producto o servicio resultante del proyecto que se está desarrollando.

Conocer a fondo el servicio y/o producto que será generado, aportará al Project Manager, algunas ventajas importantes, como por ejemplo:

– Selección de los proveedores más adecuados.

– Respuesta adecuada a los eventuales riesgos.

– Equilibrio entre costes, tiempo, alcance y calidad.

– Mejora en la comunicación entre los interesados.

– Reducción de la incertidumbre.

– Mejor control general en la ejecución del proyecto.

Para ello, es importante entender cómo el producto o servicio será desarrollado, su valor (comercial, estratégico...), sus funcionalidades, sus fortalezas y eventuales debilidades.

4.3.1.3. Sistema de autorización de trabajo (Work authorization system – WAS)

El sistema de autorización de trabajo (conocido como Work authorization system - WAS en inglés), es un procedimiento que determina las acciones necesarias para autorizar u obtener la autorización de la ejecución de un determinado trabajo. Este procedimiento debe incluir también la documentación y los requisitos necesarios para ejecutar este tipo de gestión. Este documento es muy utilizado, además, para gestionar y mantener bajo control los trabajos que no formen parte del alcance previsto, evitando de esta forma, que se produzcan incidencias en los costes, plazos o consumo de recursos del proyecto.

El sistema de autorización de trabajo funciona básicamente de la siguiente forma:

– Uno de los integrantes del equipo del proyecto redacta un “Documento de autorización de trabajo” (Work authorization document – WAD. Este documento es enviado al Project Manager (o a las personas con autorización para aprobar este tipo de solicitud) donde se describe el trabajo (o el listado de trabajos) que necesitan ser ejecutados.

64


– El Project Manager reenvía el WAD a los departamentos correspondientes para que se especi-fiquen las fechas hábiles, las duraciones, costes y recursos estimados para el desarrollo de los trabajos listados en el WAD.

– El personal encargado realizará las eventuales comprobaciones que correspondan (sobre todo en lo que se refiere a las estimaciones generales de los trabajos) y devolverá el WAD al Project Manager con toda la información necesaria para que se juzgue su viabilidad.

– Cuando el WAD haya sido aprobado y firmado por todas las partes involucradas, el Project Ma-nager autorizará el inicio de los trabajos.

– Este documento formará parte de todo el ciclo de vida del proyecto y su contenido podrá ser incrementado con nuevos trabajos, valores, plazos o cualquier cambio relevante que haya sido debidamente aprobado previamente.

4.3.1.4. Evaluación de progresión o reuniones de seguimiento (Follow–up meetings)

Las reuniones de seguimiento tienen como principales objetivos verificar el avance de un proyecto, intercambiar informaciones y revisar las estimaciones, entre otras cosas.

Es imprescindible incluir estas reuniones como una actividad del cronograma del proyecto, puesto que suelen consumir un tiempo considerable y deben tener una frecuencia regular, para proporcionar un seguimiento coherente al proyecto.

En el capítulo 10, “Dirección de la comunicación”, se amplía detalladamente la forma correcta de organizar una reunión de seguimiento.

4.3.1.5. Sistema de información de gestión de proyectos (Project Management information system – PMIS)

Descrita en la sección 4.2.1.3.

4.3.1.6. Procedimientos de la organización (Organization procedures)

Las organizaciones deben establecer procedimientos que les permitan desarrollar su trabajo obede-ciendo una serie común de pasos claramente definidos, que posibiliten la ejecución de cada tarea correctamente, reduciendo la probabilidad de errores.

Estos procedimientos pueden ser de índole técnica, administrativa u operacional, deben estar clara-mente definidos y no deben ser excesivos.



65

C4

4.4. Monitorización y control del trabajo del proyecto (proceso que corresponde a la fase de control del proyecto)

Este es el proceso en el que se puede notar una actuación intensiva por parte del Project Manager. Su labor incluye recolectar, medir y distribuir la información de rendimiento del proyecto, a la vez que elabora tendencias, ajusta métricas, mejora procesos y, sobre todo, trabaja para mantener el proyecto en su curso planificado.




4.5. Control integrado de cambios (proceso que corresponde a la fase de control del proyecto)

Este es el proceso donde se decide si un cambio solicitado podrá ser implementado o no, acorde con un procedimiento previamente establecido. Los cambios en un proyecto son inevitables y pueden ser solicitados por cualquier interesado del proyecto, impuesto por alguna ley o exigido por factores relacionados con la competencia y/o el mercado. La implantación de un cambio es una gestión que se hace de forma planificada, valorando, sobre todo, su impacto y las posibles consecuencias.

Nadie puede asumir que un proyecto será ejecutado sin que se produzcan cambios. Cualquier tipo de proyecto, durante su ciclo de vida, estará sujeto a modificaciones que podrán repercutir tanto en el alcance como en sus plazos y costes. En proyectos como los de la construcción, que suelen ser más estables, algunos cambios no llegan a afectar el desarrollo del proyecto. En proyectos más sensibles, como son los de informática, un único cambio, dependiendo de su dimensión, puede llevar todo el proyecto al fracaso. El desafío del Project Manager consiste en cómo manejar estos cambios, mini-mizando los eventuales impactos provocados.

De los factores que normalmente generan cambios en un proyecto, podemos destacar:

– Cambios en los requisitos del cliente.

– Aprobación de leyes o reglamentaciones.

– Nuevas tecnologías.

– Cambios en el entorno macroeconómico.

Aparte de estos factores externos, frecuentemente nos podemos encontrar con proyectos que son débilmente estructurados: el equipo tiene un plan, pero no lo organiza de forma adecuada y, conforme el proyecto avanza, algunos conceptos se van aclarando mejor y, como consecuencia, las especifi-caciones anteriormente realizadas tendrán que ser modificadas. Hay casos en que se hace necesario parar el trabajo y empezarlo otra vez. Proyectos desarrollados de esta forma suelen consumir mucho más recursos que los asignados originalmente y difícilmente son terminados.

66


Por otro lado, aunque exista una planificación detallada, estructurada y bien organizada, el cambio puede ser inevitable. A medida que el proyecto avanza, se producen modificaciones, añadidos, ob-servaciones que hacen que la especificación original cambie y produzca un impacto en el trabajo planificado. En algunos casos, los cambios son el reflejo de la madurez del personal involucrado que ha evolucionado en su forma de pensar y ha decidido de alguna manera mejorar aspectos antes igno-rados que aportarán beneficios al proyecto sin perjudicar su línea base planificada.


4.5.1.1. Sistema de control de cambios (Change control System)

Casi todos los proyectos que son desarrollados sufren cambios por alguno motivo. Cuanto más largo y complejo sea un proyecto, mayor es la posibilidad de que sufra algún cambio. En casi todos los ca-sos, los cambios en un proyecto son inevitables, y por ello es importante estar preparado para afrontar el momento de realizar las eventuales acciones correctivas, cuando estos cambios ocurran.

De las situaciones más comunes de solicitud de cambios podemos destacar:

– La aprobación de una nueva ley.

– Una petición inesperada por parte del cliente.

– Un cambio de tecnología.

– Un cambio de estrategia organizacional.

– Un error o una omisión en la línea base del alcance.

También podemos encontrar las siguientes situaciones:

– El cliente solicita que se incluyan nuevos elementos al producto.

– El líder técnico solicita que se incrementen los plazos de entrega de un determinado elemento.

– Los técnicos solicitan la compra de nuevos equipos que no estaban previstos en el presu-puesto original.

– Una nueva ley puede frenar el desarrollo de un determinado componente.

– La competencia puede desarrollar algún tipo de producto que nos obligue a cambiar nuestra estrategia.

Un proyecto es estructurado de forma integral y cualquier cambio en el proyecto podrá repercutir en su estructura principal o provocar un determinado impacto. Para evitar que se produzcan cambios en un proyecto de forma arbitraria y sin planificación, se utiliza un sistema de control de cambios que establecerá la forma como un determinado cambio en el proyecto será administrado. Los cambios so-licitados deberán ser previamente analizados por una junta de expertos que se encargará de aprobar, rechazar o postergar las solicitudes de cambios. Esta junta de expertos normalmente está compuesta por líderes técnicos, consejeros y directivos que cuentan con la autoridad suficiente para aprobar o rechazar una solicitud de cambio.

67

C4

Las solicitudes de cambios se desarrollan a través de un procedimiento específico, según ilustra la figura 17. Las acciones deben estar respaldadas por una documentación que registre todo el proceso de solicitud de cambios.

Figura 17: Flujo de control de cambios del alcance

Solicitud de cambios: Es el proceso que permite a cualquier interesado solicitar una petición de cambio en el proyecto. A priori, se identifican las necesidades de realizar un determinado cambio en el proyecto y a continuación se genera un documento formal de solicitud de cambios, que será remi-tido al Project Manager.

Figura 18: Peticiones de cambio

INICIO

Identifica lanecesidad de

cambios

Cumplimenta lasolicitud de

cambios

Remite lasolicitud a la

Junta

Emite resultadodel estudio

¿Cambiosaprobados?Archivo

Refleja elcambios en la

documentacióndel proyecto

Realiza unseguimiento del

cambio realizado

FIN

PROJECT MANAGERJUNTA DE EXPERTOS

NO

Realiza estudiode impactos

SÍ

PETICIONESDE CAMBIO

PARAMETROSTECNICOS

POLITICAS YPROCEDIMIENTOS

ALCANCEDEL

PROYECTO

CRONOGRAMACOSTE O

PRESUPUESTO

DOCUMENTACIÓN EVENTOS DEFUERZAMAYOR

68


Revisión de la solicitud de cambios: Esta acción es realizada por el Project Manager que encargará a una junta de expertos la realización de un estudio que determine la viabilidad de dicha petición. Es importante resaltar que, en algunos casos, el propio Project Manager tiene la autonomía para rechazar esta petición, antes mismo de enviársela a la junta de expertos. De hecho, este proceso sirve como una especie de “filtro”, puesto que en algunos proyectos producen una cantidad desproporcionada de peticiones que muchas veces son contraproducentes.

Estudio de viabilidad: Cuando la petición de cambio ha pasado satisfactoriamente por la revisión del Project Manager, una junta de expertos realizará un estudio que determinará la viabilidad de cambio solicitado (descrito en la sección 4.5.1.2).

Los criterios aceptación de un cambio normalmente pasan por las siguientes evaluaciones:

– Requisitos necesarios para la puesta en marcha de los cambios solicitados.

– Posibles alternativas.

– Costes y beneficios.

– Riesgos.

– Posibles impactos en los costes, plazos, recursos y calidad del proyecto.

Después de realizar las evaluaciones anteriormente citadas, el estudio de viabilidad culminará con una de las siguientes conclusiones:

– Se podrá encajar el cambio solicitado sin afectar los recursos consumidos ni los plazos: Esta es la situación más sencilla y más optimista. Ocurre en los casos en que la junta de expertos analiza la petición de cambio y entiende que este cambio no será significativo lo suficiente para provocar cualquier impacto al proyecto.

– Se podrá encajar el cambio solicitado, pero afectará el plazo final del proyecto: En este caso, el plazo de conclusión del proyecto será aplazado para poder encajar el cambio solicitado, sin necesidad de incrementar los recursos utilizados.

– Se podrá encajar el cambio solicitado, sin cambiar el plazo, pero necesitará consumir más recursos: El proyecto necesitará de más recursos para poder realizar el cambio solicitado sin aplazar su plazo de finalización.

– Se podrá encajar el cambio solicitado, pero afectará el plazo final del proyecto y necesitará consumir más recursos: Los recursos y plazos disponibles no serán suficientes para encajar el cambio solicitado. Los cambios solicitados empiezan provocar impactos significativos.

– Se podrá encajar el cambio solicitado cambiando la estrategia del proyecto y priorizando las entregas más urgentes: Es muy frecuente que un proyecto sufra grandes cambios a lo largo de su ciclo de vida, que conllevan a modificaciones importantes en el plan, que exigirá una amplía revisión en la documentación del proyecto, de los plazos de entrega y del presupuesto.

– No se podrá encajar el cambio solicitado sin realizar un cambio radical en el proyecto: Hay ca-sos en que los cambios solicitados son tan drásticos que prácticamente anularía toda la planificación anteriormente realizada. El presupuesto, los plazos y los recursos estimados, todo tendría que ser total-mente revisado. En situaciones de esta magnitud la junta de expertos solo podrá optar por dos salidas:

∙ Rechazar el cambio solicitado y seguir con el proyecto original (aceptando todos los riesgos implicados).

∙ Anular el proyecto en marcha, planificarlo otra vez y arrancar un proyecto nuevo con los cambios incluidos (asumiendo todos las consecuencias que está decisión podrá provocar).

69

C4

Finalmente, tras realizar todos los análisis necesarios para determinar la decisión más adecuada a la petición de cambio, la junta de expertos emitirá un informe de respuesta a la solicitud de cambios que podrá contener las siguientes conclusiones:

– Rechazar la petición de cambio: Son muchas las razones por las que la junta de expertos po-dría rechazar una petición de cambio, como, por ejemplo, que los cambios solicitados puedan provocar un impacto importante que no generaría beneficios que justifiquen dicho cambio o que el cambio solicitado no añadiría ningún valor al proyecto o, asimismo, que los costes generados por dicho cambio podrán ser muy altos.

– Solicitar más información: Es posible que la junta de expertos no sea capaz de llegar a una conclusión, por la escasez de información remitida por la persona que ha solicitado el cambio. En este caso, la junta solicitará más datos para que se pueda realizar una investigación adecuada.

– Aprobar la petición de cambios: Si el cambio solicitado cumple con los requisitos determinados por la junta de dirección, esta procederá con la aprobación formal de esta solicitud.

– Aprobar la petición de cambio con restricciones: Hay casos en que la junta de expertos aprue-ba la petición de cambio, pero impone algunas restricciones. En este caso, el solicitante evaluará si los cambios propuestos podrán ser puestos en marcha bajo las restricciones impuestas por la Junta de Expertos.

Los criterios de aprobación o rechazo de una determinada solicitud de cambios normalmente tendrán en cuenta los siguientes criterios:

– Posibles impactos en el proyecto, derivados de la implantación de los cambios propuestos.

– Posibles impactos en el proyecto, derivados de la no implantación de los cambios propuestos.

Implantación: Consiste en implantar los cambios aprobados y autorizados por la junta de expertos. El Project Manager, entonces, remitirá al solicitante la autorización para la realización de los cambios, y realizará las siguientes gestiones:

– Comunicar a todos los involucrados del proyecto los cambios que serán realizados.

– Planificar la forma como los cambios serán implantados.

– Realizar la Implantación de los cambios previstos.

– Actualizar la documentación correspondiente.

Una buena gestión de cambios de un proyecto empieza en la línea base que debe ser establecida en el principio del proyecto, sobre todo porque la peticiones de cambios que vayan siendo aprobadas modificarán su estructura de modo que se quedará muy distinta a la línea base original. Sin embargo, la organización contará con importantes registros de los cambios solicitados, aceptados y rechazados que servirán de referencia en proyectos futuros similares. Además, con la línea base siempre actuali-

*Nota del autor: En los contratos confeccionados para el proyecto, es muy recomendable que se establezcan claramente quie-nes son las personas que tienen autoridad para iniciar y aceptar los cambios. La implementación de cambios no autorizados es frecuentemente la causa de muchas disputas, por ello, todo cambio solicitado solamente debe ser aceptado o rechazado por la(s) persona(s) autorizada(s) según establecido en una cláusula contractual correspondiente. Se trata de una medida preventiva que evitará una eventual pérdida de control sobre el proyecto debido a la implementación de cambios no autorizados.

Algunos de los cambios aceptados deberán ser incorporados de manera formal al contrato, puesto que podrán provocar mo-dificaciones importantes en los planes de gestión del proyecto, políticas, procedimientos, costes o cronogramas.

Por otro lado, pueden existir los cambios impugnados (reclamaciones, conflictos, apelaciones, etc.), que son aquellos cambios solicitados respecto de los cuales el adquiridor y el proveedor no logran acordar la compensación correspondiente debido a los mismos. Estos cambios son documentados, procesados y gestionados a lo largo del ciclo de vida del contrato, obedeciendo los términos contractuales acordados.

70


zada, será posible evaluar el impacto real de los cambios solicitados. Es importante que el Project Manager tenga el cuidado de preservar las líneas bases originales de alcance, costes y plazos para poder realizar comparativas entre las primeras líneas bases estimadas y las líneas base realizadas.

Figura 19: Proyecto realizado con pocos cambios en el alcance

Figura 20: Proyecto realizado con muchos cambios en el alcance

4.5.1.2. Estudio de viabilidad (Feasibility study)

Como su propio nombre indica, el estudio de viabilidad es una forma de determinar si un determinado cambio es viable. Se trata de una herramienta que nos ayudará a contestar una pregunta muy frecuen-te en el entorno empresarial: “¿Podemos seguir por este camino?”. El estudio de viabilidad es algo imprescindible y que debe ser realizado antes de poner en marcha un cambio. Sus resultados podrán ahorrarnos dinero y tiempo, además de prevenirnos de eventuales riesgos que quizás no serían co-rrectamente identificados al no realizarse este tipo de estudio.

LINEA BASE ORIGINALTRABAJO EJECTUADO

LINEA BASE ORIGINALTRABAJO EJECTUADO

71

C4

Un estudio de viabilidad completo deberá realizar el análisis de los siguientes apartados:

– Viabilidad técnica o tecnológica: A través de un análisis de las alternativas tecnológicas dispo-nibles para el proyecto, se determinan los requisitos y dificultades de implantación. Además, el estudio de la viabilidad técnica determinará si la empresa y su plantilla cuentan con la experiencia y el conocimiento suficientes para su desarrollo, y si los equipos disponibles pueden soportar los requisitos técnicos necesarios.

– Viabilidad financiera: El análisis financiero es uno de los estudios que se realizan con más frecuencia, ya que suele ser uno de los factores que determinan la aprobación de un cambio. Este estudio analizará la capacidad de la empresa en asumir los costes generados, si el cam-bio incrementará la receta de la empresa y consecuentemente, impactará positivamente en sus ganancias.

– Viabilidad legal: Determina si el cambio puede llegar a tener algún conflicto con la legislación vigente, como por ejemplo, alguna normativa medioambiental.

– Viabilidad operacional: Determinará si la empresa posee las condiciones necesarias o cuenta con los recursos apropiados para realizar un cambio.

– Viabilidad de plazos: Determina si el cambio podrá ser realizado dentro de un plazo viable.

– Viabilidad de mercado: Determinará si el cambio tiene salida comercial y si existe un mercado consumidor.

– Viabilidad de recursos: Este apartado contempla cuestiones acerca de la capacidad de la empresa de desarrollar el cambio propuesto en función de su plantilla, instalaciones, equipos, entre otros.

4.5.1.3. Gestión de la configuración (Configuration management)

Esta técnica es muy utilizada en entornos de desarrollo de software, debido, básicamente, a la inesta-bilidad que este tipo de proyecto conlleva. En el ámbito del desarrollo de software es un hecho común que los requisitos inicialmente establecidos cambien a medida que el proyecto evoluciona, muchas veces provocando errores que generan múltiples versiones del código fuente del programa.

Por todo ello, la gestión de la configuración es una técnica muy oportuna, puesto que permite llevar un correcto control de los cambios producidos a lo largo de la evolución del proyecto, manteniendo de esta forma, la integridad del producto, desde la fase de requisitos hasta alcanzar la fase final de pruebas, asegurando sobre todo:

– La validez de todo producto obtenido durante cualquiera de sus fases de desarrollo.

– La producción de cambios controlados.

– La disponibilidad de una versión única y estable para todos los involucrados que la manejan.

Esta gestión, además, facilita el mantenimiento del sistema, aportando la información adecuada que permitirá realizar una valoración del impacto de un cambio solicitado, reduciendo de esta forma, el tiempo de implantación de dicho cambio.

Una adecuada gestión de la configuración puede además, hacer un control global del sistema, aportar informaciones acerca del estado de su desarrollo y reducir el número de errores que puedan llegar a producirse, generando un sistema estable, fiable y acorde con los requisitos del cliente.

72


Según la gestión de la configuración definida en MÉTRICA v3, los elementos de configuración del software incluyen:

– Ejecutables.

– Código fuente.

– Modelos de datos.

– Modelos de procesos.

– Especificaciones de requisitos.

– Pruebas.

Y para cada uno de estos elementos se almacenará al menos:

– Nombre.

– Versión.

– Estado.

– Localización.

MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistema de TI pro-movida por el Ministerio de Administraciones Públicas del Gobierno de España para la sistemati-zación de actividades del ciclo de vida de los proyectos software en el ámbito de las administra-ciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination).

4.5.1.4. Informes de progreso (Progress report)

Los informes de progreso pueden ser muy útiles para realizar un control efectivo de los costes del proyecto, y, además, se trata de una forma muy sencilla de hacerlo. En muchos casos, el Project Manager determina cuánto trabajo ha sido realizado, solicitando a su equipo un porcentaje estimado del trabajo realizado en cada actividad. No obstante, en muchos casos, el equipo no tiene claro un criterio que determine realmente el porcentaje de avance de una determinada actividad, como por ejemplo decir que “en la actividad 5.4.2 está casi un 90%”. Este porcentaje no pasa de un sencillo “pálpito”, que poco o nada podrá aportar al control de costes del proyecto. De hecho, en muchos casos, encontramos actividades que han alcanzado rápidamente el 90% del trabajo realizado y luego se quedan en este porcentaje para siempre.

Es importante dividir todo el trabajo en paquetes de menor duración, como establece la EDT (descrita en la sección 5.3). De esta forma, trabajando con cortos plazos de finalización de estos paquetes, la estimación del trabajo realizado se vuelve más sencilla.

Por otro lado, existe una forma muy práctica de reportar el avance de un proyecto, sin recurrir a in-tuiciones sin fundamento. Se puede determinar con más exactitud, el avance de una determinada actividad a través de dos reglas diferentes:

73

C4

REGLA 50/50: La actividad obtiene un 50% de crédito cuando se inicia el trabajo, y el restante 50% se obtiene al finalizarlo.

Figura 21: Regla 50/50

REGLA 0/100: Una actividad es considerada 100% realizada cuando esté formalmente finalizada.

Figura 22: Regla 0/100

La principal ventaja de aplicar esta regla del 50/50, o la del 0/100, es que elimina la necesidad de determinar el porcentaje completado, que en la gran mayoría de las veces será un porcentaje equivocado.

4.5.1.5. Sistema de información de gestión de proyectos (Project management information system – PMIS)




4.5.1.7. Reunión de control de cambios (Change control meetings)

La reunión de control de cambios ocurre siempre que se produce una petición de cambio en un proyecto. Su objetivo es realizar un estudio acerca de una petición de cambio, sus consecuencias e impactos en el proyecto. Una junta de expertos se encargará de aprobar o rechazar los cambios so-licitados y, además, generará un informe con sus conclusiones. Esta reunión forma parte del sistema de control de cambios (descrita en la sección 4.5.1.1).

ACTIVIDAD

0% 50% 100%

ACTIVIDAD

0% 100%

74


4.6. Cierre del proyecto o fase (proceso que corresponde a la fase de cierre del proyecto)

En un proyecto, es importante que todo esté debidamente documentado. La documentación es una forma que el Project Manager tiene de controlar su avance, los cambios implementados y cualquier incidencia o información relevante.

Cuando se termina el proyecto o una de sus fases, el Project Manager deberá realizar una revisión general de todos los cierres de fases anteriores, asegurando de esta forma el correcto cumplimiento de los objetivos definidos. Cualquiera sea la razón por la cual un proyecto se haya finalizado, su cierre debe pasar por un proceso formal.




C5Dirección de la integración

76


5.1. Recopilar requisitos (proceso que corresponde a la fase de planificación del proyecto)5.1.1. Técnicas y herramientas

5.2. La definición del alcance (proceso que corresponde a la fase de planificación del proyecto)5.2.1. Técnicas y herramientas

5.3. Creación de la EDT (proceso que corresponde a la fase de planificación del proyecto)5.3.1. Técnicas y herramientas

5.4. Verificación del alcance (proceso que corresponde a la fase de control del proyecto)5.4.1. Técnicas y herramientas

5.5. Control de cambios del alcance (proceso que corresponde a la fase de control del proyecto)5.5.1. Técnicas y herramientas

77

Algunas cosas en las que NO puedes pensar acerca de la dirección del alcance

“¿Por qué no aprovechamos y le añadimos al cliente unas funciones extra al producto? ¡Seguro que le va a encantar!”

Al principio, lo que suena como algo muy positivo podrá provocar un gran dolor de cabeza. Añadir más elementos sin que el cliente los hubiera solicitado podría significar un importante incremento de riesgo en el proyecto, que consecuentemente se traduciría en retrasos en los plazos establecidos. Si ocurre alguna incidencia en este sentido, lo primero que el cliente dirá es que los problemas empezaron a partir del momento que el Project Manager decidió añadir elementos al producto que no figuraban en los requisitos originales. Al cliente se le debe entregar solamente lo solicitado, ni más ni menos. Añadir “extras” es una pérdida de tiempo que no aportará ningún beneficio al proyecto.

“Olvídense de los requisitos del cliente. Nosotros sabemos lo que hacemos”

Los requisitos funcionan básicamente como el hilo conductor de un proyecto y reflejan exactamente las necesidades y expectativas del cliente. La correcta captura y entendimiento de dichos requisitos permitirá, entre otras cosas, gestionar las necesidades del proyecto de forma estructurada, mejorar la capacidad de predecir costes, plazos y riesgos, adoptar las acciones preventivas adecuadas y sobre todo asegurar a aceptación final del cliente.

“El alcance completo lo definimos en una fase más avanzada”

No todos los proyectos pueden tener su alcance definido durante su fase inicial. Es un reto muy difícil de alcanzar, sobre todo en proyectos innovadores, como son los de desarrollo de software, diseño de un nuevo móvil, por ejemplo. Cuando es posible disponer de toda la información para definir el alcance completo en la fase inicial del proyecto, lo ideal es definirlo sobre la marcha, a través de metodologías de planificación gradual, mitigando de esta forma los riesgos implicados.

Introducción

El alcance del proyecto es el trabajo que debe realizarse para entregar un producto con las caracte-rísticas y funciones específicas, o como define el PMBOK® de forma muy acertada, la dirección del alcance debe “incluir los procesos requeridos para asegurar que el proyecto incluya todo el trabajo necesario, y solamente el trabajo necesario, para completar el proyecto con éxito”. En otras palabras:

– Verificar constantemente que las tareas asignadas al proyecto están siendo completadas de acuerdo con el plan.

– Rechazar cualquier actividad adicional no prevista en el proyecto o que no forme parte de la EDT.

– Evitar a todo coste el “gold plating” (entregar más cosas que las el cliente ha solicitado).

78


La correcta dirección del alcance es imprescindible, pues a partir de ella se desarrollarán las estima-ciones de plazo, costes y recursos.

Una de las razones por la cual un proyecto falla, es porque su alcance ha sido mal definido. Son varias las razones que comprometen el alcance del proyecto. Una de las razones más comunes es que muchas veces el cliente tiene una idea supervalorada del proyecto, es decir, el cliente cree que el proyecto irá generar algo espectacular. Además, en las primeras reuniones con el equipo, normal-mente el cliente tiene la sensación que el equipo tiene el proyecto totalmente claro en la mente, con lo cual no es imprescindible planificar el alcance. Es un raciocinio equivocado que inevitablemente irá provocar serios problemas más tarde.

Además, existen casos en que un Project Manager no tiene la costumbre de desarrollar una EDT (véase también 5.3), que es una herramienta clave en la dirección del alcance.

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección del alcance de un proyecto incluye los procesos y actividades necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarlo con éxito. Incluye los siguientes procesos:

– Recopilar requisitos.

– Definir el alcance.

– Crear la EDT.

– Verificar el alcance.

– Controlar el alcance.

5.1. Recopilar requisitos (proceso que corresponde a la fase de planificación del proyecto)

La recopilación de requisitos es el proceso que documenta las necesidades de los interesados y que define los objetivos del proyecto. Uno de los factores de suceso de un proyecto depende del cuidado que se tenga en obtener correctamente los requisitos de un cliente y él saber gestionarlos adecuadamente. Se puede decir que los requisitos son “los intereses documentados del cliente”. Allí residen sus expectativas, ilusiones y deseos que en algunos casos pueden ser muy subjetivos o mal aclarados, y por ello es fundamental su completa documentación.

*Nota del autor: A veces el cliente no sabe lo que quiere

Una reunión de recopilación de requisitos tiene como objetivo desarrollar una documentación completa que permita al equipo del proyecto el pleno entendimiento de todo el trabajo que deberá ser ejecutado para cumplir las expectativas del cliente. El problema reside cuando es el propio cliente el que no tiene claro lo que necesita, puesto que muchas veces viene influenciado o amparado por “ideas” mal fundamentadas y con escasa información.

Al no tener clara la definición de requisitos, cualquier intento de desarrollo de sus exigencias será una total pérdida de tiempo y dinero. Es fundamental que el cliente tenga claro sus requisitos de forma que permita al equipo del proyecto comprehender cada parámetro que conducirá el objetivo final que el proyecto pretende alcanzar. No obstante, es importante tener en cuenta que el cliente muchas veces no es un experto y por ello no tendrá plenas condiciones de proporcionar la información necesaria para establecer claramente los requisitos del proyecto.

Por todo ello, la comunicación es un factor clave en la recopilación de requisitos. Es fundamental que cliente sepa exponer exac-tamente lo que desea y el equipo de proyecto debe entender claramente sus necesidades. Si un cliente no es un experto, debería contar con profesionales que pudiesen aportarle las aclaraciones que necesita para cumplir con sus necesidades. En caso contra-rio, hay que intentar guiarle y lograr que entienda exactamente lo que necesita y cuál es el resultado final esperado.

79

C5

Los requisitos además, constituyen la base de la EDT (véase también sección 5.3) y son el marco de planificación de costes, plazos y recursos.

(1) Cómo el cliente lo explicó, (2) cómo el líder del proyecto lo ha entendido, (3) cómo el analista lo diseñó, (4) forma en que el programador lo escribió, (5) forma en que el consultor de negocios lo describió, (6) cómo el proyecto fue documentado, (7) qué el departamento de operaciones ha instalado, (8) cómo se le factura al cliente, (9) la forma en la que recibe soporte, (10) lo que el cliente realmente quería.

Figura 23: Requisitos del cliente. Si el cliente no es capaz de expresar claramente sus necesidades o si el equipo de pro-yecto no logra comprenderlas correctamente, el resultado final de un proyecto podrá convertirse en un auténtico desastre.


5.1.1.1. Entrevistas (Interviews)

La entrevista es una técnica que consiste en reunir a una o más personas, especialistas en una deter-minada materia, con el objetivo de recopilar datos que puedan ser útiles a alguna cuestión relacionada con un proyecto. Tiene una gran importancia en el proceso de recopilación de requisitos, puesto que permite obtener determinadas conclusiones sobre lo que se está investigando.

Ventajas:

– Es una técnica sencilla, de bajo coste y muy flexible que permite obtener datos relevantes.

– La información recopilada es muy superior a la obtenida cuando está limitada a la lectura de una respuesta escrita.

– Se pueden captar los gestos, tonos de voz, énfasis..., que aportan una importante información sobre el tema y sobre todo sobre las personas entrevistadas.

No obstante, la principal ventaja de la entrevista reside en la capacidad que esta técnica tiene de po-der extraer directamente del entrevistado sus verdaderas sensaciones, expectativas, puntos de vistas, opiniones y deseos, que serían muy difíciles de obtener a través de otro medio menos directo.

Desventajas:

– Si el entrevistador no logra producir una pauta adecuada, no será posible extraer del entrevistado la información que se necesita.

– Puede haber por parte del entrevistado, un cierto desinterés en responder las preguntas propues-tas. También hay casos de personas que se inhiben ante un entrevistador, y por ello, les cuesta responder con seguridad.

– Es común encontrarse con interlocutores que mienten, deforman o exageran en sus respuestas, perjudicando de esta forma la calidad de los resultados esperados.

80


De acuerdo con el objetivo que se pretenda alcanzar, se puede desarrollar una entrevista estándar, que planteará a los entrevistados exactamente las mismas preguntas y en el mismo orden. Como prin-cipal desventaja, este tipo de entrevista no permite expresar la opinión del entrevistador. Sin embargo, sus resultados son muy fáciles de procesar, simplificando el proceso comparativo.

Por otro lado, existen las entrevistas “no estructuradas”, que se caracterizan por su flexibilidad, aun-que se rige a su objetivo principal. Su principal ventaja es la capacidad de adaptación acorde con el entrevistado o la situación, permitiendo además profundizar sus reflexiones.

Como desventajas, requiere una inversión importante de tiempo y los resultados obtenidos no más difíciles de tabular.

5.1.1.2. Grupos de opinión (Focus groups)

Esta técnica consiste en reunir un determinado grupo de personas para discutir un asunto específico de carácter técnico, comercial, político, organizacional, entre otros aspectos. En el caso de la recopi-lación de requisitos, podemos, por ejemplo, imaginar que el grupo esté formado por potenciales clien-tes de un producto y/o servicio. Es similar a la lluvia de ideas (brainstorming, véase también sección 11.2.1.8), pero tiene un matiz fundamental que de mantener el grupo constantemente enfocado en una determinada cuestión.

Con un moderador encargado de hacer las preguntas y dirigir la discusión, su objetivo es coordinar el grupo para que esté debidamente enfocado y no se distancie del tema de estudio, por ello viene el nombre en inglés: “focus group”.

Toda la dinámica de la reunión está pensada para que los participantes se sientan cómodos y a gusto para poder expresar sinceramente sus opiniones y sugerencias. En el mundo del marketing, este tipo de reuniones son consideradas una herramienta fundamental para extraer los deseos y necesidades de un determinado grupo de clientes y/o consumidores. Las informaciones generadas son de extremo valor para la creación de los requisitos que compondrán un futuro servicio o producto.

Para que las secciones de grupos de opinión sean exitosas, es importante cumplir con algunos re-quisitos:

– Impedir que el grupo pierda el foco central de la sección y pierda tiempo en asuntos de poca trascendencia.

– Elaborar un guión de desarrollo que servirá para iniciar y cerrar la discusión.

– Limitar la participación y la duración de la reunión (no deberían sobrepasar las dos horas).

– Es habitual que algunos participantes se dejen llevar por la presión del grupo, cambiando su opinión, lo que produciría una cierta “contaminación” en los resultados. Es importante que el mo-derador esté bien entrenado para saber manejar adecuadamente el grupo.

5.1.1.3. Talleres facilitados (Facilitated workshops)

Muchos proyectos sufren cambios importantes en su alcance, principalmente porque la recopilación de sus requisitos no ha sido correctamente realizada. Frecuentemente, nos encontramos con requi-sitos provenientes de resultados cruzados, mal documentados y muchas veces recopilados de per-sonas que no tienen claro los objetivos del proyecto. La obtención de requisitos fiables depende de la puesta en marcha de un ambiente controlado y con la participación de las personas adecuadas. Y esto se puede conseguir, a través de talleres facilitados.

81

C5

Los talleres facilitados son secciones en donde se reúnen los interesados del proyecto para definir los requisitos de un producto o servicio. Para que estas secciones proporcionen una información fiable, es fundamental que los interesados que formen parte de estas reuniones, conozcan el sector afectado y tengan experiencia en proyectos anteriores similares. Este grupo emitirá una opinión fun-damentada en un análisis de los objetivos del proyecto, las necesidades y expectativas del cliente, el entorno de su negocio, etcétera.

Uno de los talleres facilitados más conocidos en la industria del software es el JAD (joint application development – desarrollo conjunto de aplicaciones). Su filosofía cumple con la idea básica de los talleres facilitados*:

– La gente que hace un trabajo tiene la mejor comprensión de ese trabajo.

– La gente entrenada en tecnologías de la información tiene la mejor comprensión de las posibilida-des de esas tecnologías.

– Los sistemas de información y los procesos del negocio raramente existen en forma aislada - Más bien trascienden los límites de cualquier sistema u oficina y afectan el trabajo en departamentos relacionados. La gente que trabaja en estas áreas relacionadas tiene una percepción valiosa del papel del sistema dentro de una comunidad más amplia.

– Los mejores sistemas de información se diseñan cuando todos estos grupos trabajan juntos en un proyecto como socios iguales.

Los talleres facilitados pueden generar los requisitos exactos que el proyecto necesita, además de proporcionar mejor las metas comunes del proyecto y el fortalecimiento del grupo involucrado en su desarrollo.

5.1.1.4. Técnicas de creatividad en grupo (Group creativity techniques)

Una de las habilidades más impresionantes del ser humano es la creatividad, que, sin lugar a dudas, ha sido una de las bases fundamentales para el avance del hombre en el campo de las artes, la arqui-tectura, la ingeniería, la informática y los negocios en general.

Acorde con Diane E. Papalia en su libro Psicología del desarrollo, la creatividad consiste en la ha-bilidad de ver las cosas bajo una nueva perspectiva e inventar luego soluciones nuevas, originales y eficaces. Existirían por lo tanto dos tipos de pensamiento que se relacionarían con la resolución de problemas y la creatividad:

– El pensamiento divergente, que es la capacidad para descubrir respuestas nuevas y originales.

– El pensamiento convergente, que lo define como la capacidad para descubrir una única res-puesta correcta.

Estos pensamientos estarían también altamente relacionados con la motivación, los conocimientos previos, el aprendizaje, la independencia de carácter y la determinación.

Todos estos conceptos se encajan perfectamente en uno de los aspectos más recalcados en este li-bro: un proyecto de éxito depende sobre todo de reunir las personas ciertas, en el momento oportuno, con los conocimientos adecuados y, según lo que establece lo anterior, con capacidad de descubrir soluciones nuevas y originales.

*Fuente: Wikipedia.

82


Son muchas las técnicas para fomentar y motivar la imaginación de las personas, algunas de ellas se encuentran ampliamente explicadas en este libro, las podrá encontrar en los puntos a continuación:

– Lluvia de ideas (Brainstorming): Descrita en la sección 11.2.1.8.

– Técnica de grupo nominal (Nominal group technique): Descrita en la sección 11.2.1.9.

– Técnica delphi (Delphi technique): Descrita en la sección 6.4.1.7.

– Técnica crawford slip (Crawford´s slip writing method): Descrita en la sección 11.2.1.11.

– Mapa conceptual (Concept map): Descrita en la sección 11.2.1.13.

– Diagrama de afinidad (Affinity diagram): Descrita en la sección 11.2.1.14.

5.1.1.5. Técnicas de toma de decisión en grupo (Group decision making)

La tomas de decisión en grupo es un proceso que reúne a un grupo de personas con el objetivo de tomar, de forma conjunta, la mejor decisión posible frente a una determinada situación.

Algunos de los métodos más utilizados para llegar a una decisión en grupo son:

– Unanimidad: Ocurre cuanto todos los participantes están de acuerdo en poner en marcha una única línea de acción.

– Mayoría: La decisión elegida cuenta con el apoyo de por lo menos 51% de los miembros del grupo.

– Pluralidad: El bloque más grande de todo el grupo de participantes toma la decisión, aunque no se alcance la mayoría.

– Dictadura: Cuando una persona decide el curso de la acción, sin considerar la posición de los demás.

5.1.1.6. Cuestionarios y encuestas (Questionnaires and surveys)

Las encuestas pueden ser útiles en la recopilación de requisitos, y como dicho anteriormente, siempre y cuando los encuestados sean profesionales del sector con experiencia y provistos de conocimien-tos que aporten calidad a los resultados de la encuesta.

Estos resultados se obtienen a partir de un conjunto de preguntas dirigidas a una muestra representa-tiva o al conjunto total de una población estadística en estudio, formada por profesionales, empresas o entes institucionales y con el objetivo, en nuestro caso, de recopilar los requisitos necesarios para desarrollar un determinado producto y/o servicio.

La encuesta tiene la ventaja de ser una acción de bajo coste y que suele recopilar la información exac-ta. No obstante, la calidad de los resultados obtenidos dependerá fundamentalmente de dos factores: de la selección de las preguntas correctas y de la elección de los encuestados adecuados.

5.1.1.7. Observaciones (Job shadowing)

Ampliamente utilizada en las escuelas secundarias americanas, es conocida como Job Shadowing, esta técnica trata de introducir a jóvenes estudiantes en ambientes reales de trabajo (oficinas, talleres, bufetes, entre otros), donde podrán observar en primera persona, como trabajan los profesionales en sus áreas de actuación y hacerles preguntas acerca de su trabajo. Esta experiencia les aportará la información que necesitan para conocer mejor determinadas profesiones y ayudarles a decidir acerca de su futuro profesional.

83

C5

En el campo del Project Management, esta técnica es utilizada para observar de forma directa como un profesional realiza su trabajo y ejecuta sus procesos, de esta forma, el observador podrá constatar cómo se hace el trabajo y descubrir determinados requisitos desconocidos. Son extremadamente útiles para procesos detallados, cuando las personas tienen dificultades en detectar sus propias ne-cesidades o no tienen claro cómo pueden mejorar sus proceso de trabajo.

5.1.1.8. Prototipos (Prototypes)

Un prototipo es básicamente un modelo operativo que contiene todas las características funcio-nales del producto que se pretende fabricar y es utilizado para hacer simulaciones y probar sus debilidades y fortalezas.

Dado que es tangible, el prototipo permite hacer experimentos muy próximos a lo que llegaría a ser el producto final, en lugar de sólo debatir de forma abstracta sobre sus requisitos.

5.2. La definición del alcance (proceso que corresponde a la fase de planificación del proyecto)

Esta fase normalmente es plagada por el entusiasmo general. Existe una sensación de que todo puede ser hecho y que el proyecto será desarrollado sin incidencias. Es una sensación un poco pe-ligrosa, pues conllevará a confeccionar un alcance muy complejo con más artículos de los que real-mente el producto o el servicio necesitan para cumplir su objetivo, que además de innecesarios, no interesarán al cliente. Cualquier problema que surja a raíz de ellos, conllevará a pérdidas importantes de tiempo y recursos.

Para impedir que esto ocurra, es importante reunir el equipo del proyecto y a los principales intere-sados para hacer una lista de los artículos que deben salir del primer borrador del alcance. Una vez realizado este filtro, llegaremos a lo que llamamos de “listado de requisitos”, que formará parte del plan de gestión de requisitos.

Este listado contendrá todos los elementos que el equipo y los interesados juzguen importantes para el proyecto. Si posible, es recomendable realizar una segunda ronda de verificaciones para comprobar si el listado de requisitos disponible hasta el momento, puede ser aún más reducido. Para asegurarse de que todos los artículos que están en este listado son realmente necesarios, es prudente que se desarrollen justificativas razonables para seguir manteniéndolos.

Los artículos eliminados durante las secciones de verificación, no serán olvidados. Es recomendable documentar estos artículos en una “lista de requisitos excluidos”, que también formará parte del plan de gestión de requisitos. Si no se documentan los artículos descartados en una lista de exclusión, estos volverán una y otra vez, siempre que se realice el proceso de definición del alcance.

Una vez completada el listado de requisitos, el Project Manager podrá definir con su equipo, cuáles serán los entregables (deliverables) del proyecto. Un entregable, de acuerdo con el PMBOK® es “todo producto, resultado o elemento mensurable, tangible y verificable que deba entregarse para finalizar un proyecto, o parte de un proyecto”.

Estos entregables deben ser formalmente aprobados por los interesados del proyecto, sobre todo por el cliente y los patrocinadores. No puede haber dudas de que estos entregables, resul-tado de todos los filtros realizados en gestiones de definición del alcance, son los entregables definitivos del proyecto.

84


Además es importante definir los resultados que cada entregable debe atingir y cuáles serán los crite-rios de aceptación. Estos cuidados iniciales evitarán que el alcance sea modificado durante el desa-rrollo del proyecto. El cambio de alcance es un factor crítico que, al ser cambiado, puede producir impactos negativos. Un alcance bien definido no debería sufrir ningún tipo de replanificacion posterior.

Figura 24: Acciones resultantes de los cambios en el alcance

Realizadas todas las verificaciones pertinentes, será posible desarrollar los “paquetes de trabajo”. Estos paquetes, son las actividades necesarias para llevar a cabo la producción de un entregable. Para ello, usaremos una herramienta llamada estructura detallada del trabajo - EDT” o, WBS, su sigla en inglés. (Véase también la sección 5.3).


5.2.1.1. Planificación gradual (Rolling wave project planning – RWPP)

La planificación gradual (Rolling Wave Project Planning – RWPP) es una técnica muy utilizada en proyectos que poseen un grado muy alto de incertidumbre, donde no se puede planear mucho más adelante, como pueden ser los proyectos de desarrollo de software.

Una situación muy frecuente que nos encontramos es la de tener que empezar inmediatamente un proyecto, sin que este cuente con un alcance totalmente definido y no disponga de toda la informa-ción necesaria para planificar todo el proyecto.

Esta técnica tiene un concepto extremadamente sencillo: se planifica hasta donde se pueda, es decir, hasta donde se tiene visibilidad o hasta donde la información obtenida en las fases anteriores nos permita llegar. Se va ejecutando lo planificado y a medida que el proyecto avanza y se recopila más información, se retoma la planificación de las siguientes fases.

ACTUALIZACIONESEN EL

CRONOGRAMA:

REVISIONES

REPLANIFICACIÓN

POCO IMPACTO

MEDIO IMPACTO

ALTO IMPACTO

CAMBIOS EN ELALCANCE

RESULTAN EN:

85

C5

Para ello, el proceso más coherente es partir de una EDT (descrita en la sección 5.3) que contemple todas las fases y objetivos del proyecto. Se detallan entonces, las actividades de la primera fase, y conforme avanza el proyecto, se recopila más información. Al finalizar esta primera fase, las informacio-nes y conocimientos adquiridos serán utilizados en la EDT para planificar las actividades de la siguiente fase, en un ciclo que se mantiene hasta concluir el proyecto.

Este procedimiento permite ejecutar el proyecto planificando la fase siguiente sobre la marcha. De todas formas, esta herramienta solo funcionará correctamente si el equipo y los interesados hayan establecido y reconocido previamente las fechas inicio y fin de la fase de cada una de las fases del proyecto.

Figura 25: Estimaciones basadas en desarrollo gradual

5.2.1.2. Descomposición (Decomposition)

Utilizando la técnica de la descomposición, se hace la definición del alcance sobre cada componente en que descompone el proyecto o sobre las tareas de bajo nivel en que se descomponen otras tareas.

Las definiciones de bajo nivel se combinan para producir la definición de cada actividad, y consecuen-temente, de cada fase, hasta llegar al proyecto completo.

La forma más conocida y más utilizada para hacer la descomposición del alcance de un proyecto es la técnica de la estructura detallada del proyecto – EDT (Work Breakdown Structure – WBS), descrita en la sección 5.3.



5.2.1.4. Análisis del producto (Product analysis)

El análisis del producto es una herramienta que tiene como objetivo conocer en profundidad todas las características generales de un producto, y con ello buscar mejorar la calidad de su desarrollo y fabricación. Es un análisis que se realiza a través de distintas etapas, cada una de ellas tratando de conocer los diferentes entornos de un mismo producto.

El análisis del producto se desarrolla de la siguiente forma:

– Análisis Morfológico: Define la forma del producto y sus características geométricas (volumen, ergonomía, etc.);

– Análisis Funcional: Define sus funciones y si estas cumplen con los objetivos planteados cuando ha sido creado;

ESTIMACIÓN DETALLADA ESTIMACIÓN APROXIMADA



ESTIMACIÓN DETALLADA

mes 1 mes 2 mes 3 mes 4 mes 5 mes 6 mes 7

86


– Análisis Estructural: Define qué elementos tiene y cómo se relacionan. Para ello es necesario el despiece del objeto y estudiar sus partes.

– Análisis de Funcionamiento: Define su funcionamiento, y si cumple correctamente con sus especificaciones;

– Análisis Tecnológico: Define su elaboración y sus materiales, cómo ha sido desarrollado y que procesos fueron realizados para su fabricación;

– Análisis Económico: Define su valor en función de sus costes (directos e indirectos), de diseño y fabricación, su logística de distribución y su precio final al consumidor;

– Análisis Comparativo: Define sus diferencias y/o similitudes con otros productos; comparando sus funcionalidades, efectividades y precisión.

– Análisis Relacional: Define su entorno y analiza sus elementos vinculables, por ejemplo: Si es un producto que necesita de energía eléctrica, que potencia necesitará para desempeñar su función correctamente, etc.

Una vez finalizado el estudio completo del producto, sus resultados podrán aportar una serie de informaciones útiles que podrán mejorar su diseño y sus prestaciones. A nivel de Project Mana-gement, se podrá, de forma más precisa, establecer los costes, plazos y los recursos necesarios para su desarrollo.

5.2.1.5. Talleres facilitados (Facilitated workshops)


5.3. Creación de la EDT (proceso que corresponde a la fase de planificación del proyecto)

Este proceso consiste en subdividir todos los entregables de un proyecto en componentes más pe-queños y más fáciles de manejar. Para ello, se utiliza la Estructura Detallada de Trabajo - EDT (Work Breakdown Structure – WBS), que realiza una descomposición jerárquica de las actividades del proyecto necesarias para lograr un determinado objetivo. La EDT organiza y define el alcance total de proyecto y facilita la estimación de sus costes, plazos y recursos.


5.3.1.1. Estructura detallada del trabajo – EDT (Work breakdown structure – WBS)

También conocida como WBS (Work Breakdown Structure), es una de las herramientas más útiles y más populares en Project Management. Es sencilla y fácil de utilizar. Comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto. Cerca de 95% de las actividades de un proyecto pueden ser identificadas a través de esta herramienta. Además, sirve tantos para proyectos grandes como para pequeños. Es considerada por muchos, como la “fundación” del proyecto, puesto que aporta toda la información necesaria para realizar un seguimiento eficaz.

87

C5

Es una técnica fundamental de planificación de un proyecto y es muy útil para:

– Organizar y definir el alcance total del proyecto: Una regla básica de la EDT es: Si no se encuentra en la EDT, no puede formar parte del alcance;

– Mejorar las estimaciones de los plazos, costes y recursos que serán consumidos;

– Facilitar la comunicación entre los implicados del proyecto, permitiendo visualizar de forma gráfica el trabajo necesario para llevar a cabo sus actividades;

– Determinar las responsabilidades de cada integrante del equipo;

– Definir la línea base del alcance.

Características

Tiene un formato de árbol jerárquico, donde se organizan las actividades y se las agrupan en un primer nivel. A partir de este nivel, se desglosa el proyecto en subniveles, hasta llegar al último nivel, que constituye los paquetes de trabajo, que tienen un nivel de detalle que permita el control requerido por él.

Una EDT tiene que contemplar todas las actividades de un proyecto, tiene que estar bien organizada y es fundamental que las actividades descritas en la EDT sean completamente entendidas por el equipo que las va a desarrollar. Si alguna actividad no está clara para el equipo, es aconsejable desglosarla en niveles más detallados.

Principales Elementos

– Código de Cuentas (Code of Accounts): Sistema numérico utilizado para identificar los elemen-tos de la EDT;

– Plan de Cuentas (Chart of Accounts): Es un sistema numérico financiero utilizado para identificar cada elemento de la Estructura Detallada de Trabajo y para monitorizar los costes del proyecto por categoría (Ej.: mano de obra, materiales, maquinaria, etc.). El plan de cuentas es confeccionado de acuerdo con el plan de cuentas “maestro” desarrollado por la organización y que contiene las principales actividades de todos los proyectos desarrollados por la empresa;

– Paquetes de Trabajo (Work Packages): Es el entregable que se encuentra en el último nivel del árbol jerárquico de la EDT;

– Diccionario de la EDT (WBS Dictionary): Contiene la descripción detallada de los componentes que forman parte de cada actividad y cómo ellos serán desarrollados.

¿Cómo se confecciona una EDT?

Para empezar a confeccionar una EDT es necesario identificar las tareas necesarias para llevar a cabo el desarrollo de un proyecto. Estas tareas deben ser divididas en fases y en secuencia cronológica. Un ejemplo muy sencillo de confección de una EDT es la pintura de una habitación, trabajo que repre-senta uno de los entregables del proyecto de reforma de una casa.

88


1. Preparar Materiales

1.1. Comprar pintura

1.2. Comprar masilla

1.3. Comprar escalera

1.4. Comprar accesorios

2. Preparar dormitorio

2.1. Retirar ropas

2.2. Retirar cuadros y espejos

2.3. Desmontar muebles

2.4. Cubrir el suelo

3. Pintar el dormitorio

3.1. Lijar pared

3.2. Tapar grietas

3.3. Primera mano de pintura

3.4. Segunda mano de pintura

4. Limpiar el dormitorio

4.1. Tirar o guardar el resto de la pintura

4.2. Limpiar pinceles y rodillos

4.3. Guardar o tirar accesorios

4.4. Retirar la protección del suelo

4.5. Montar los muebles

4.6. Guardar las ropas

4.7. Poner cuadros y espejos

Figura 26: EDT de una pintura de un dormitorio

A cada elemento de una EDT se le asigna un identificador único (normalmente numérico). Los trabajos que no estén en la EDT quedan fuera del alcance del proyecto.

Según ilustra el ejemplo de la pintura de un dormitorio, la EDT descompone las tareas de un proyecto, lo que comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto (planificación, ejecución, control y cierre).

1. PREPARARMATERIALES

2. PREPARARDORMITORIO

3. PINTARDORMITORIO

4. LIMPIARDORMITORIO

1.1 Comprarpintura

1.2 Comprarmasilla

1.3 Comprarescalera

1.4 Compraraccesorios

2.1 Retirarroupas

2.2 Retirar cuadrosy espejos

2.3 Desmontarmuebles

2.4 Cubrir elsuelo

3.1 Lijar pared

3.2 Tapar grietas

3.3 Primeramano de pintura

3.4 Segundamano de pintura

4.1 Guardarpintura

4.2 Limpiarpinceles

4.3 Guardaraccesorios

4.4 Retirarprotección suelo

PINTURA DE DORMITORIO

4.5 Montarmuebles

4.6 Guardar Ropas

4.7 Poner cuadrosy espejos

100%

89

C5

La EDT puede ser ilustrada en formato de tabla, según ilustra la figura 27 que se presenta a continuación:

1 Preparar materiales

1.1 Comprar pintura

1.2 Comprar masilla

1.3 Comprar escalera

1.4 Comprar accesorios

2 Preparar dormitorio

2.1 Retirar ropas

2.2 Retirar cuadros y espejos

2.3 Desmontar muebles

2.4 Cubrir el suelo

3 Pintar dormitorio

3.1 Lijar pared

3.2 Tapar grietas

3.3 Primera mano de pintura

3.4 Segunda mano de pintura

4 Limpiar dormitorio

4.1 Guarda pintura

4.2 Limpiar pinceles

4.3 Guardar accesorios

4.4 Retirar protección suelo

4.5 Montar muebles

4.6 Guardar ropas

4.7 Poner cuadros y espejos

Figura 27: La EDT en formato de tabla

La creación de la EDT debe seguir algunas reglas importantes:

– El primer nivel de la EDT corresponde al nombre del proyecto o fase.

– El segundo nivel de la EDT normalmente corresponde al ciclo de vida del proyecto (en proyectos de desarrollo de software estos niveles podrían ser: Requisitos, diseño, programación, pruebas y documentación).

– Cada nivel de la EDT debe ser más pequeño que el nivel anterior.

– Cada tarea de la EDT debe ser realista y estimable, no puede ser subdividida, debe ser de rápida ejecución (máx. de 80 horas) y debe ser ejecutada sin interrupciones.

– Deberá incluir todo el trabajo previsto para la ejecución del proyecto.

– Deberá contemplar todos los entregables, incluido de terceros.

– Deberá incluir las actividades de gestión de proyecto.

– Cada elemento deberá tener un identificador único.

– Cada elemento deberá corresponderse con un único entregable.

– Es importante utilizar nombres o codificaciones familiares a toda la empresa. El Diccionario de la EDT es muy útil en este sentido.

90


¿Existe algún límite para descomponer una EDT?

Una EDT no debe ser demasiado grande ni demasiado limitada. En cualquiera de los casos se pue-den producir problemas de entendimiento del proyecto. Si una actividad que tiene una estimación de diez meses de finalización, es una actividad muy difícil de hacerse un seguimiento correcto. Lo mismo ocurre con una tarea que tiene una duración estimada de dos horas. El esfuerzo que conlleva hacer un seguimiento de una actividad de tan corta duración no es compensador.

Se suele utilizar muy a menudo algunas reglas acerca de la descomposición de una EDT. Algunas organizaciones utilizan lo que se conoce por “regla 4/40” o “regla 8/80”. La regla 4/40 es utilizada cuando se establece que ningún paquete de trabajo puede tener una duración menor que 4 horas y mayor que 40 horas. Con la regla 8/80, ocurre lo mismo, pero con limites mayores.

Para lograr una buena administración de un proyecto, una EDT no debe sobrepasar los cien ob-jetos terminales. Si el proyecto es muy grande y sobrepasa este límite, es aconsejable montar varias EDT (se puede hacerlo por fases, por ejemplo). Es aconsejable también que una EDT no sobrepase 4 niveles.

Normalmente, una EDT se descompone hasta llegar a una tarea desarrollada por un solo grupo funcio-nal puro (pintores, albañiles, electricistas, entre otros). Será el responsable o encargado del grupo fun-cional el que realizará las estimaciones de tiempo y coste que se encuentran bajo su responsabilidad.

El número de horas requeridas para el desarrollo de cada actividad además de sus costes asociados, deben aparecer en cada nivel de la EDT. Las primeras estimaciones financieras podrán ser realizadas a partir de la conclusión del diseño de la EDT, como ilustra la figura 28, a continuación:

Figura 28: Estimación de costes basado en una EDT

*Nota del autor: La EDT es una herramienta que debe ser desarrollada por el Project Manager en conjunto con los equipos que trabajaran en ella. Además de poder contar con la experiencia de profesionales con experiencia, el desarrollo de esta estructura en equipo ayudará a todos los involucrados a entender mejor el proyecto. De esta forma, el equipo del proyecto podrá obtener el conocimiento suficiente para poder compartir informaciones y hacer con que el proyecto se desarrolle de forma más eficaz ya que, en muchos casos, una tarea será compartida a equipos distintos.

Aunque cada proyecto es único, la EDT de un proyecto similar anterior puede ser utilizada como modelo para un nuevo pro-yecto. Normalmente, los proyectos desarrollados por la misma empresa contienen fases y ciclo de vidas similares y muchas veces los mismos entregables

1.EXCAVACIÓN

2.CONSTRUCCIÓN

3.ELETRICIDAD

4.TUBERIAS

Actividad 1.1

PROYECTO DE CONSTRUCCIÓN

Trabajo: 100%Ppto: 1000 Euros


Actividad 1.2



Actividad 2.1


Actividad 2.2



Actividad 3.1



Actividad 4.1



91

C5

5.3.1.2. Estructura de desglose del producto – EDP (Product breakdown structure – PBS)

Aunque muchos proyectos son desarrollados para la puesta en marcha de una solución integrada, algunos son realizados para el desarrollo de un producto específico (un coche, un móvil, un equipo informático...). En este tipo de proyecto, es imprescindible utilizar la estructura de desglose del pro-ducto DP (Product breakdown structure - PBS, en algunos casos también es conocida como Bill of materials – BOM). Se trata de una herramienta que permite confeccionar visualmente el listado de materias primas, componentes, accesorios y cantidades necesarias para producir un determinado artículo. Muchas empresas utilizan catálogos o banco de precios electrónicos de productos (como por ejemplo, BASELEC, BASEFON o BASEFER).

Figura 29: EDP de la fabricación de una PDA

5.3.1.3. Otros tipos de estructuras de desglose

– Estructura de desglose de la organización – EDO (Organization breakdown structure - OBS): Representa la parte del organigrama de la organización que formará parte del proyecto (descrita en la sección 9.1.1.4).

– Estructura de desglose de costes - EDC (Cost breakdown structure - CBS): Lista organizada de costes directos en los que incurrirá el proyecto (descrita en la sección 7.1.1.10).

– Estructura de desglose de riesgos - EDR (Risk breakdown structure - RBS): Lista organizada de riesgos del proyecto (descrita en la sección 11.2.1.5).

5.3.1.4. El diccionario de la EDT (WBS dictionary)

La EDT es una herramienta imprescindible para organizar el alcance del proyecto. Sin embargo, tiene sus restricciones. Su uso se limita a organizar el alcance del proyecto e informar de los nombres de las actividades que forman parte del proyecto. Será necesario conocer los componentes de cada actividad y cómo ellos serán desarrollados. Para ello, se utiliza el diccionario de la EDT, que incluirá la descripción detallada de todos los elementos de la EDT.

5.4. Verificación del alcance (proceso que corresponde a la fase de control del proyecto)

Es el proceso que consiste en obtener la aceptación formal del alcance del proyecto por parte de los interesados correspondientes. Esta aceptación tiene como condicionante la revisión de los entrega-bles del proyecto que deberán atender a los requisitos establecidos.

HARDWARE SOFTWARE COMUNICACIONES FUERZA

Cuna

Pantalla

Aplicaciones

SistemaOperativo

Antena

Conectores

Cableado

Circuitos

FABRICACIÓN PDA

92


Como requisito, podemos decir que es: “Una condición o capacidad que un producto o servicio tiene que poseer para cumplir con un contrato, especificación o cualquier otro documento formalmente impuesto”. Los requisitos incluyen las necesidades, los deseos y las expectativas del cliente o del patrocinador. Generalmente, clasificamos los requisitos en dos tipos:

– Obligatorios: forman parte inexcusable del proyecto.

– Deseables: aportarían valor añadido a la satisfacción del cliente, pero no están incluidos obliga-toriamente en el proyecto.

Cuando hablamos de requisitos deseables, es muy importante no caer en la tentación de añadir requi-sitos que en vez de aportar beneficios al proyecto, puede perjudicar el buen funcionamiento del pro-ducto o servicio resultante. Esto suele suceder a menudo cuando se practica en gold plating (véase también capítulo 9 – dirección de calidad).


5.4.1.1. Inspección (Inspection)

La inspección funciona como si de una auditoría se tratara. Se realiza a través de mediciones y ve-rificaciones que determinarán si los servicios o productos entregados cumplen con los requisitos establecidos en el plan de proyecto. Esta inspección puede ser realizada por el Project Manager, por algún miembro del equipo capacitado o incluso por el propio cliente (de hecho, lo suelen hacer antes de firmar la aceptación del proyecto). A veces, se contrata a un auditor externo con competencia para determinar si el producto o servicio desarrollado cumple con los requisitos establecidos previamente.

Se suele hacer en formato de checklist que incluirá todos los componentes de la EDT del proyecto. Normalmente, suele tener los campos a continuación:

Nº Descripción del artículo

Aprobado Crítico

Sí No Sí No

1

2

3

4

5

Figura 30: Checklist de artículos

De acuerdo con los resultados de la inspección, el cliente podrá aceptar el producto/servicio entrega-do o rechazarlo. La forma en que se realizará la inspección, incluyendo cuales son los puntos consi-derados críticos, podrá ser detallada en el plan de proyecto.

93

C5

5.5. Control de cambios del alcance (proceso que corresponde a la fase de control del proyecto)

Casi todos los proyectos que son desarrollados sufren cambios por alguno motivo. Cuanto más largo y complejo sea un proyecto, mayor es la posibilidad de que sufra algún cambio. En casi todos los ca-sos, los cambios en un proyecto son inevitables, y por ello es importante estar preparado para afrontar el momento de realizar las eventuales acciones correctivas, cuando estos cambios ocurran.

Los cambios de un proyecto pueden ser el resultado de muchos factores:

– La aprobación de una nueva ley.

– Una petición inesperada por parte del cliente.

– Un cambio de tecnología.

– Un cambio de estrategia organizacional.

– Un error o una omisión en la línea base del alcance.

A continuación, veremos las principales herramientas de control de cambios de alcance.


5.5.1.1. Análisis de variación (Variance analysis)

El análisis de variación es una herramienta utilizada para evaluar la magnitud de la variación respecto de la línea base original del alcance. Los aspectos importantes de control incluyen básicamente la de-terminación de la causa y del grado de variación entre la línea base original del alcance y la línea base actual. Se desarrolla de la siguiente manera:

– Se comprueba la calidad y la veracidad de la información recopilada a fin de asegurarse de que esté completa y de que sea coherente con datos anteriores.

– Se establecen las variaciones mediante la comparación de la información real con la línea base del proyecto, y la observación de todas las diferencias, tanto favorables como desfavorables.

– Se utilizan herramientas como el valor del trabajo realizado para cuantificar las variaciones.

– Se determina el impacto de las variaciones y sus consecuencias en el coste y en el cronograma del proyecto.

– Se documentan las conclusiones sobre las fuentes de variación y el área de impacto.

El valor del trabajo realizado (earned value – EV) es descrito detalladamente en la sección 7.3.1.1.

5.5.1.2. Sistema de control de cambios del alcance (Scope change control system)


5.5.1.3. Planificación adicional (Additional planning)

Son pocos los proyectos que se desarrollan exactamente según lo planificado. Prácticamente todos los cambios aprobados y aplicados al proyecto conllevarán la modificación de la documentación ori-ginal, y por ello se hará necesario la revisión de los plazos, costes y recursos anteriormente estable-cidos. La planificación adicional tiene como objetivo mitigar cualquier impacto negativo causado por los cambios incluidos en el proyecto. Por ello es importante revisar toda la planificación anteriormente realizada y actualizarla acorde con la nueva situación del proyecto.

94


C6Dirección de plazos

96


6.1. Definición de las actividades (proceso que corresponde a la fase de planificación del proyecto)6.1.1. Técnicas y herramientas

6.2. Secuenciación de actividades (proceso que corresponde a la fase de planificación del proyecto)6.2.1. Técnicas y herramientas

6.3. Estimación de los recursos de las actividades (proceso que corresponde a la fase de planifica-ción del proyecto)6.3.1. Técnicas y herramientas

6.4. Estimación de duración de actividades (proceso que corresponde a la fase de planificación del proyecto)6.4.1. Técnicas y herramientas

6.5. Desarrollo del cronograma del proyecto (proceso que corresponde a la fase de planificación del proyecto)6.5.1. Técnicas y herramientas

6.6. Control del cronograma (proceso que corresponde a la fase de control del proyecto)6.6.1. Técnicas y herramientas

97

Algunas cosas en las que NO puedes pensar acerca de dirección de plazos

“El cronograma es inútil, ya sabéis que no lo vamos a cumplir”

Podemos considerar que un cronograma está bien hecho cuando refleja exactamente la realidad de su entorno. Es decir, un cronograma tiene que basarse en la correcta gestión de los calendarios, en la capacidad de ejecución por parte del equipo asignado y en la complejidad de cada actividad. El problema del incumplimiento de plazos no reside en el cronograma. Las causas son las mencionadas anteriormente: no se ha tenido en cuenta el calendario del proyecto, el equipo no tenía la capacidad esperada, o la complexidad de la actividad ha sido evaluada incorrectamente.

“Os puedo asegurar, que mañana lo tenemos funcionando”

“No dejes para mañana lo que puedas hacer hoy”. Este refrán, muy popular, significa exactamente lo que parece, y se encaja perfectamente a la dirección de plazos del proyecto. Si puedes hacer algo ahora, no esperes al día siguiente. Si tienes una tarea en manos y hay tiempo y condiciones para iniciarla, lo ideal es ponerla en marcha para que se pueda finalizarla dentro del plazo. Una serie de incidencias no esperadas pueden llegar a ocurrir en un proyecto, lo que podrá provocar atrasos en la finalización de algunas actividades. Si a esto sumamos atrasos debidos a postergaciones innecesa-rias, el cronograma del proyecto podría colapsarse.

“No es necesario obedecer la secuencia de actividades propuesta”

Al analizar el cronograma de un proyecto, se podrá apreciar que las actividades obedecen a una ló-gica, que han sido investigadas y desarrolladas por un grupo de expertos. Prácticamente, todos pro-cesos industriales, artesanales o incluso naturales obedecen a una secuencia lógica que no debería ser modificada. No se puede pintar una pared sin antes levantar los ladrillos, y tampoco es posible tomarse una copa de vino sin antes sacarle el corcho de la botella. Por lo tanto, si el cronograma pre-senta una secuencia de actividades, lo mejor es cumplirla a rajatabla.

“Esta medición, aunque parezca compleja, será realizada en tiempo récord”

Existen tareas que necesitan un tiempo mínimo para que finalicen adecuadamente. El desarrollo de un proyecto no es una carrera contra el tiempo, es un emprendimiento que ha sido previamente estudia-do y cuyas actividades deberán ser realizadas dentro de unos plazos compatibles con su naturaleza.

“Podemos hacerlo con calma, porque disponemos de una buena reserva de tiempo extra”

Las reservas de contingencia de tiempo existen para los casos de emergencia cuando, por razones especiales, el equipo no ha podido finalizar su labor en el plazo previsto y, por lo tanto, dispone de una reserva de tiempo extra para poder completar sus tareas. Por esta razón, no podemos ralentizar la ejecución de una tarea, pensando en una reserva de tiempo que tenemos disponible.

98


Según la ley de Parkinson (Parkinson´s law), creada por Cyril Northcote Parkinson en un artículo publi-cado en el semanario británico The Economist, en el año 1955: “El trabajo se amplía para cubrir todo el tiempo disponible para su conclusión”. O sea, si una determinada tarea tiene un plazo estimado de seis días y se añaden dos días más como contingencia, según la ley de Parkinson, esta tarea llevará ocho días para ser completada. Por supuesto, esta teoría no pretende derrumbar la técnica de la reserva de tiempo, pero intenta demostrar que no será simplemente añadiendo un par de días más a cada tarea, que se alcanzará el cronograma perfecto; todo lo contrario, esta práctica puede tornarse un vicio que convertirá el proyecto en un emprendimiento interminable.

Introducción

Para muchos, gestionar un proyecto es lo mismo que confeccionar un cronograma. Sabemos que la gestión de un proyecto conlleva a la administración integrada de una serie de elementos, como son la comunicación, los costes, el alcance y los recursos humanos. La dirección de plazos, por lo tanto, depende del correcto sincronismo de las actividades realizadas por los diferentes profesionales impli-cados en el proyecto que necesitarán de una coordinación que pueda asegurar el cumplimiento de toda la planificación establecida.

Aisladamente, la dirección de plazos empieza definiendo las actividades del proyecto. Luego se or-ganiza su secuencia para, a continuación, estimar sus duraciones. El resultado final de estas estima-ciones es el cronograma, que orientará el equipo del proyecto en lo que dice respeto a las fechas de inicio/fin y la duración de las actividades correspondientes.

Algunos proyectos pueden perder totalmente su objetivo si los plazos no son cumplidos. La infraes-tructura necesaria para realizar una carrera de Fórmula 1 en una ciudad, será de muy poca utilidad si los trabajos se concluyen después que la carrera ha terminado.

Sin embargo, y naturalmente, gestionar el tiempo de un proyecto no se limita tan solamente a estimar las secuencias y las duraciones del proyecto, ni mucho menos desarrollar un cronograma. Existen algunos conceptos que el Project Manager necesita conocer, para entender mejor las implicaciones que conlleva realizar una dirección de plazos correcta:

– Actividad crítica (Critical activity): Es una actividad que, si no finaliza en el tiempo estimado podrá impactar negativamente en la duración de todo el proyecto. Se determina una actividad como cri-tica cuando no se puede cambiar sus fechas de comienzo y finalización sin modificar la duración total del proyecto. Su holgura total es cero.

– Camino crítico (Critical path): Es la secuencia de actividades del proyecto que tiene la mayor duración y que determina el menor tiempo posible para completar un proyecto sin holguras. La duración del camino critico determina la duración total del proyecto, con lo cual, cualquier retraso en el desarrollo de los elementos del camino critico repercutirá negativamente sobre la fecha de finalización del proyecto. Es decir, si se retrasa en dos días una de las actividades del camino crítico, el proyecto entero se retrasará en dos días (a no ser que haya otra tarea del camino crítico que se adelante en dos días).

– Duración (Duration): Periodo de tiempo estimado (sin incluir días festivos u otros periodos de no trabajo) necesario para completar una determinada actividad. Normalmente es expresado en horas, días, semanas…

– Esfuerzo (Effort): Número de unidades requeridas para completar una determinada actividad del proyecto. Normalmente se expresa en horas hombre, días hombre o semanas hombre. No se debe confundir con la duración.

– Flotación (Float): Tiempo que una actividad se puede retrasar desde su fecha de inicio temprana sin retrasar la fecha de finalización del proyecto. Este tiempo de flotación puede cambiar a medida que avance el proyecto y se efectúan cambios en el proyecto.

99

C6

– Recorrido hacia Adelante (Forward pass): Este término determina la fecha de inicio y finalización más temprana para las partes incompletas de todas las actividades de la red. El resultado obteni-do permite conocer cuál es la fecha más temprana para la asignación de un determinado recurso y cuál es la fecha mínima que el proyecto necesita contar con este recurso.

– Recorrido hacia Atrás (Backward pass): Cálculo de fechas de finalización e inicio tardías para las partes incompletas de todas las actividades de las redes. Se determina yendo hacia atrás en la logia de las redes a partir de las fechas de conclusión del proyecto, la que puede calcularse en un recorrido hacia adelante o ser establecida por el cliente o patrocinador.

– Hito (Milestone): Un punto del cronograma, normalmente señalizando un evento importante del proyecto, normalmente la conclusión de una determinada actividad, decisión o fase. Los hitos no son actividades, es decir que no consumen tiempo ni recursos, son tan solamente, un punto de referencia del proyecto.

– Diagrama de Red (Network Diagram): Representación gráfica de las relaciones lógicas de las actividades de un proyecto. Siempre se traza de la izquierda a la derecha para reflejar la cronología del proyecto.

– Holgura (Slack): Es la cantidad de tiempo que una tarea puede ser aplazada sin afectar la fecha de finalización del proyecto.

Estos términos son fundamentales para entender correctamente la dirección de plazos del proyecto. Su correcto entendimiento además, contribuirá para el desarrollo de un cronograma realista. Un cro-nograma “perfecto” que debería ser confeccionado obedeciendo algunos procedimientos:

– Identificar las actividades que formarán parte del proyecto: Utilizando la Estructura detallada del proyecto – EDT (descrita en la sección 5.3) será posible realizar las estimaciones iniciales del proyecto. La EDT es una herramienta de descomposición del trabajo realizado, orientada a los entregables del mismo, que organiza y define el alcance completo.

– Desarrollar el diagrama de red: La confección de este diagrama deberá contemplar todas las actividades del proyecto. Estas actividades deberán secuenciarse de forma precisa para susten-tar el posterior desarrollo de un cronograma realista. Si posible, es importante poder contar con la colaboración de expertos. (Para más detalles, véase también sección 6.2.1 - Técnicas y herra-mientas para la secuenciación de actividades).

– Estimar la duración de las actividades: Normalmente, se estiman las fechas más optimistas, como si todos los recursos estuviesen disponibles en tiempo integral. Una vez hecha está esti-mación orientativa, se parte para una estimación más realista, basado en la disponibilidad real de los recursos en la empresa.

– Estimar fechas: Con la secuencia y la duración de las actividades en manos, es hora de plani-ficar las fechas concretas de comienzo y cierre del proyecto. Muchas veces, estas fechas son una restricción del proyecto ya que pueden, y muchas veces lo son, determinadas pelo cliente. Para poder lograr el cumplimiento del calendario establecido, es importante considerar festivos, horarios especiales y, sobre todo, la disponibilidad de los recursos asignados; esta última muchas veces es la razón por la cual muchos proyectos no finalizan en el plazo estimado.

– Hacer un seguimiento: Finalizado en cronograma de las actividades es fundamental crear una línea base. Esta línea base será importante para comprobar si el proyecto avanza según el cronograma planificado y posteriormente se tornará una fuente de consulta para futuros proyectos similares.

100


En algunos proyectos, especialmente en los pequeños, la secuencia de las actividades, su estimación y duración, así como el desarrollo del cronograma están tan estrechamente vinculados que son vistos como un único proceso ya que pueden ser ejecutados durante un periodo relativamente corto.

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección de plazos de un proyecto incluye los procesos y actividades necesarios para administrar la finalización del proyecto a tiempo. Son estos:

– Definir las actividades.

– Secuenciar las actividades.

– Estimar los recursos de las actividades.

– Estimar la duración de las actividades.

– Desarrollar el cronograma.

– Controlar el cronograma.

6.1. Definición de las actividades (proceso que corresponde a la fase de planificación del proyecto)

Este proceso consiste básicamente en identificar correctamente las acciones específicas que debe-rán ser puestas en marcha para el desarrollo de los entregables del proyecto. Las actividades de un proyecto son la base fundamental para la estimación, la planificación, la ejecución, el seguimiento y el control del trabajo del proyecto. La definición y la planificación de las actividades del cronograma están implícitas en este proceso, de modo que se cumplan los objetivos del proyecto.



Descrita en la sección 5.3.

6.1.1.2. Descomposición (Decomposition)

La descomposición es la subdivisión de los entregables del proyecto en componentes más pequeños y manejables, hasta que el trabajo y los entregables queden definidos al nivel de paquetes de trabajo. El nivel de paquetes de trabajo es el más bajo en la EDT, y es aquel en el que el coste 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 forma más conocida y más utilizada para hacer la descomposición del alcance de un proyecto es la técnica de la estructura detallada del proyecto – EDT (work breakdown structure – WBS), descrita en la sección 5.3.

6.1.1.3. Planificación gradual (Rolling wave project planning – RWPP)


101

C6

6.1.1.4. Plantillas (Templates)

Una plantilla es un documento estándar utilizado para diferentes fines y sirve, sobre todo, para facilitar el trabajo de reproducción de documentos idénticos o similares. Las plantillas no son otra cosa que un punto de partida, una idea aproximada de lo que se quiere hacer. A partir de una plantilla se puede diseñar nuevas plantillas, más refinadas y con más informaciones. Con el paso de los años, muchas empresas mantienen un “banco de plantillas” que pueden ser aprovechadas para determinado mo-mento del proyecto.



6.2. Secuenciación de actividades (proceso que corresponde a la fase de planificación del proyecto)

Este proceso consiste en identificar y documentar las relaciones entre las actividades del proyecto, que se establecen mediante relaciones lógicas; es decir, las actividades se conectan con sus prede-cesores y sucesores correspondientes, que pueden incluir adelantos o retrasos entre las actividades que proporcionen al cronograma un escenario realista, viable y, sobre todo, sostenible.


6.2.1.1. Diagramas de red (Network diagram)

Un diagrama de red es el término genérico de un diagrama, que representa algún tipo de red que pueda conectar varias actividades en una secuencia cronológica. Presentan una serie de variaciones, y cada una de ellas podrá ser estructurada para los más diferentes fines.

Figura 31: Diagrama básico de red

*Nota del autor: Las plantillas son realmente muy útiles. Yo mantengo un banco de plantillas personal desde hace años y las utilizo a menudo. Cualquier documento puede servir de plantilla: contratos, cronogramas, líneas base, cartas, propuestas... Se trata de un recurso que te hace ahorrar el tiempo y te aporta un contenido listo para usar. Otra ventaja es que estas plantillas van mejorando con el paso del tiempo. Siempre que utilizo una plantilla, aprovecho para mejorar su contenido y formato.

No obstante, a la hora de coger un documento para convertirlo en plantilla, es fundamental eliminar cualquier información que pueda identificar a personas, fechas, valores o cualquier otro dato identificativos utilizado en un documento anterior. De una plantilla se aprovecha su estructura y contenido, pero se debe conservar la confidencialidad, eliminando datos considerados “sensibles”.

inicio

A

D

B

E

C

F

fin

102


Un diagrama de red básico debería contener, por lo menos, los siguientes elementos:

– Un evento: Que señale el inicio y el fin de la tarea o acción; no consume tiempo ni recursos. Se representa a través de un nodo o un círculo.

– Actividades: Son el un conjunto de tareas, que deben ejecutarse, para la realización de una obra; consume tiempo, tiene inicio y fin, requiere mano de obra, materia prima y otros recursos.

– Una actividad ficticia: Es aquella que no consume tiempo ni trabajo. Se representa por líneas entrecortadas y sirve para guardar la lógica de la red.

– Un camino crítico: Es el camino más largo a través de la red y representa el menor tiempo posi-ble para la ejecución del proyecto.

6.2.1.2. Método de diagramación con flechas (Arrow diagramming method – ADM)

También conocido por “AOA - Activity on arrow”, es una de las primeras herramientas utilizadas para secuenciar actividades. Utilizada en proyectos muy sencillos, su concepto es limitado y no puede soportar una red de actividades muy compleja. Por esta razón, es poco utilizada actualmente.

La relación precedente entre actividades es representada por círculos conectados a una o más fle-chas. La longitud de la flecha puede representar la duración de la actividad. En algunos casos, se añade una actividad ficticia (conocida en el ámbito del Project Management como dummy task), que sirve básicamente para representar la dependencia entre actividades y no consume tiempo ni trabajo.

Existen dos formas de diseñar una diagramación con flechas. En la figura 32, la actividad es represen-tada por la fecha, en que los círculos ilustran el comienzo y el fin de la actividad. También se puede confeccionar este diagrama representando las actividades en círculos, según ilustra la figura 33. Las flechas representan la secuencia determinada para las actividades del proyecto.

Figura 34: Diagrama ADM

Figura 33: Enlace de actividades Figura 32: Enlace de eventos

A

Actividad A

A B

Actividad A-B

1

2

3

4

5

6

103

C6

6.2.1.3. Método de diagramación por precedencia (Precedence diagramming method – PDM)

El PDM es una técnica de representación visual que describe las actividades de un proyecto. Es una herramienta que aporta muchos beneficios, como por ejemplo:

– Comunicación clara: Su representación visual permite entender claramente el flujo de desarrollo del proyecto y sus implicaciones.

– Identificación de actividades “olvidadas”: Cuando una actividad no es identificada, conse-cuentemente no será incluida en la red y, por supuesto, no será desarrollada. La PDM permite, a través del análisis de su estructura, la ausencia de alguna actividad en el proyecto.

– Identificación de las dependencias: En la PDM, cada actividad es dependiente de alguna acti-vidad predecesora. Cuando una dependencia no es identificada, el proyecto seguramente termi-nará retrasado. Por ejemplo, si un componente crítico está siendo producido por un proveedor ex-terno, el producto final dependerá del proveedor, es decir, aunque todas las actividades internas hayan sido correctamente completadas, el proyecto no estará finalizado hasta que el proveedor suministra el componente crítico. Este un ejemplo de dependencia que debe ser identificada y por supuesto, contemplada en la PDM.

– Identificación de las actividades críticas: Algunas actividades tienen un mayor impacto en la programación del proyecto que otras. Mediante el uso de la PDM, es posible determinar las acti-vidades críticas a la programación del proyecto. Esto se conoce como método del camino crítico (descrito con profundidad en la sección 6.5.1.2).

– Creación del cronograma del proyecto: El objetivo final de todo PDM es crear un cronograma de trabajo fiable.

Relaciones de precedencia:

– Finalizar para comenzar (Finish-to-start): Muchas de las actividades de un proyecto contienen esta relación lógica. Es, sin duda, la relación más común de todas. En esta relación, la actividad predecesora (A) debe ser concluida para que la actividad sucesora (B) pueda empezar. Esto no quiere decir que la actividad sucesora (B) finalice inmediatamente tras el término de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, después de aplicar la masilla, se puede empezar la pintura en cualquier momento, pero es lógico que no se podrá pintar la pared antes que se aplique la masilla.

Figura 35: Relación finish-to-start

A

B

104


– Comenzar para finalizar (Start-to-finish): Esta relación es la menos utilizada en un proyecto. La actividad predecesora (A) debe empezar antes de que finalice la actividad sucesora (B). No es ne-cesario que la actividad sucesora (B) finalice inmediatamente después del comienzo de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, el aprendiz puede empezar a pintar (A) antes de la llegada del jefe de pintura (B), pero no podrá rematar la pintura (A) antes su llegada (B).

Figura 36: Relation start-to-finish

– Finalizar para finalizar (Finish-to-finish): La actividad predecesora (A) debe finalizar antes de que fina-lice la actividad sucesora (B). No es necesario que la actividad sucesora (B) concluya inmediatamente después del término de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, el jefe de la pintura no podrá terminar la revisión de la pintura (B) antes que el aprendiz termine de pintar (A).

Figura 37: Relation finish-to-finish

– Comenzar para comenzar (Start-to-start): La actividad predecesora (A) debe empezar antes de que empiece la actividad sucesora (B). No es necesario que la actividad sucesora (B) empiece inmediatamente después de la puesta en marcha de la actividad predecesora (A), pero no podrá empezar antes. Para ilustrar un ejemplo, cogeremos una vez más el caso de la pintura de una ha-bitación. Las dos actividades son: (A) la llegada del jefe de pintura y (B) pintar la pared. El aprendiz de pintura no puede empezar a pintar (actividad B), antes que llegue el jefe de pintura (actividad A);

Figura 38: Relación start-to-start

– Leads y Lags: Para acabar el tema de las relaciones entre actividades es importante mencionar los leads y lags. Se trata de retrasos o adelantos que, a veces, son impuestos entre actividades de un proyecto, sin modificar su relación.

*Nota del autor: Una lag es un retraso o un “tiempo de espera” entre actividades. En el ejemplo de la pintura, cuando se aplica la masilla, es necesario esperar un tiempo para que esta pueda secar, y a continuación empezar la pintura. Si establecemos un tiempo de secado de ocho horas, este será el lag entre una actividad y la posterior. La actividad B (pintar la pared) no podrá empezar hasta ocho horas después de completada la actividad A (aplicación de la masilla).

Por otro lado, una lead es aceleración entre actividades. Una forma de “provocar” una lead es realizando dos tareas en paralelo, cuando lo normal es que deberían ser realizadas en secuencia.

Por ejemplo, tras la aplicación de la masilla en la pared, se podría instalar la cornisa mientras se espera por el secado de la masilla y antes que empiece la pintura de la pared. Es decir, la actividad C (instalación de la cornisa) empezaría ocho horas antes de la actividad B (pintar la pared). De esta forma, el tiempo necesario para la ejecución y finalización de la actividad C sería absorbido por el tiempo de espera entre la actividad A y B.

B

A

B

A

B

A

105

C6

Teniendo en cuenta los conceptos de relación de dependencias, ya es posible confeccionar un dia-grama de red. Para ello, es importante saber:

– Qué actividades deben empezar antes de una actividad concreta.

– Qué actividades no pueden empezar antes que se finalice una actividad concreta.

– Qué actividades pueden ser desarrolladas simultáneamente.

A partir de la información recogida de la estructura detallada trabajo – EDT (descrita en la sección 5.3), se confecciona una tabla donde se clasifican las actividades del proyecto y se identifican sus predecesores. Todavía no se han realizado las estimaciones de duración o adjudicación de recur-sos. De momento, la única preocupación es establecer la relación entre las actividades. El ejemplo que se desarrolla a continuación ilustra las actividades para la puesta en marcha de un viaje de fin de semana.

Actividad Descripción PredecesoraDuración (en

minutos)

1 Revisar documentación 3 10

2 Llamar taxi y dirigirse al aeropuerto 6 30

3 Reservar hotel y vuelo 5 30

4 Separar ropas 3 30

5 Establecer las fechas del viaje – 10

6 Dormir y despertar a la hora programada 1, 4, 7 480

7 Preparar el equipaje 3 30

8 Aterrizar en el destino programado 9 120

9Realizar check-in y embarque en

los horarios establecidos2 120

Figura 39: Tabla de actividades de la EDT

Note que en la propia tabla de actividades de la EDT se pueden establecer sus duraciones. La du-ración de una actividad será estimada por el esfuerzo previsto, es decir el tiempo que uno o más recursos necesitarán para ejecutarla. Este esfuerzo normalmente es estimado por número de horas (o minutos, como ilustra la figura 39, por tratarse de un proyecto de tres días).

La columna de las predecesoras es fundamental para poder enlazar la secuencia de las actividades y construir el diagrama correspondiente, según ilustra la figura abajo:

Figura 40: Secuencia de actividades

5 3 4

1

7

6 2 9 8

106


Según explicado anteriormente, hay casos muy frecuentes en que el Project Manager y su equipo suelen realizar estimaciones muy optimistas. Para definir correctamente la duración de una actividad, se debería contar con la experiencia de expertos, que podrán aportar estimaciones más realistas.

Convirtiendo el diagrama en un cronograma: El producto resultante de la confección del diagrama de red y de la estimación de las duraciones de cada actividad resultará en el cronograma, que tendrá un aspecto semejante al que ilustra la figura a continuación. Para conocer más detalles acerca del desarrollo de un cronograma, véase también sección 6.5.

Figura 41: Cronograma del proyecto

6.2.1.4. Método del camino crítico (Critical path method – CPM)

El método CPM o camino crítico (critical path method - CPM) fue desarrollado en 1957 por la empre-sa americana DuPont, y su objetivo principal es establecer la duración de un proyecto, entendiendo este como una secuencia de actividades que se relacionan entre sí, donde cada una de ellas tiene una duración determinada.

Un camino o ruta es el recorrido (o recorridos) realizada por el proyecto a través de la secuencia lógica de sus actividades desde el inicio hasta el final. En este sentido, cada camino tendrá sus longitudes, siendo una de ellas considerada un camino crítico, y será siempre la más grande del proyecto. El ca-mino crítico tiene una característica principal: no hay tiempo de holgura entre las actividades, y por ello, ninguna de ellas puede retrasarse. El camino crítico solo permite holgura si una de sus actividades es completada antes del plazo previsto.

El desarrollo del CPM es realizado a través de los siguientes pasos:

– Se identifican las actividades del proyecto: A través de la EDT (véase también sección 5.3) se recogen todas las actividades necesarias para el desarrollo del proyecto.

– Se establecen las relaciones entre las actividades. Decidir cuál debe comenzar antes y cuál debe seguir después.

CRONOGRAMA2003 2003

5 6 7 8 9 1 2 3 4 5

Actividad 1

6 7 8 9

Actividad 2

Actividad 3

Actividad 4

Actividad 5

Actividad 6

Actividad 7

Actividad 8

107

C6

– Se confecciona el diagrama de red. Conectando las diferentes actividades en base a sus rela-ciones de precedencia.

– Se define el tiempo estimado para cada actividad.

– Se identifica la trayectoria más larga del proyecto. Siendo esta la que determinará la duración del proyecto (el camino critico).

Una CPM puede proporcionar una gran cantidad de informaciones, y para poder conocerlas, es im-portante establecer los siguientes parámetros para cada actividad:

Para organizar correctamente el camino crítico es importante cumplir un requisito importante: Organi-zar todas las actividades secuencialmente, identificando sus sucesoras y predecesoras y establecien-do sus fechas de inicio y fin, que se desglosan en cuatro tipos:

Figura 42: Diagrama de red según el CPM

– Inicio más temprano - IT (early start - ES): Representa la fecha de inicio más temprana en que se pude iniciar una actividad, basada en el diagrama de red del cronograma del proyecto. Para las primeras actividades del proyecto esta fecha es la fecha de comienzo del proyecto.

– Inicio más lejano - IL (late start - LS): Es la fecha más de inicio tarde en que se puede iniciar una actividad, basada en el diagrama de red del cronograma del proyecto.

– Finalización más temprana - FT (early finish – EF): Representa la fecha más temprana posible de fi-nalización de una determinada actividad, basada en el diagrama de red del cronograma del proyecto.

– Finalización más lejana - FL (late finish - LF): Representa la fecha más tardía de finalización de una determinada actividad, sin provocar retrasos en el proyecto. Las fechas de finalización tardías son determinadas durante el cálculo del camino crítico a partir del final del proyecto hacia el principio.

Ejemplo práctico:

Para desarrollar correctamente el método del camino crítico, es necesario previamente realizar las siguientes acciones:

– Una vez identificadas las actividades del proyecto, se determinan sus sucesores y predecesores, estableciendo de esta forma las rutas lógicas que el proyecto tendrá que recorrer desde el inicio hasta su fin.

– Es imprescindible conocer cuál es la duración estimada de cada actividad, antes de desarrollar el diagrama, puesto que la duración será siempre el punto de partida para conocer los otros valores de la red. Tal y como ilustra la figura 43, la duración de las actividades se disponen en el recuadro central superior de la actividad correspondiente.

Actividad A0 000 0

0 000 0Actividad C0 000 0

0 000 0

Actividad B0 000 0

0 00 0Actividad F0 000 0

0 000 0Actividad E0 000 0

0 000 0

Actividad D0 000 0

0 000 0Actividad X

InicioTemprano

FinalizaciónTemprana

InicioTardío

FinalizaciónTardia

DURACIÓN

HOLGURA

108


Como regla general el inicio y el fin son considerados hitos, y por ello su duración será siempre igual a cero.

Figura 43: Diagrama de red con sus rutas lógicas y duraciones correspondientes

Tal y como podemos apreciar en la figura 43, las actividades del proyecto ya están enlazadas por varias rutas lógicas y sus actividades predecesoras debidamente identificadas. Es fundamental añadir un “INICIO” y un “FIN” al diagrama, para no dejar ninguna actividad “suelta”. De esta forma, tenemos el diagrama debidamente atado. Es importante mencionar otra vez, que el inicio y fin son hitos, y, por lo tanto, tendrán duración igual a cero.

Conociendo la duración de todas las actividades, ya podemos establecer cuáles serán las fechas de inicio más temprano y finalización más temprana. En el la figura 44, las actividades “A”, “B” y “C”, em-piezan simultáneamente, a partir del inicio (que tiene duración igual a cero), por lo tanto, sus fechas de inicio más temprano será igual a “cero” y las fechas de finalización más temprana serán: cero + la duración correspondiente.

Figura 44: Las fechas de inicio más temprano se sitúan el recuadro superior izquier-do y las de finalización más temprana en el recuadro superior derecho

D3

C4

0

B6

A2

G2

E5

F4

FIN (0)INICIO (0)

C0 4 4

0

B0 6 6

A0 2 2

INICIO (0)

109

C6

Para obtener entonces las fechas de inicio y finalización de las siguientes actividades, se realizan los siguientes cálculos:

Actividad D: IT (2) + duración (3) = FT (5)

Actividad E: IT (4) + duración (5) = FT (9)

Actividad F: IT (2) + duración (4) = FT (6)

Figura 45: Diagrama de red con sus fechas y duraciones

En el caso de la actividad “G” tenemos una situación especial. Tal y como se puede observar en la figura 46, esta actividad tiene 3 predecesoras (B, D y E). Cuando esto ocurre, siempre se elegirá el valor de la actividad predecesora que posee el mayor valor. En este caso, sería la actividad “E” que tiene un FT = 9. De esta forma:

IT de la actividad “G” es igual al FT de la actividad “E” + duración de la actividad “G” = 9 + 2 = 11.


D2 3 5

C0 4 4

0

B0 6 6

A0 2 2

G2

E4 5 9

F2 4 6

FIN (0)INICIO (0)

D2 3 5

B0 6 6

G9 2 11

E4 5 9

110


Con el fin del proyecto pasa lo mismo. Como se encuentra enlazado por dos actividades predeceso-ras (F y G), se elegirá la que tenga la FT mayor. En este caso, sería la actividad “G” que tiene un FT = 11. De esta forma, el fin del proyecto será:

= FT de la actividad “G” + duración del “FIN” = 11 + 0 = 11.


El camino de vuelta

Ahora, tenemos que hacer el camino de vuelta, para conocer las fechas de inicio y fin lejano (IL y FL).

Para empezar correctamente con el camino de vuelta, tenemos que tener en cuenta lo siguiente:

La FL del “FIN” será siempre igual a su “FT”, en este caso será 11.

La FL de las actividades predecesoras del “FIN” será siempre igual al FL del “FIN”, con lo cual, las actividades “F” y “G” tendrán un FL = 11.

Figura 48: El camino de vuelta

A continuación, se aplican las FL de cada actividad predecesora y restando con la duración correspon-diente, encontraremos sus IL correspondientes, lo que nos proporcionará los siguientes resultados:

IL de “G”:

IL de “F”:

IL de “E”:

IL de “D”:

IL de “C”:

IL de “B”:

IL de “A”:

11 - 2 = 9

11 - 4 = 7

9 - 5 = 4

9 - 3 = 6

4 - 4 = 0

9 - 6 = 3

6 - 2 = 4

G9 2 11

F2 4 6

FIN (0)

1111

G9 2 11

11

F2 4 6

FIN (0)

1111

11

111

C6

Figura 49: El camino de vuelta

La actividad “A” tiene dos sucesores “D” y “F”. En el camino de vuelta, cuando una actividad se enlaza con dos sucesoras, se elige la de menor valor, es decir: IL de “A” = IL de “D” (6) – 2 = 4.

Tras calcular las fórmulas correspondientes en el camino de ida y vuelta, ya conocemos todas las fechas posibles del proyecto. (IT, FT, IL y FL) y tenemos todo el grafico completo.

Nos queda por fin, conocer el camino crítico del proyecto, y para ello necesitamos encontrar las hol-guras de cada actividad, representadas en el recuadro centrar inferior, que es el único recuadro que se ha quedado de momento sin ningún valor.

Las holguras se obtienen restando el FL del FT de cada actividad (FL – FT), es decir:

Actividad A:

Actividad B:

Actividad C:

Actividad D:

Actividad E:

Actividad F:

Actividad G:

6 - 2 = 4

9 - 6 = 3

4 - 4 = 0

9 - 5 = 4

9 - 9 = 0

11 - 6 = 5

11 - 11 = 0

Y de esta forma, hemos obtenido la holgura de todas las actividades. Nos queda por fin, lograr el ob-jetivo principal de esta herramienta, que es identificar el camino crítico del proyecto.

D2 3 5

6 9

C0 4 4

0 4

B0 6 6

3 9

A0 2 2

4 6

G9 2 11

9 11

E4 5 9

4 9

F2 4 6

7 11

INICIO (0) FIN (0)

1111

11

112


Identificando el camino crítico

Esta operación es muy sencilla. Simplemente se marcan las actividades cuya holgura es igual a cero; en este caso, serían las actividades “C”, “E” y “G”, además del inicio y del fin.

Figura 50: El camino crítico

La duración de todas estas actividades será lo que indique el FL del fin, en este caso, once días, o sea, el camino crítico de este proyecto tiene once días, y por no disponer de holguras, ninguna activi-dad podrá retrasarse. Por todo ello, el Project Manager tendrá que asegurar que:

– La actividad “C” empiece el día 0 y termine el día 4.

– La actividad “E” empiece el día 4 y termine el día 9

– La actividad “G” empiece el día 9 y termine el día 11.

Si estas fechas no se cumplen, todo Si esto ocurre, todo el proyecto se retrasará.

Las otras actividades podrán retrasarse acorde con la holgura que cada una dispone, por ejemplo: La actividad A dispone de una holgura de cuatro días, por lo tanto, si hiciera falta, esta actividad podría empezar el día uno o dos y terminaría el día tres o cuatro.

Figura 51: Las holguras de una actividad

*Nota del autor:

– Las actividades del camino crítico no son necesariamente las técnicamente más importantes del proyecto.

– Para utilizar el método CPM correctamente, es imprescindible conocer todos los tiempos de duración de cada actividad del proyecto, es decir, no puede haber incertidumbre.

– En un diagrama como el presentado, los cálculos de ida y vuelta son sencillos. No obstante, nos podemos encontrar con diagramas bastante complejos, y por ello se recomienda el uso de programas informáticos. El CPM es una de las herramien-tas clave del Project Management, y cualquier error podría provocar graves daños al proyecto.

– Las actividades que forman parte del camino crítico deben ser las actividades que el Project Manager deberá dedicar más atención. Todo y cualquier retraso en el camino crítico provocará un retraso en todo el proyecto. Tampoco es recomendable abusar de las holguras de determinadas actividades. Cualquier incidencia podrá incrementar un riesgo importante en las fechas de las actividades subsecuentes.

– En 1997, el físico israelí Eliyahu Goldratt publicó su best seller Critical Chain (Cadena Crítica) que aportaba una técnica innova-dora que permitiría completar los proyectos en un tiempo significativamente más corto que utilizando las técnicas tradicionales de administración de proyectos. El método de la cadena crítica es considerado por muchos autores como la evolución del método del camino crítico, y podremos conocerlo en profundidad, en la sección 6.5.1.2 de este capítulo.

D2 3 5

6 9

C0 4 4

0 0 4

B0 6 6

3 9

A0 2 2

4 6

G9 2 11

9 0 11

E4 5 9

4 0 9

F2 4 6

7 11

INICIO (0) FIN (0)

1111

11

A0 2 2

4 4 6

1 o 2 3 o 4

113

C6

6.2.1.5. Determinación de dependencias (Dependency determination)

Para determinar la secuencia entre actividades, se pueden emplear tres tipos de dependencias:

– Dependencias obligatorias: Son las dependencias consideradas contractualmente obligatorias o inherentes a la naturaleza del proyecto. El equipo del proyecto determinará qué dependencias son las obligatorias, durante el proceso de establecimiento de secuencia de las actividades. Un ejemplo de dependencia obligatoria es la construcción de un edificio, donde es imposible erigir su estructura hasta que no se realicen las labores de excavación.

– Dependencias discrecionales: En este caso, el equipo del proyecto podrá establecer las depen-dencias de las actividades libremente, aunque es prudente hacerlo de acuerdo con la experiencia obtenida de proyectos similares de éxito u obedeciendo el estándar de las mejores prácticas del sector. Este tipo de dependencias deben estar bien documentadas, pues sus resultados podrán definir estándares internos para proyectos futuros similares de la organización, además de ser una importante fuente de consulta de “lecciones aprendidas”.

– Dependencias externas: Son dependencias que implican una relación entre las actividades del proyecto y aquellas que no pertenecen al proyecto, y por ello se encuentran parcial o total-mente fuera de control de la organización. Podrán depender de la ejecución de un profesional o empresa externo a la organización, o en algunos casos, dependerá también de la decisión y/o aprobación de la administración pública. Por ejemplo, la ampliación de un aeropuerto depen-derá de la aprobación del presupuesto del Ayuntamiento o Junta correspondiente, o la puesta en marcha de una determinada maquina podrá depender de la entrega de algún componente fabricado fuera del país.

6.2.1.6. Aplicación de adelantos y retrasos (Applying leads and lags)

Una lag es un retraso o un “tiempo de espera” entre actividades. En el ejemplo de la pintura, cuando se aplica la masilla, es necesario esperar un tiempo para que esta pueda secar, y a continuación empezar la pintura. Si establecemos un tiempo de secado de ocho horas, este será el lag entre una actividad y la posterior. La actividad “B” (pintar la pared), no podrá empezar hasta ocho horas después de completada la actividad “A” (aplicación de la masilla).

Por otro lado, una lead es aceleración entre actividades. Una forma de “provocar” una lead es realizan-do dos tareas en paralelo, cuando normalmente deberían ser realizadas en secuencia. Por ejemplo, tras la aplicación de la masilla en la pared, se podría instalar la cornisa mientras se espera por el se-cado de la masilla y antes que empiece la pintura de la pared. Es decir, la actividad “C” (instalación de la cornisa) empezaría ocho horas antes de la actividad “B” (pintar la pared). De esta forma, el tiempo necesario para la ejecución y finalización de la actividad C seria absorbido por el tiempo de espera entre la actividad “A” y “B”.

6.2.1.7. Plantillas de red de cronograma (Schedule network templates)


6.3. Estimación de los recursos de las actividades (proceso que corresponde a la fase de planificación del proyecto)

Este proceso consiste en estimar el tipo y las cantidades de recursos necesarias para ejecutar correc-tamente cada actividad de un proyecto. Como “recurso” podemos entender por ejemplo, materiales, personas, maquinaria, equipos informáticos y suministros en general.

114





6.3.1.2. Datos de estimación publicados (Published estimating data)

Muchas empresas publican periódicamente los costes unitarios de sus recursos para una amplia va-riedad de materiales y equipos en diferentes países. Es una fuente de información que aporta datos fiables para la estimación de recursos.

6.3.1.3. Estimación ascendente (Bottom–up estimating)

Cuando una actividad tiene unas características que dificultan una estimación fiable, se utiliza la téc-nica de estimación ascendente que funciona de la siguiente forma: se descomponen los trabajos de esta actividad a un nivel mayor de detalle, y se estiman los recursos necesarios para ejecutar cada actividad individualmente. A continuación, se van totalizando los costes encontrados, cuya suma total corresponderá al coste total de la actividad.

Para esta estimación es muy interesante utilizar la estructura detallada del trabajo - EDT (para más detalles, véase también la sección 5.3). La ventaja de esta técnica es que ella produce resultados bastante fiables. La desventaja es que estos resultados necesitan de un periodo de análisis considerablemente largo.

Se estiman los costes y las duraciones desde los niveles más bajos (paquetes de trabajo)

Figura 52: Aplicación de la estimación ascendente en la EDT

6.3.1.4. Software de gestión de proyectos (Project Management Software)

Para poder desarrollar una gestión de proyectos eficiente, el Project Manager debe hacer uso de siste-mas y procedimientos que colaboren en la administración del proyecto junto con su equipo. Los últimos avances tecnológicos han contribuido bastante, ofreciendo en el mercado un amplio abanico de opcio-nes de herramientas verticales, como los de gestión financiera, de plazos e incluso de recursos. El mer-cado dispone también de potentes aplicaciones de gestión de documentos que evitan la duplicación in-necesaria de datos y la pérdida de información y que generan formatos profesionales para su publicación.

115

C6

Sin embargo, gestionar un proyecto no se limita solamente a utilizar aplicativos informáticos. No hay dudas de que el uso de una buena herramienta informática es fundamental para desarrollar un pro-yecto. No obstante, nada puede sustituir el sentido común, la experiencia y el juicio de expertos. Es importante tener claro que un software no puede:

– Asegurar que la información es apropiada, actualizada y correcta: Durante el desarrollo del pro-yecto, los integrantes del equipo, registrarán datos técnicos y de gestión del proyecto en el sistema de información disponible por la organización. El Project Manager podrá revisar y formatear toda la información registrada, pero el programa no puede asegurar la fiabilidad de los datos imputados.

– Tomar decisiones: Un programa informático puede perfectamente auxiliar el Project Manager a la hora de tomar decisiones, generando informes y una serie de resultados, pero no puede de forma alguna, decidir por él.

– Crear y sostener relaciones interpersonales de forma dinámica: A pesar de que las personas son fascinadas por chat, e-mails, redes sociales y otros tipos de aplicaciones volcadas a las re-laciones interpersonales, un programa no puede asegurar la fiabilidad de cualquier relación entre personas. Además, ningún programa tiene la habilidad de comunicar un mensaje de forma tan personal y dinámica, como las expresiones faciales y el lenguaje del cuerpo.

Por lo tanto, tenga en cuenta las limitaciones de una aplicación informática e intente sacar lo mejor que la tecnología puede ofrecer. Si has decidido utilizar un software de gestión integral es importante seguir las recomendaciones a continuación:

– Programas utilizados pela organización: Verifique los programas que son utilizados por otros equipos de proyecto de la organización. Pregunte cuáles son los aspectos que ellos más valoran y qué prestaciones les gustaría tener.

– Versión de demostración: Si ya sabes cual es el programa que pretendes adquirir, intente con-seguir una versión de demostración, para poder explotarlo durante un periodo.

*Nota del autor: Los softwares del Project Management más utilizados en el mercado son:

Open-Source desktop applications

– KPlato (www.koffice.org)

– OpenWorkbench (www.openworkbench.org)

– TaskJuggler (www.taskjuggler.org)

– GANTT Project (http://ganttproject.biz)

Open-Source web-based applications

– Bugzilla (www.bugzilla.org)

– dotProject (sourceforge.net/projects/dotproject)

– Eventum (https://launchpad.net/eventum)

– Mantis Bug Tracker (www.mantisbt.org)

– Project.net (www.project.net)

– ProjectPier (www.projectpier.org)

– Trac (http://trac.edgewall.org)

Proprietary desktop applications

– Artemis (http://www.svibs.com)

– CerebralProject(TM) (www.cerebralproject.com)

– Collanos Workplace (www.collanos.com)

– Microsoft Project (www.microsoft.com)

– Merlin (www.projectwizards.net/en/merlin)

– OmniPlan (www.omnigroup.com)

– Planisware OPX2 Pro (www.planisware.com)

– SophoclesPM (www.mediafire.com/sophocles)

Proprietary web-based applications

– 24SevenOffice (http://24sevenoffice.com)

– @task (www.attask.com)

– Basecamp (http://basecamphq.com)

– Central Desktop (www.centraldesktop.com)

– JIRA (www.atlassian.com/software/jira)

– Project Insight (www.projectinsight.net)

– ProjectHand (www.natara.com/projectathand2)

– Teamwork (www.twproject.com)

– Wrike (www.wrike.com)

– TOPdesk (www.topdesk.com)

116


– Prácticas: Una vez que tenga la versión de demostración instalada, intente crear proyectos senci-llos. De esta forma será más fácil hacer un recorrido general por todas las funciones del programa.

– Compatibilidad: Asegúrese que el producto es compatible con los sistemas existentes en la empresa. Verifique si el programa es capaz de generar los gráficos, informes o cualquier otro tipo de información que el proyecto necesite.

– Formación: Matricúlese en algún curso de formación. Es importante establecer contacto con otras personas que conozcan el programa. Incluso, si posible, forme parte de algún foro de In-ternet. En los foros será posible conocer las ventajas y desventajas del programa, a través de la opinión de usuarios más experimentados.

6.4. Estimación de duración de actividades (proceso que corresponde a la fase de planificación del proyecto)

La estimación de duración de actividades es el acto de cuantificar la cantidad de tiempo necesaria para finalizar una determinada actividad. Normalmente esta estimación se realiza sobre el esfuerzo dedicado a esta actividad en término de horas. De esta forma, si un trabajador está disponible las ocho horas diarias de su jornada laboral, sería muy sencillo realizar la estimación de sus activida-des en un proyecto. Sin embargo, este tipo de circunstancia no suele ocurrir en el mundo real. Existen muchas variables que dificultan la realización de estimaciones fiables. Algunas de estas variables son:

– Variables de conocimiento: Difícilmente un grupo de trabajadores tiene la misma capacidad de trabajo. Unos pueden tener más conocimientos o habilidades que otros.

– Eventos inesperados: Eventos de la naturaleza como tormentas de nieve, lluvia, incluso huracanes pueden perjudicar el plazo de conclusión de una tarea. Otras incidencias pueden ocurrir, como por ejemplo, retrasos por parte de proveedores, problemas burocráticos, cortes de energía, entre otros.

– Interrupciones: Las tareas que un trabajador desarrolla en un proyecto son frecuentemente inte-rrumpidas por el teléfono, e-mail, reuniones, desayunos y charlas con los compañeros.

– Equivocaciones: Es común que ocurran fallos que culminan en una tarea desarrollada de forma equivocada.

La curva de aprendizaje

Existe un concepto llamado “curva de aprendizaje”, que es un modelo matemático que demuestra que la repetición de una determinada actividad conlleva a que su tiempo de desarrollo sea cada vez más reducido y consecuentemente sus costes también. Por ejemplo, el montaje de una misma máquina por la centésima vez será mucho más rápido y menos costoso que la primera vez. Es algo que el Project Manager deberá tener en cuenta a la hora de estimar duraciones.

Nota del autor: Dos trabajadores no realizan una actividad en la mitad de tiempo

Otro detalle muy importante y que suele ocurrir con una cierta frecuencia es pensar que dos personas realizan una actividad en la mitad de tiempo. Consecuentemente, se podrá pensar que tres personas llevarán un tercio del tiempo, y así sucesivamente. En estas horas hay que tener en cuenta que dos madres no pueden generar un niño en cuatro meses y medio.

Es una equivocación muy común pensar que se puede disminuir la ejecución de una actividad, añadiendo más recursos a ella. Es cierto que se nota una reducción, pero no en una escala lineal. Aumentar el número de trabajadores puede realmente reducir el tiempo de ejecución de una tarea, pero este tipo de medida también provoca un incremento de costes, que en algunos casos no compensa. El Project Manager deberá saber estimar el número correcto de recursos que pueden ser asignados a una tarea sin comprometer su duración y/o incrementar indebidamente los costes.

117

C6

Figura 53: Curva de aprendizaje

Algunos proyectos incluyen actividades muy familiares cuyas estimaciones son sencillas de realizar. No obstante, en muchos casos, hay un total desconocimiento de la duración necesaria para llevar a cabo una determinada tarea, sobre todo en proyectos innovadores. No importa cuál sea el caso, siempre será necesario realizar estimaciones considerando las variables descritas anteriormente.

Algunas consideraciones importantes acerca de la estimación de duración de actividades:

– Es importante tener como base el calendario laboral y estimar las duraciones en días laborales.

– Verificar la existencia de festivos durante los periodos de ejecución del proyecto.

– Las horas extra no se consideran.

– El nivel de experiencia del personal es un factor importante a la hora de realizar estimaciones de tiempo.

– Incluir las reuniones de revisión en los cronogramas. En muchos casos, las reuniones pueden llegar a consumir el 10% del tiempo total de un proyecto.

– Considerar tiempos de viaje y desplazamientos;

– Considerar la disponibilidad de infraestructuras (equipos informáticos, maquinaria, vehículos, entre otras).

– Tener siempre en cuenta que los trabajadores necesitan formación, pueden estar asignados a más de un proyecto, cogen vacaciones y a veces solicitan bajas médicas por problemas de salud.




0 10 20 30 40 50 60 70 80 90

1000

2000

3000

4000

5000

6000

7000

8000

9000

Producción Acumulada

Coste porunidad

producida

118


6.4.1.2. Estimación analógica (Analogous estimating or top–down estimates)

Cuando el equipo se reúne para determinar la duración de las actividades del proyecto, hay casos en que no se dispone de información suficiente para poder realizar las estimaciones correctas. En este caso, se utiliza la estimación analógica, que es una técnica utilizada para determinar la duración de una deter-minada actividad, basándose en otra actividad similar que ha sido desarrollada en un proyecto anterior.

Las organizaciones que desarrollan proyectos muy parecidos cuentan con una base de datos que contiene información valiosa que puede ser aprovechada en otros proyectos y con ello reducir el tiem-po de reuniones para estimación de duraciones.

Esta herramienta suele ser menos costosa que otras técnicas, pero también es menos precisa. Sin embargo, puede ser considerada fiable cuando los proyectos anteriores comprenden un contenido realmente similar y los encargados por realizar las estimaciones son profesionales con experiencia.

6.4.1.3. Estimación paramétrica (Parametric estimating)

Esta técnica utiliza una relación estadística entre datos históricos y otras variables para calcular los costes de un recurso en una determinada actividad del proyecto (ejemplo: metros cuadrados en la construcción, líneas de códigos en desarrollo de software, lauda de texto traducido...). Es una herra-mienta que puede producir resultados muy fiables, dependiendo de la complejidad del proyecto y de la cantidad de información conocida.

6.4.1.4. Técnica de evaluación y revisión de programas (Program evaluation and review technique – PERT)

Inventada en 1958, la técnica de revisión y evaluación de programas (program evaluation and review technique - PERT) es un método utilizado en el análisis de las tareas que forman parte de un proyecto, sobre todo cuando existe un grado importante de incertidumbre en relación a sus duraciones. Tam-bién es conocida como three-point estimating.

El PERT realiza tres estimaciones para cada actividad:

– PesimistaTP: define el mayor tiempo que puede durar una actividad.

– OptimistaTO: define el menor tiempo que puede durar una actividad.

– Más probableTM: define el tiempo más probable que puede durar una actividad.

La fórmula utilizada con el PERT es la siguiente:

(O + 4M + P) / 6

*Nota del autor: El mantenimiento de un archivo de los proyectos realizados permitirá a la empresa disponer de una inagotable y valiosa fuente de información que aportará estimaciones fiables, como es el caso de la estimación analógica.

No obstante, es importante tener en cuenta que los datos aportados por un proyecto de características similares no pueden ser 100% aplicables a un nuevo proyecto, puesto que, en cualquier caso, siempre habrá diferencias que deberán ser consideradas.

Vamos suponer que en un proyecto anterior, la empresa ha construido un puente de cinco kilómetros en dos meses. El siguien-te proyecto prevé la construcción de otro puente que presenta las mismas características del anterior, con una única diferencia que este tendrá una extensión de veinte kilómetros. Haciendo una estimación analógica, se podría estimar un plazo de ocho meses para concluir este proyecto.

No podemos dejar de considerar que existen otras variables a parte del puente. Por ejemplo, el puente anterior fue construido en verano y el nuevo será construido en invierno. Las condiciones climáticas de las estaciones del año tienen un peso importante a la hora de estimar los plazos del proyecto. Además, el puente anterior se construyó sobre un terreno previamente asfaltado y en este nuevo proyecto, el terreno se encuentra en el medio de una zona boscosa, sin haber recibido todavía ningún tratamiento previo.

Como se pudo apreciar, la eficacia de la estimación analógica depende severamente de las similitudes de dos proyectos, con lo que es fundamental realizar una comparación a fondo de todas las características de ambos proyectos.

119

C6

O = Es la estimación optimista para la duración de una determinada tarea.

M = Es la estimación más probable para la duración de una determinada tarea.

P = Es la estimación pesimista para la duración de una determinada tarea.

Figura 54: Gráfico PERT

Estadísticamente, esta fórmula tiende a la estimación a más probable, pero permite algunos ajustes para acomodar los extremos mínimos y máximos.

En la tabla que hay a continuación se ha aplicado la formula PERT en tres actividades. En el caso de la actividad “A” se ha estimado una duración optimista de siete días. En el caso en que surgiera algún tipo de incidencia, la duración podría llegar a catorce días. En condiciones normales la tarea “A” con-sumiría probablemente nueve días. Aplicando la formula PERT, se ha llegado a una duración ajustada de diez días, que añade tres más que la estimación más optimista, pero que no alcanza los catorce días resultantes de una estimación pesimista.

Actividad Optimista Más probable PesimistasDuración ajustada

A 7 9 14 10

B 10 20 27 19

C 13 20 32 21

Figura 55: Tabla PERT

*Nota del autor: ¿Cuánto tiempo se lleva para pescar un pez?

Es una pregunta muy difícil de responder. En algunos casos, puede llevar un minuto y a veces un pescador puede volver a casa con las manos vacías después de pasar todo un día a la orilla del río. Es muy difícil realizar estimaciones, y cuando se estiman las duraciones de un proyecto, normalmente se llega a resultados equivocados.

Para que un PERT pueda aportar el resultado más fiable posible, es muy importante que las duraciones optimistas, pesimistas y más probables sean muy bien definidas. Para llegar a un número adecuado, se recurren a los recursos que se expresan a continuación.

Probabilidadde Ocurrencia

Optimista

Más Probable

Pesimista

( O + 4M + P ) / 6

120


6.4.1.5. Base histórica de proyectos (Historical records)

Un proyecto finalizado correctamente es un proyecto bien documentado. Proyectos que cuentan con una buena documentación pueden guardar informaciones importantes, como, por ejemplo, las esti-maciones de las actividades realizadas para su desarrollo. Hay casos en que se encuentran estima-ciones muy sofisticadas con datos que pueden incluir, además de las duraciones, las características de las actividades y los conocimientos necesarios para realizarlas. La base histórica de proyectos puede incluir:

– Tareas: Muchos proyectos pueden tener actividades muy similares e incluso idénticas. Consultar cómo se ha realizado el desarrollo de estas tareas en proyectos anteriores similares puede ser una forma eficaz de realizar nuevas estimaciones.

– EDT: Es una herramienta de descomposición del trabajo realizado en un proyecto, orientada a los entregables del mismo, que organiza y define su alcance (para más detalles, véase también la sección 5.3).

– Informes: Si la comunicación de un proyecto ha sido correctamente desarrollada, una serie de informes de seguimiento deberían haber sido distribuidos a todos los interesados a lo largo de su ciclo de vida. Estos informes suelen aportar información útil a proyectos futuros, ya que describen posibles problemas encontrados durante el desarrollo de sus actividades y propone las medidas preventivas o correctivas tomadas en su momento.

– Estimaciones: En muchos casos, se podrán encontrar en proyectos anteriores actividades simi-lares. Las estimaciones realizadas pueden aportar informaciones que pueden ser utilizadas en el proyecto actual.

– Planes de proyecto: El plan de proyecto es un documento formal y aprobado por la dirección y es utilizado principalmente para la administración del proyecto de forma general. Se puede aprovechar mucha información de un plan de proyecto similar desarrollado anteriormente y aplicar varias de sus estimaciones en el plan de proyecto actual.

Lecciones aprendidas: (Descrito en la sección 11.2.1.16).

– Riesgos: El nivel de riesgo de un proyecto dependerá sobre todo de la cantidad de información disponible. De cuanta más información disponga el equipo, menor será el riesgo, ya que el nivel de incertidumbre será reducido.

– Recursos necesarios: Si un proyecto anterior cuenta con una buena documentación de gestión de recursos, ciertamente esta documentación incluirá los procesos, las técnicas, las herramientas y la documentación utilizada para realizar el uso efectivo de las personas involucradas.



6.4.1.7. Técnica delphi (Delphi technique)

La técnica delphi es una metodología de investigación multidisciplinar para la realización de pronós-ticos y predicciones. Fue desarrolla por la Corporación Rand al inicio de la Guerra Fría para investi-gar el impacto de la tecnología en la guerra. El nombre del método se basa en las predicciones del Oráculo de Delfos.

121

C6

Su objetivo es la consecución de un consenso basado en la discusión entre expertos. Esta técnica puede producir buenas estimaciones, y elimina un problema común que suelen ocurrir en las sec-ciones de tormenta de ideas (brainstorming, véase también sección 11.2.1.8), como la timidez o la sensación de intimidación por parte de algún participante. Utilizando la técnica delphi, los participantes pueden contar con el anonimato, una vez que la recogida de opiniones puede ser realizada a través de chat o por e-mail, lo que también añade la ventaja de poder incluir personas de distintas localidades.

En esta técnica, un facilitador (por ejemplo, el Project Manager), solicita a los participantes que apor-ten ideas acerca de los riesgos de un determinado evento. El facilitador recoge todas las ideas envia-das y la centraliza en un listado, que será reenviado a todos los participantes, para que estos puedan añadir más información sobre la lista anteriormente estructurada. Esta lista circulará hasta que no se generen ideas nuevas.

La ventaja principal de esta técnica es que recoge la opinión sobre el proyecto actual basada en experiencias anteriores difíciles de evaluar por otros medios (características especiales del personal, peculiaridades del proyecto...).

6.4.1.8. Reserva de tiempo (Contingency time)

Cuando se estiman duraciones de actividades, se intenta buscar el plazo más próximo a la realidad, y eso puede ser posible utilizando algunas de las técnicas mencionadas anteriormente. Sin embargo, aunque se estime correctamente la duración de una actividad, es común añadir una cantidad de tiem-po extra, por si acaso surge alguna incidencia no esperada.

Existe una teoría llamada ley de Parkinson (Parkinson´s law), creada por Cyril Northcote Parkinson en un artículo publicado en el semanario británico The Economist en 1955 que dice: “El trabajo se am-plia para cubrir todo el tiempo disponible para su conclusión”. O sea, si una determinada tarea tiene un plazo estimado de seis días y se añaden dos más como contingencia, según la ley de Parkinson, esta tarea llevará ocho días para ser completada. Por supuesto, esta teoría no pretende derrumbar la técnica de la reserva de tiempo, pero intenta demostrar que no será simplemente añadiendo un par de días más a cada tarea, que se alcanzará el cronograma perfecto; todo lo contrario, esta práctica puede tornarse un vicio que convertirá el proyecto en un emprendimiento interminable.

La reserva de tiempo o contingencia debe ser utilizada de forma correcta para realmente ser eficaz. Y eso se hace de la siguiente forma: de acuerdo con el tipo de proyecto se añade un por-centaje de tiempo extra al final del proyecto, que será utilizado en tareas que ultrapasen el plazo estimado de conclusión.

Este porcentaje puede variar entre el 5% y el 10% del tiempo total estimado de finalización de todo el proyecto. Se utilizará el 5% en proyectos cuyo grado de incertidumbre es bajo y el 10% cuando se utilizan, por ejemplo, nuevas tecnologías.

Una vez que se determine el plazo total del proyecto, se creará una tarea que será la “reserva de tiempo” y que tendrá como duración el porcentaje necesario de tiempo extra. Esta tarea será la últi-ma tarea del proyecto. De esta forma, las actividades del proyecto contarán con un plazo estimado real sin reservas, y el equipo del proyecto reunirá los esfuerzos necesarios para cumplir con cada plazo determinado.

Imaginemos un proyecto en que se estiman ciento veinte días para su conclusión. Se le añade un 10% de reserva (es decir doce días más). El proyecto tendrá un plazo final de ciento treinta y dos días. Si una determinada tarea consume dos días más que el originalmente previsto, se descontará dos días de la reserva, que pasaría a contar con diez días. Esta técnica permite que el Project Manager pueda gestionar la reserva disponible de forma más dinámica. Si un proyecto ha completado el 35% de sus actividades, pero ya ha consumido la mitad de la reserva, ya se sabe con mucha antelación que el proyecto no avanza según el plan.

122


Estimar correctamente un tiempo adecuado de contingencia no es una labor muy sencilla. No obstan-te, es posible llegar a un valor muy aproximado, obedeciendo algunos principios básicos:

– Cuanto más largo y complejo el proyecto, más tiempo de contingencias será necesario.

– La contingencia aplicada deberá ser proporcional al riesgo del proyecto.

– El tiempo de contingencia podrá ser reducido si el proyecto en marcha es muy similar a algún proyecto anterior.

– Se podrá tomar como base el nivel de experiencia del equipo a la hora de decidir la cantidad de contingencia que será utilizada.

Existe una técnica llamada gestión de proyectos por cadena crítica, descrita en la sección 6.5.1.2, que aporta más informaciones sobre la gestión de las contingencias de un proyecto.

6.5. Desarrollo del cronograma del proyecto (proceso que corresponde a la fase de planificación del proyecto)

El desarrollo del cronograma es un proceso que consiste en analizar las actividades establecidas para un proyecto, su duración, los recursos necesarios y las restricciones identificadas. La in-corporación de todas estas informaciones generará un cronograma con fechas planificadas que deberán ser cumplidas.

El desarrollo de un cronograma es una de las tareas clave de un proyecto y podrá exigir el repaso y una revisión en profundidad de los tiempos de duración estimados de cada actividad y de los recur-sos necesarios para su correcta puesta en marcha. Es importante recordar que un cronograma es un documento que necesita de un seguimiento constante para mantenerse realista y sostenible.


6.5.1.1. Método del camino crítico (Critical path method – CPM)


6.5.1.2. Gestión de proyectos por cadena crítica (Critical chain Project Management – CCPM)

Presentada por el físico israelí Eliyahu Goldratt en 1997 en su libro Critical Chain, la gestión de proyec-tos por cadena crítica (Critical Chain Project Management - CCPM) está basada en algoritmos de su teoría de las restricciones* y se acredita que su técnica es capaz de reducir los costes y plazos entre un 10% y un 50% más que los métodos tradicionales.

Esta técnica ha sido desarrollada para solucionar uno de los vicios más recurrentes del Project Mana-gement, que es la adición de tiempo innecesario a la ejecución de una tarea, observada en varios proyectos, incluso los de alto nivel. A la hora de realizar las estimaciones de duración de una determi-nada tarea, existe una tendencia natural a añadirle más plazo de lo necesario como forma de protec-ción frente a la incertidumbre. Esta protección nos permitirá finalizar la tarea dentro del plazo estimado,

123

C6

incluso en los casos más desfavorables. La figura 56 ilustra cómo solemos realizar nuestras estima-ciones de tiempo de ejecución de tareas:

Figura 56: Estimaciones de tiempo con colchón de seguridad

Como se puede apreciar en la figura 56, una tarea recibe un colchón de seguridad de tiempo que mu-chas veces puede ser del orden del doble de lo que sería la duración media de la tarea. Si aplicamos esta regla a todas las actividades de un proyecto, su tiempo total de finalización sería el doble, es decir, si una obra contiene tareas que normalmente consumen veinte días de ejecución, aplicando colcho-nes de seguridad a todas las actividades del proyecto, la obra tendría un plazo total de cuarenta días para finalizar. El colchón de seguridad nos permite, entonces, terminar el proyecto dentro del plazo, ya que nos ha añadido el doble del tiempo necesario para su ejecución. No obstante, lo que se ve es que el proyecto, por más colchones de tiempo que se añadan, terminará retrasado de la misma forma.

Esto ocurre debido a una teoría conocida como la “síndrome del estudiante” (student syndrome), en el que una persona comenzará a esforzarse en la finalización de una actividad faltando muy poco para el vencimiento de su plazo. La consecuencia principal de esta actitud es la pérdida de cualquier ima-gen de tiempo establecido en la fase de estimación de tiempo de ejecución de actividades. La figura 57 nos ilustra cómo se administra de forma equivocada el esfuerzo dedicado a una actividad. Prácti-camente, durante el 70% del tiempo asignado a esta actividad, el nivel de esfuerzo ha sido mínimo, elevándose sustancialmente en el 30% del tiempo disponible.

Figura 57: Síndrome del estudiante

ESTIMACIÓN TIEMPO

FREC

UEN

CIA

ColchónSeguridad

50%

TIEMPO DE LA ACTIVIDAD

FECHA DEENTREGA

NIV

EL D

E ES

FUER

ZO SINDROME DELESTUDIANTE

124


Lo primero que la cadena crítica pretende defender es la idea de que añadir colchones de seguridad a todas y cada una de las tareas no tiene ningún sentido. Este tipo de actitud nos lleva a preocuparnos por terminar cada tarea a tiempo, cuando lo que realmente importa es finalizar el proyecto en el plazo previsto. La cadena crítica tiene una filosofía totalmente opuesta: trata de gestionar exactamente la imposición del plazo mínimo en que un proyecto puede ser realizado.

Se puede definir entonces la cadena crítica como la secuencia de tareas más corta teniendo en cuen-ta los conflictos de recursos.

A través de la tabla que presento a continuación podemos comparar los conceptos de la cadena crítica con las técnicas de gestión tradicionales:

Método tradicional Método de la cadena crítica

Protege las tareas individualmente con buffers de seguridad.

Protege la finalización total del proyecto con buffers.

Énfasis en la evolución de la tarea. Énfasis en la evolución del proyecto.

Énfasis en la evolución de la tarea.Inicio de las actividades solamente

cuando sea necesario.

Realización de múltiples tareas.Minimización de la realización de múltiples

tareas a través de la distribución de prioridades.

Reacción a las incertidumbres a través del cambio de prioridades, estableciendo nuevos horarios.

Gestiona la incertidumbre monitorizando el impacto de los hechos en el

consumo de los buffers.

Figura 58: Método de la cadena crítica x método tradicional

El método de la cadena crítica es considerada como uno de los más importantes avances en el Pro-ject Management en los últimos treinta años y tiene su origen en la teoría de las restricciones (véase también “nota del autor”, al final de esta sección).

De acuerdo con Goldratt, las previsiones de las estimaciones son normalmente aportadas por perso-nas distintas, que, en algunos casos, no tienen acceso a toda la información del proyecto, causando una cierta incertidumbre que, naturalmente, les motivará a añadir un colchón de seguridad muchas veces innecesario.

La cadena crítica, por lo tanto, sugiere que se planifiquen las actividades estimando sus duraciones de forma agresiva, reduciendo el tiempo hasta un nivel que permita la realización de su ejecución sin comprometer su calidad.

Actividad A Actividad B Actividad C

Duración estimada

ColchónDuración estimada

ColchónDuración estimada

Colchón

Figura 59: Tabla con las actividades y sus colchones de seguridad

*Nota del autor: La esencia de la teoría de las restricciones se basa en cinco puntos:

1. Identificar las restricciones del sistema.

2. Decidir cómo explotarlas.

3. Subordinar todo a la decisión anterior.

4. Superar la restricción del sistema (elevar su capacidad).

5. Si en los pasos anteriores se ha roto una restricción, regresar al paso 1.

Para conocer en profundidad la metodología de la cadena crítica, consulte la obra de Eliyahu M. Goldratt Cadena Crítica – Una novela empresarial sobre la gestión de proyectos, editorial Díaz de Santos.

125

C6

Actividad A Actividad B Actividad C Colchón

Duración estimada Duración estimada Duración estimada

Figura 60: Tabla con las actividades y sus colchones de seguridad dispuesta al final del cronograma.

Este tipo de estrategia permite eliminar una serie de colchones de seguridad añadidos innecesaria-mente que “inflan” el proyecto, volviéndole más manejable y con estimaciones más realistas.

6.5.1.3. Nivelación de recursos (Resource leveling)

Una de las grandes dificultades en el Project Management es asegurar que el trabajo ha sido asig-nado al equipo de forma equilibrada. Si no se logra realizar una adecuada gestión de los recursos del proyecto, se darán casos donde algunos integrantes estarán sobrecargados, mientras otros tendrán demasiado tiempo ocioso.

La nivelación de recursos es una técnica utilizada para evaluar el uso desequilibrado de recursos y resolver sus conflictos y/o asignaciones equivocadas. Actualmente la mejor forma de utilizar esta herramienta es a través de programas informáticos dedicados que son capaces de administrar es-cenarios complejos donde se ejecutan múltiples proyectos a la vez. Cruzando las informaciones de los calendarios de los proyectos y del personal, es posible determinar la cantidad óptima de mano de obra disponible en cada momento del proyecto.

6.5.1.4. Análisis “¿Qué pasa si…?” (What‑if scenario analysis – WISA)

El análisis WISA (¿Qué pasa si…?) es una técnica que utilizamos en nuestro cotidiano, con cuestiones tan sencillas como la que presento a continuación:

Su novia le pide que la lleve al cine este viernes y, como trabajas hasta tarde, decides llevarla a la última sesión, que empieza a las once de la noche. De súbito, te haces la siguiente reflexión: “¿Qué pasa si llegamos al cine y no quedan entradas disponibles?”.

La respuesta a esta pregunta deberá ser una o más soluciones alternativas, por ejemplo: “Si no que-dan más entradas, la llevo a cenar a su restaurante favorito”.

Este tipo de situación se repite decenas de veces en el Project Management. La pregunta “¿Qué escenario podríamos tener sí ocurre una determinada situación?”.

El mercado dispone de un gran abanico de herramientas informáticas WISA, que son capaces de crear varios escenarios para determinadas cuestiones relacionadas con costes, plazos, cambios y riesgos en general.



* Nota del autor: Las herramientas que realizan análisis WISA necesitan de una cantidad importante de información, para poder realizar un análisis eficaz. Por ello, es importante que se introduzcan los siguientes datos:

– La creación de un escenario actual, que será el punto de partida para un análisis “¿Qué pasa si…?”.

– Determinar los valores y variables que harán cambiar los escenarios contemplados.

– Determinar los recursos disponibles para cada escenario sugerido.

Una herramienta muy similar al WISA, es el método de los escenarios, descrita detalladamente en la sección 11.3.1.4.

126


6.5.1.6. Ejecución rápida (Fast tracking)

La técnica de la ejecución rápida significa poner en ejecución dos o más actividades en paralelo, en vez de ejecutarlas secuencialmente. Lógicamente, esta técnica no se puede aplicar en todos los ca-sos, por ejemplo, no se puede levantar un tabique y pintarlo a la vez, pero utilizando correctamente la técnica de la ejecución rápida se podría ir pintando las partes del tabique que ya están listas para la pintura, en vez de esperar a que todo el tabique esté completamente construido. Sin embargo, este tipo de técnica tiene un riesgo involucrado que puede provocar un incremento de coste y plazo, si ocurre algún imprevisto. Por esta razón, es muy importante tener la actividad muy bien planificada, para poder aplicar esta técnica con los riesgos mitigados.

6.5.1.7. Compresión (Crashing)

En el Project Management, el término “compresión” (crashing) significa reducir las actividades del ca-mino crítico con el objetivo de terminar el trabajo antes del tiempo previsto, o en el peor de los casos, en el tiempo originalmente previsto (cuando se aprecia la posibilidad de que el trabajo podría terminar con retraso). Una de las formas más comunes de aplicar la compresión es añadiendo trabajadores a una o más actividades del camino crítico. Si un trabajador está trabajando en una tarea que necesita de diez horas para ser completada, y existe una necesidad de completarla en menos tiempo, se aña-de un segundo trabajador, que posibilitaría la reducción del plazo original de diez horas estimado para la ejecución de esta actividad.

Los recursos añadidos en un proyecto pueden venir de la propia plantilla de la empresa o pueden ser contratados de forma temporal. Esta técnica puede asegurar la entrega de un producto o servicio antes del plazo determinado, pero, sin embargo, implicará en costes añadidos, ya que se incrementan los recursos asignados para completarla en menos tiempo. De todas formas, muchas veces, la em-presa prefiere asumir este incremento de costes, asegurando la entrega dentro del plazo.

En el ejemplo que viene a continuación podemos ver una serie de actividades cuya duración estimada total es de cuarenta días.

Figura 61: Serie de actividades

Situación actual del proyecto Aplicando la “compresión”

ActividadDuración (en días)

CosteDuración (en días)

CosteCoste diario de la compresión

A 10 10.000 5 18.000 1.600

B 10 5.000 5 7.000 400

C 10 10.000 5 15.000 1.000

D 5 15.000 2 22.000 3.500

E 5 5.000 2 6.000 500

Totales 40 horas 40.000 € 19 horas 68.000 € 7.000 €

Figura 62: Aplicación de la compresión

* Nota del autor: Algunos autores estiman que en algunos casos se puede aplicar la ejecución rápida de la siguiente manera: la segunda actividad puede empezar a ser ejecutada cuando la actividad anterior esté al 66% completada. Este sería el porcentaje más conservador y de menor riesgo involucrado para poder aplicar la ejecución rápida. Sin embargo, cada proyecto tiene su naturaleza y características propias que pueden exigir un porcentaje de trabajo realizado más alto.

A10

B10

C10

D5

E5

Actividad

Duración

127

C6

Este tipo de técnica es muy utilizada en determinadas circunstancias en que el plazo final no pue-de ser, en ninguna hipótesis, postergado. En la década de los 90, muchas empresas de software tuvieron que afrontar el problema del año 2000, más conocido como el “efecto 2000” o “Y2K”. Sus aplicaciones informáticas corrían el riesgo de parar de funcionar si no se implantaban las correcciones necesarias antes de que terminara el año 1999. Bancos, empresas de telefonía y otras compañías de grande porte invirtieron millones de dólares para evitar que ocurriese una “catástrofe informática”, que felizmente no ha llegado a ocurrir. Los proyectos de desarrollo de aplicaciones informáticas que pretendían subsanar el “Y2K” tenían que tenerlo todo listo antes de que empezara el año 2000 y, para ello, el método de la compresión tuvo que ser puesto en marcha para lograr este objetivo. En la preparación de grandes eventos deportivos, como los juegos olímpicos o los mundiales de futbol, la técnica de la compresión es ampliamente utilizada.

Desventajas de la compresión:

– Aumento de costes del proyecto: La compresión demanda más gente trabajando en una acti-vidad, lo que conlleva a un incremento en los costes de mano de obra.

– Aumento de los riesgos: La compresión conlleva a la gestión de una ejecución acelerada de trabajo, con más recursos añadidos en un plazo de tiempo reducido.

– Cualificación del equipo: Cuando es necesario incluir más recursos de última hora, normalmen-te estos recursos disponibles no son los mejores cualificados. En algunos casos, será necesario darles algún tipo de formación.

– Calidad: Tener que reducir la duración de la ejecución de una tarea, añadiéndole más traba-jadores, que, además, podrán contar con la cualificación necesaria, provocará problemas de integración y comunicación entre el grupo, lo que podría comprometer la calidad de ejecución de la tarea.

6.5.1.8. Gráfico de barras de Gantt (Gantt chart)

El gráfico de Gantt fue concebido por el ingeniero estadounidense Henry L. Gantt durante la primera guerra mundial. En aquel entonces, Gantt buscaba resolver el problema de la programación de ac-tividades, es decir, su distribución conforme un calendario, de manera que fuese posible visualizar de manera sencilla el periodo de duración de cada actividad, sus fechas de inicio y fin, y también el tiempo total requerido para la ejecución del trabajo.

Este gráfico consiste en un sistema de coordinadas en que se indica un eje horizontal que repre-sentará una escala de tiempo definido en términos de unidad más adecuada al trabajo que se va a ejecutar: hora, día, semana o meses, y un eje vertical que constituye las actividades del proyec-to. Ha sido desarrollado para presentar la información acerca del estado de un proyecto, de una forma fácil de comprensión, sobre todo a la hora de realizar comparaciones de datos estimados por datos realizados.

A cada actividad se hace corresponder una línea horizontal cuya longitud es proporcional a su dura-ción en la cual la medición efectúa con relación a la escala definida en el eje horizontal conforme se ilustra en la figura 63.

128


Figura 63: Gráfico de barras de Gantt

Características gráficas:

– Cada actividad es representada mediante un bloque rectangular cuya longitud indica su duración. La altura carece de significado.

– La posición de cada bloque en el diagrama indica las fechas de inicio y finalización de cada acti-vidad de acuerdo con la escala de tiempo asignada.

La figura 64 representa una variación del gráfico de Gantt. La diferencia básica es el uso de triángulos en lugar de barras. En este tipo de Gantt, los triángulos con la punta hacia arriba representan la fecha de inicio de cada actividad y los triángulos con la punta hacia abajo, la fecha de conclusión de la tarea. Las fechas planificadas corresponden a los triángulos blancos y las fechas reales a los triángulos grises.

Figura 64: Variación del gráfico de barras de Gantt

Actividad A

Actividad B

Actividad C

Actividad D

Actividad E

Actividad F

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Hoy PlanificadoReal

A

B

C

D

E

F

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

HoyPlanificado

Real

129

C6

Comparando la figura 63 con la 64 se podrá apreciar que ambos gráficos presentan la misma informa-ción. La tarea B, por ejemplo, ha empezado más tarde y su duración será mucho más larga que lo pla-nificado. Lo mismo pasa con la tarea D. Las tareas E y F, de momento, siguen lo establecido por el plan.

Método constructivo

Para construir un diagrama de Gantt se han de seguir los siguientes pasos:

– Dibujar los ejes horizontal y vertical.

– Escribir los nombres de las tareas sobre el eje vertical.

– En primer lugar, se dibujan los bloques correspondientes a las tareas que no tienen predeceso-ras. Se sitúan de manera que el lado izquierdo de los bloques coincida con el instante cero del proyecto (su inicio).

– A continuación, se dibujan los bloques correspondientes a las tareas que sólo dependen de las tareas ya introducidas en el diagrama. Se repite este punto hasta haber dibujado todas las tareas. En este proceso se han de tener en cuenta las siguientes consideraciones:

Las dependencias fin-inicio (finish-to-start) se representan alineando el final del bloque de la tarea predecesora con el inicio del bloque de la tarea dependiente.

Figura 65: Relación finish-to-start

Las dependencias final-final (finish-to-finish) se representan alineando los finales de los bloques de las tareas predecesora y dependiente.

Figura 66: Relación finish-to-finish

Las dependencias inicio-inicio (start-to-start) se representan alineando los inicios de los bloques de las tareas predecesora y dependiente.

Figura 67: Relación start-to-start

A

B

B

A

B

A

130


La relación start-to-finish es la menos utilizada en un proyecto. La actividad predecesora debe empe-zar antes que finalice la actividad sucesora.

Figura 68: Relación start-to-finish

Cálculos

El diagrama de Gantt es un diagrama representativo que permite visualizar fácilmente la distribución temporal del proyecto, pero es poco adecuado para la realización de cálculos. Por la forma en que se construye, muestra directamente los inicios y finales mínimos de cada tarea.

6.5.1.9. Grafico de hitos (Milestones)

Un hito es un punto del cronograma normalmente señalizando un evento importante del proyecto, como la conclusión de una determinada fase o la entrega de un módulo importante del proyecto. Los hitos no son actividades, es decir, no consumen tiempo, ni recursos, ni duraciones. Son tan solo un punto de referencia del proyecto.

Figura 69: Gráfico de hitos

* Nota del autor: Ventajas y desventajas de los gráficos de Gantt

Los gráficos de barras de Gantt se revelan muy eficaces en las etapas iniciales de planificación. No obstante, después de inicia-da la ejecución de la actividad y cuando comienzan a efectuarse modificaciones, el gráfico tiende a volverse confuso. Cuando esto ocurre, normalmente se requiere la confección de un nuevo gráfico. Aún en términos de planificación, existe una limitación bastante grande en lo que se refiere a la representación de planes de cierta complejidad. En resumen, para la planificación de actividades relativamente simples, el gráfico de Gantt representa un instrumento de bajo coste y de extrema simplicidad en su utilización. Para proyectos complejos, sus limitaciones son bastantes serias, y fueron estas las que llevaron a ensayos que die-ron como resultado el desarrollo del CPM, del PERT (véase también sección 6.4.1.4) y otras técnicas conexas.

De todas formas, el gráfico de barras de Gantt es ampliamente utilizado por las organizaciones y se ha hecho muy popular por la simplicidad de su confección y su uso. Es fácil de hacer y de entender y, actualmente, está incorporado en los programas de pla-nificación más utilizados del mercado. Su simplicidad es tan evidente, que incluso ni siquiera hace falta un ordenador o un soft-ware específico para confeccionarlo. Un papel, un lápiz y una regla son suficientes para poder sacar partido de esta herramienta.

B

A

Entrega del Diseño Módulo I

03

agosto septiembre octubre noviembre diciembre12 18 2822 01 05 14 3022 03 08 17 2927 07 11 15 2725 03 04 12 2220

Instalación Módulo I

Conversión de Datos

Entrega del Diseño Modulo II

Instalación Módulo II

Conversión de Datos

Pruebas de Instalación

Aceptación del Cliente

HITOS DEL PROYECTO

131

C6

6.6. Control del cronograma (proceso que corresponde a la fase de control del proyecto)

El control del cronograma es el proceso que realiza el seguimiento del estado actual del proyecto, el control de su avance y la gestión de los cambios realizados en su línea base. Los objetivos de este proceso son los siguientes:

– Determinar el estado actual del cronograma del proyecto.

– Influir en los factores que generan cambios en el cronograma.

– Determinar que el cronograma del proyecto ha cambiado.

– Gestionar los cambios reales conforme suceden.


6.6.1.1. Medición del rendimiento (Earned value management)


6.6.1.2. Índice de desempeño del cronograma (Schedule performance index – SPI)

El índice de desempeño del cronograma es la medida del avance logrado en un proyecto en compa-ración con el avance planificado. Básicamente, esta herramienta utiliza fórmulas matemáticas para de-terminar el grado de cumplimiento del cronograma establecido en la fase de planificación del proyecto.

La fórmula utilizada para la obtención del SPI es la siguiente:

SPI = BCWP/BCWS

Los resultados obtenidos traducen las siguientes situaciones:

– SPI=1: El proyecto está en el plazo previsto.

– SPI>1: El proyecto está adelantado.

– SPI<1: El proyecto está retrasado.

El BCWS (budgeted cost of work scheduled), es el “coste presupuestado del trabajo planificado” o valor planificado (PV). Significa el coste presupuestado de las tareas que se habían planificado terminar en esa unidad de tiempo. “¿Cuánto trabajo debería estar terminado?”.

El BCWP (budgeted cost of work reformed) es el “coste presupuestado del trabajo realizado” o valor ganado (EV). Significa el coste presupuestado de las tareas que realmente se han avanzado o termi-nado para cada periodo. “¿Cuánto trabajo está realmente terminado?”.

Aunque el SPI puede ser utilizado de forma independiente, sus resultados aportan una información bastante más robusta cuando son agrupados a otras variables que forman parte de la EVM (earned value management), considerada como la herramienta de valoración de avance del proyecto más poderosa que existe en el ámbito del Project Management. La EVM es descrita en profundidad en la sección 7.3.1.1.

132


6.6.1.3. Software de gestión de proyectos (Project management software)


6.6.1.4. Nivelación de recursos (Resource leveling)


6.6.1.5. Análisis “¿Qué pasa si…?” (What–if scenario analysis)




6.6.1.7. Compresión del cronograma (Schedule compression)


6.6.1.8. Sistema de control de cambios del cronograma (Schedule control change system)


6.6.1.9. Planificación adicional (Additional plan)


C7Dirección de costes

134


7.1. Estimación de costes (proceso que corresponde a la fase de planificación del proyecto)7.1.1. Técnicas y herramientas

7.2. Establecimiento del presupuesto (proceso que corresponde a la fase de planificación del pro-yecto)7.2.1. Técnicas y herramientas

7.3. Control de costes (proceso que corresponde a la fase de control del proyecto)7.3.1. Técnicas y herramientas

135

Algunas cosas en las que NO puedes pensar acerca de la dirección de costes

“Empezamos sin el presupuesto finalizado, luego nos adaptamos a lo que aprueben”

Los proyectos se desarrollan en varios ámbitos, uno de ellos es el económico. Lamentablemente, y sobre todo en tiempos de crisis, puede volverse un área inestable donde suele predominar la incertidumbre, y por ello necesita de una dedicación especial. El presupuesto es, por lo tanto, una herramienta de planificación y control de los costes asignados al proyecto. Los cambios bruscos en el ambiente, las variantes en las disposiciones legales o los acontecimientos mercantiles inesperados pueden cambiar el proceso.

“Podemos consumir más dinero en esta actividad, porque sé que hay unas actividades donde sobra la pasta”

La estimación de costes es una actividad fundamental en la dirección de costes. Se debe llevar a cabo con el mayor detalle posible, puesto que cualquier equivocación podría infraccionar el coste total del proyecto, lo que derivaría en el rechazo de su aceptación de desarrollo. De lo contrario, si falta dinero en el proyecto, su finalización no sería viable. Cuando “sobra la pasta” en alguna actividad, la estimación ha sido realizada de forma equivocada. Una actividad puede, como mucho, contar con una reserva financiera para emergencias.

“El cliente es de confianza, estoy seguro de que nos pagará en el plazo que establecimos con él en la cena de la semana pasada”

Con los tiempos que corren, se vuelve muy arriesgado poner en marcha cualquier acción que de-penda de posteriores pagos por parte de un cliente y/o proveedor sin ningún compromiso escrito. Cuando en una determinada actividad del proyecto no cabe el establecimiento de un contrato, se suele utilizar una “carta de compromiso”, que es un documento que se redacta para hacer constar un compromiso verbal, ya fuese un compromiso de pago de una deuda o cualquier otro tipo de compro-miso previamente establecido informalmente.

Introducción

La dirección de costes existe en cualquier organización de cualquier sector, aunque se trate de una or-ganización sin ánimo de lucro, o incluso en nuestro propio hogar. Si no se hace una gestión adecuada de costes, cualquier entidad, profesional o familiar, se iría a la quiebra en poco tiempo.

136


En muchos proyectos se asocia la dirección de costes a actividades aburridas que deberían estar exclusivamente asignadas al departamento financiero de la empresa. Esta gestión no se restringe solamente al seguimiento y control del presupuesto asignado al proyecto, sino que es fundamental para realizar un análisis financiero que permita tomar decisiones correctivas antes de que el proyecto empiece a generar costes superiores a los previstos. Este tipo de control forma parte de una de las responsabilidades fundamentales del Project Manager.

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección de costes de un proyecto incluye los procesos y actividades necesarias para estimar, presupuestar y controlar los costes de modo que se complete el proyecto dentro del presupuesto. Estos son:

– Estimar los costes.

– Determinar el presupuesto.

– Controlar los costes.

Factores que determinan la importancia de la dirección de costes:

– La dirección de costes permite conocer el progreso real del trabajo realizado.

– Mide fielmente el desempeño del equipo.

– Permite auditar el progreso general del proyecto.

– Permite comparar el coste realizado con el coste previsto y, por consiguiente, tomar las decisio-nes correctivas oportunas.

– Proporciona referencias comparativas de precio, que después servirán para realizar compras por mejores ofertas.

– Servirá como una importante base de consulta para presupuestar futuros proyectos similares.

Tipo de costes

Estimar costes es especialmente difícil por la variedad de tipos que pueden afectar al proyecto y que no pueden ser olvidados.

El coste directo es un gasto que está específicamente vinculado al proyecto. Las categorías presen-tadas a continuación son las más frecuentes:

– Trabajo/mano de obra: Normalmente se calcula multiplicando el número de horas de trabajo por el coste por hora del recurso asignado. Suele ser el coste más alto del proyecto y puede incluir, además de los sueldos, los costes de admisión, costes contractuales, seguridad social, seguros, entre otros elementos.

– Material y suministros: Incluyen los artículos comprados para ser consumidos durante la ejecu-ción del proyecto.

– Facilidades: Son incluidos si son utilizados solamente para el proyecto. Puede ser el alquiler de maquinaria o de una nave.

– Formación: Es el gasto requerido para formar el equipo del proyecto. En algunas ocasiones po-drá incluir la formación del cliente.

– Viajes, dietas y costes diversos: Igual que las facilidades, son incluidas solamente si están vin-culadas directamente al proyecto.

137

C7

El coste indirecto es un gasto que está relacionado con el mantenimiento de las instalaciones, los servicios generales y la organización como un todo. Estos costes pueden incluir:

– Beneficios complementarios: Son los costes asociados a los trabajadores, excluyendo el suel-do, como seguridad social, transporte, seguros u otros.

– Facilidades: Son los costes requeridos para el entorno del proyecto. Pueden incluir alquiler, man-tenimiento de la oficina, suministro de papelería, luz, agua...

– Administrativo: Son los costes referentes a las nóminas del personal de apoyo: administrativo, contabilidad, marketing, compras, etcétera.

– Coste de oportunidad: También conocido como “coste alternativo”, designa el coste de la in-versión de los recursos disponibles en una oportunidad económica, a costa de las inversiones alternativas disponibles, o también el valor de la mejor opción no realizada. El término fue acuñado por Friedrich von Wieser en su obra Theorie der Gesellschaftlichen Wirtschaft (Teoría de la Eco-nomía Social).

– Costes irrecuperables (sunk costs): Este tipo de coste incluye la cantidad de dinero que ha sido invertida antes del proyecto empezar. Este tipo de costes no son controlados por el Project Ma-nager y no entran en ningún presupuesto del proyecto. Son costes a fondo perdido en que no se espera que sean recuperados y no afectan a los resultados financieros del proyecto.

7.1. Estimación de costes (proceso que corresponde a la fase de planificación del proyecto)

La estimación de costes implica en la realización de predicciones sobre la cantidad más probable de esfuerzo, tiempo y niveles de personal necesarios para el desarrollo de un proyecto. Estas estimacio-nes son importantes sobre todo para determinar la viabilidad de un determinado proyecto.

Una estimación de costes bien realizada es fundamental, puesto que servirá como referencia para me-dir cuánto el presupuesto estimado está siendo consumido en función de los costes reales. Buenas estimaciones servirán también como base histórica para futuros proyectos similares.

Si acaso, se observa que la curva de costes reales se va alejando de la curva presupuestada, el Project Manager podrá poner en marcha las acciones correctivas adecuadas, que básicamente son tres:

– Si la variación del valor estimado real es cero o la diferencia es muy marginal, el plan podrá seguir avanzando tal cual ha sido planificado.

– Si la variación es poco significativa, y puede recomponer cualquier perdida, el proyecto sigue, pero haciendo uso de sus reservas financieras.

– Si la variación es muy importante, deberán hacerse nuevas estimaciones más adecuadas, o en el peor de los casos, evaluar si el proyecto sigue siendo económicamente viable.




138


7.1.1.2. Estimación por analogía (Analogous estimating or top down estimates)


7.1.1.3. Estimación ascendente (Bottom–up estimating)


7.1.1.4. Estimación paramétrica (Parametric estimating)


7.1.1.5. Técnica de evaluación y revisión de programas (Program evaluation and review technique – PERT)


7.1.1.6. Análisis de reserva (Reserve analysis)

El análisis de reserva es una de técnica utilizada para el desarrollo de presupuestos y se aplica ge-neralmente en proyectos que contienen un cierto grado de incertidumbre, y por ello puede contener algún riesgo. Por ejemplo, se puede incluir una reserva de contingencia por la falta de conocimiento de los técnicos del proyecto acerca de una determinada tecnología. Este desconocimiento puede provocar retrasos en la entrega del producto.

A medida que se dispone de información más precisa sobre el proyecto, esta reserva puede reducirse o incluso eliminarse. Las reservas de contingencia funcionan por lo tanto, como un colchón de segu-ridad para los casos en que la actividad consuma más recursos de lo planificado.

Todo proyecto debería contar con alguna reserva, independientemente del su grado de incertidum-bre. Cualquier proyecto, incluso los más recurrentes, siempre estarán expuestos a alguna clase de riesgo, por lo tanto, el análisis reserva es una herramienta indispensable en el proceso de estimación de costes.

7.1.1.7. Software de estimación para la gestión de proyectos (Project management estimating software)


7.1.1.8. Análisis de propuestas para licitaciones (Vendor bid analysis)



Descrita en la sección 5.3.

139

C7

7.1.1.10. Estructura de desglose de costes – EDC (Cost breakdown structure – CBS)

En general, los costes de un proyecto se clasifican en categorías, de acuerdo con la organización establecida por la empresa. Estas categorías son los elementos que componen la estructura de des-glose de costes – EDC, cuyo desarrollo veremos a continuación. Acorde con Wolter J. Fabrycky en su obra Análisis del Coste del Ciclo de Vida de los Sistemas, las principales categorías de costes son las siguientes (tomando como ejemplo una empresa de desarrollo de software):

– Costes de investigación y desarrollo: Planificación inicial, análisis de mercado, investigación del producto, análisis de requisitos, diseño de ingeniería, datos y documentación de diseño, software, pruebas y evaluación de los modelos de ingeniería, y funciones de gestión asociadas.

– Costes de producción y construcción: Ingeniería industrial y análisis de operaciones, producción (fabricación, montaje y pruebas), construcción de instalaciones, desarrollo del proceso, operacio-nes de producción, control de calidad y requisitos iniciales de apoyo a la logística (por ejemplo, apoyo inicial al cliente, producción de repuestos, producción de equipo de pruebas y apoyo...).

– Costes de operación y apoyo: Operaciones del sistema o producto por parte del consumidor o usuario, distribución del producto (marketing y ventas, transporte y gestión de tránsito), y man-tenimiento y apoyo logístico durante el ciclo de vida del sistema o producto (por ejemplo, servicio al cliente, actividades de mantenimiento, apoyo de abastecimiento, equipos de prueba y apoyo, transporte y manejo, datos técnicos, instalaciones, modificaciones del sistema, entre otras.).

– Costes de retirada y eliminación: Eliminación de elementos no reparables a lo largo del ciclo de vida, retirada del sistema o producto, reciclaje de material y requisitos aplicables del apoyo logís-tico. La estructura de desglose del coste relaciona los objetivos y actividades con los requisitos de recursos de organización. Constituye una subdivisión lógica del coste por área de actividad funcional, elementos importantes del sistema, y/o una o más de las clases discretas de elemen-tos comunes o semejantes.

Figura 70: Estructura de desglose de costes

El desarrollo de una correcta EDC ayudará el Project Manager a identificar todos los elementos de costes relevantes, además de proporcionar un medio para la asignación inicial de recursos, la vigilan-cia del coste y el control del coste.

Sea cual sea su complejidad, una EDC debe tener las siguientes características básicas:

– Deberán incluir todos los costes relevantes, incluidos los gastos internos.

– Cada coste debe estar bien definido a fin de que todos los participantes tengan una clara com-prensión de lo que se va a incluir en dicho coste.

COSTE TOTAL DELSISTEMA / PRODUCTO

Coste de investigacióny desarollo

Coste de producción yconstrucción

Coste de operación ymantenimiento

Coste de retidada yeliminación

Gestión del productoPlanificación del productoInvestigación del productoPruebas y evaluación

Gestión de producciónFabricaciónProducciónControl de Calidad

Distribución del productoDatos técnicosModificaciones

Eliminación de elementosRetirada del SistemaDocumentación

140


– Cada coste debe ser identificable con un importante nivel de información.

– El desglose de costes debe ser estructurado de tal manera que permitan el análisis de áreas específicas.

– El EDC debe ser compatible con los procedimientos contables utilizados por la empresa en su gestión financiera.

7.1.1.11. Tasas de recursos (Resources rates)

Aplicando el concepto de tasas de recursos al proceso de estimación de costes es posible determinar el coste total de los recursos del proyecto.

Vamos suponer que el proyecto necesite de cuatro programadores, dos técnicos de hardware y un Project Manager. Las tasas para cada uno de los integrantes de este pequeño equipo son:

– Programador: 80 euros/hora.

– Técnico de hardware: 90 euros/hora.

– Project Manager: 100 Euros/hora

El proyecto necesitará de cien horas de trabajo de los programadores, cincuenta horas de los técnicos de hardware y ciento cincuenta horas de trabajo del Project Manager. Estos datos nos llevan a los siguientes costes:

Programador:

80 euros/hora * 100 horas de trabajo * 4 programadores = 32.000 euros

Técnico de hardware:

90 euros/hora * 50 horas de trabajo * 2 técnicos = 9.000 euros

Project Manager:

100 euros/hora * 150 horas de trabajo * 1 Project Manager = 15.000 Euros

Los costes de los recursos tendrán entonces un coste total de:

32.000 + 9.000 + 15.000 = 56.000 euros.

7.1.1.12. Técnica delphi (Delphi technique)


7.1.1.13. Base histórica de proyectos (Historical Records)


7.1.1.14. Plan de cuentas (Chart of accounts)

Es un sistema numérico financiero utilizado para identificar cada elemento de la estructura detallada de trabajo – EDT y para monitorizar los costes del proyecto por categoría. El plan de cuentas es confec-cionado de acuerdo con el plan de cuentas “maestro” desarrollado por la organización y que contiene las principales actividades de todos los proyectos realizados por la empresa, de forma general.

141

C7

7.2. Establecimiento del presupuesto (proceso que corresponde a la fase de planificación del proyecto)

Este proceso consiste en sumar los costes estimados de todas las actividades individuales del proyecto para establecer la línea base de costes del proyecto, que incluirá todos los prepuestos revisados y aprobados, volviéndose, entonces, en el fondo financiero autorizado para el desarrollo del proyecto.


7.2.1.1. Suma de costes (Cost aggregation)

Las estimaciones de costes se suman básicamente a través de los paquetes de trabajo establecidos en la EDT del proyecto (véase también sección 5.3)





7.2.1.4. Relaciones históricas (Historical relationships)

Las relaciones históricas son resultados obtenidos a través de estimaciones análogas (véase también la sección 6.4.1.2) y/o paramétricas (véase también la sección 6.4.1.3) de proyectos similares ante-riores que podrán proporcionar modelos matemáticos que permitan preceder los costes totales de un nuevo proyecto.

7.2.1.5. Conciliación del límite del financiamiento (Funding limit reconciliation)

El gasto de fondos siempre debe estar conciliado con los límites impuestos por el presupuesto o fi-nanciamiento del proyecto. Una variación entre estos límites y los gastos planificados podrán requerir una revisión del trabajo para regular dichos gastos.

7.3. Control de costes (proceso que corresponde a la fase de control del proyecto)

El cliente o el patrocinador que invierten una determinada cantidad de dinero en un proyecto esperan que los trabajos previstos consuman solamente el presupuesto establecido. Se pueden aceptar varia-ciones, puesto que es conocido que existen muchas posibilidades de que el proyecto sufra cambios en su alcance a lo largo de su ciclo de vida. Además, siempre pueden surgir eventos no esperados. El cliente puede aceptar variaciones financieras razonables, pero no aceptará variaciones financieras derivadas de una pérdida de control por parte de la empresa ejecutora del proyecto. Si la cantidad invertida sobrepasa en mucho el presupuesto original, en muchos casos el proyecto pierde su viabili-dad, y finalmente podrá ser cancelado.

142


El control de costes básicamente implica supervisar la evolución de costes para detectar cualquier variación con respecto al plan inicial y, con ello, poder efectuar acciones correctivas y/o preventivas para mantener los costes dentro de límites aceptables. La preocupación del Project Manager en esta gestión no serán propiamente las variaciones, pero sí la dimensión de estas variaciones y sus impac-tos que pueden llevar el proyecto a un estado muy crítico. La figura 71 ilustra la situación actual de un proyecto respecto a sus costes.

Figura 71: Evolución de los costes de un proyecto (planificado x realizado)

El seguimiento y control de costes de un proyecto puede ser realizado sencillamente, tal y como ilustra la figura 72, a continuación, donde se listan las actividades del proyecto. Se añaden el coste estimado (línea base), los costes realizados y los costes estimados para el futuro. El resultado es la variación de cada tarea, y la variación total, que en ejemplo, es negativo.

TareaCoste

estimado

Consumido hasta el

momento

Coste para conclusión

Estimación revisada

Variación

A 10.000 5.200 5.000 10.200 -200

B 1.200 400 800 1.200 0

C 300 25 200 225 75

D 15.340 12.450 3.000 15.450 -110

E 860 1.020 2.000 3.020 -2.160

F 3.570 2.120 720 2.840 730

G 2.000 640 1.840 2.480 -480

Total 33.270 21.855 13.560 35.415 -2.145

Figura 72: Tabla de variaciones

Gasto Atual

Gasto Estimado

20 €

40 €

60 €

80 €

143

C7

A pesar de poder proveer la situación financiera real de un proyecto, este dato aislado no representa mucho si no está integrado con la evaluación del cronograma del proyecto. De la misma manera, tampoco será de gran utilidad saber la cantidad de trabajo realizado sin considerar los costes adju-dicados. La figura 72 indica que el proyecto consumirá 2.145 euros más de lo previsto. Quizás sea una variación aceptable. Sin embargo, estas cifras no nos dicen la cantidad de trabajo realizado ni tampoco el trabajo que queda por realizar, con lo que saber que la organización gastará 2.145 euros aparte es una información aislada que poco podrá aportar a los interesados en el proyecto.

Para disponer de una estimación más realista, es necesario utilizar una herramienta que integre el coste y el cronograma. Esta herramienta se llama valor del trabajo realizado (EV – earned value) y será explicada en detalles a continuación, en la sección 7.3.1.1).


7.3.1.1. Valor del trabajo realizado (EV: earned value)

Como hemos podido comprobar, el Project Manager tiene que asumir una serie de responsabilidades para asegurar que el proyecto avance sin incidencias. Una de ellas, que posiblemente es la que mejor justifica la intervención de un Project Manager, es el seguimiento del proyecto.

El seguimiento del proyecto no se resumen solamente a “echar un ojo”, pues debe incluir informes de estados, mediciones de avance, previsiones y tendencias. La información sobre el rendimiento del trabajo debería incluir además, la medida en que se está cumpliendo con los estándares de calidad, los costes incurridos o comprometidos, los plazos asumidos, entre otros asuntos.

Adicionalmente, es apropiado realizar revisiones internas de una forma regular, así como organizar revisiones periódicas con todas las partes participantes en el proyecto.

El análisis del valor ganado (earned value management - EVM) es actualmente el método más utiliza-do para la medición de desempeño de un proyecto por su facilidad en generar informes de estado de costes y plazo de forma integrada. Es, además, una forma eficaz de comunicar a los interesados del proyecto es estado del presupuesto y desempeño en el tiempo.

Este análisis, por lo tanto, realiza la medición del estado del proyecto básicamente por medio de la respuesta de tres preguntas.

– “¿Qué tanto trabajo se planificó?”. La respuesta corresponde al valor planificado (planned value - PV): Que representa el presupuesto definido y aprobado para realizar un determinado trabajo.

– “¿Qué tanto trabajo actualmente se ha completado?”. La respuesta corresponde al valor ga-nado (earned value - EV): Que representa el presupuesto definido y aprobado para realizar un determinado trabajo. La suma de los costes previstos para las actividades finalizadas durante un periodo dado.

– “¿Qué tanto ha costado completar el trabajo actual?”. La respuesta corresponde al coste real (actual cost - AC): Que representa el valor financiero efectivamente consumido en la realización de un determinado trabajo durante un periodo específico de tiempo.

Caso práctico

Un proyecto ha sido planificado para ser ejecutado en cuatro semanas por un presupuesto de 100.000 euros. A la tercera semana de ejecución, nos han informado de que se ha completado solamente el 50% del trabajo, cuando se debería haber realizado el 75%, acorde con el cronograma establecido.

144


Nos informan además que el coste actual asciende a la cifra de 90.000 euros. ¿Cuál será el estado del proyecto en este momento?

Figura 73: Análisis del valor ganado

Por lo tanto, el valor planificado (PV) para este proyecto para el día de hoy debería ser la realización del 75% del trabajo planificado, por un coste de 75.000 Euros. El valor planificado (PV) se calcula multipli-cando el porcentaje planificado por el presupuesto del proyecto, es decir:

PV = Porcentaje planificado (%) * el presupuesto del proyecto = 75% x 100,000 = 75,000

Por otro lado, el valor ganado (EV) se calcula multiplicando el porcentaje actual completado por el presupuesto del proyecto, es decir:

EV = Porcentaje ejecutado (%) * el presupuesto del proyecto = 50% * 100,000 = 50,000

El coste actual (actual cost) para lograr el 50% del proyecto es de 90.000 euros. El coste actual (ac-tual cost) se calcula rastreando el coste contra el presupuesto del proyecto:

AC = 90.000 euros

A través de estos cálculos, podemos determinar las variaciones de coste y cronograma del proyecto.

La variación de coste (cost variance – CV): representa la diferencia entre el valor ganado (earned value – EV) y el coste real del proyecto (actual cost – AC).

La variación de coste es encontrada utilizando la siguiente formula: CV = EV - AC.

Si el resultado es mayor que cero (valor positivo), entonces tenemos una variación de coste favo-rable. Si el valor es menor que cero (valor negativo), podemos determinar que la variación de coste no es favorable. Una de las formas más sensatas de mantener una variación de coste favorable, es controlando disciplinalmente los costes del proyecto, además de controlar también el cronograma del proyecto, ya que cada hora trabajada tiene un coste vinculado.

Variaciones de cronograma (schedule variance – SV): Es la diferencia entre lo que se ha previsto consumir en un determinado plazo y lo que efectivamente se ha consumido, que podrá definir si el proyecto está dentro o fuera del plazo.

Tiempo

AC

EV

PV

90.000

75.000

50.000 } }SVCV

100.000Coste

145

C7

Su valor se puede obtener a partir de la siguiente formula: SV = EV – PV

Aplicando las fórmulas de variaciones en nuestro ejemplo, encontramos los siguientes resultados:

Variación del coste para este proyecto:

CV= 50.000 – 9000 = - 40.000 euros

Variación del cronograma para este proyecto:

SV = 50.000 – 75.000 = -25.000 euros

Al realizar estos cálculos, el Project Manager podrá determinar que el proyecto ha consumido el 90% de su presupuesto para completar solo el 50% del trabajo planificado. En otras palabras, este pro-yecto se encuentra retrasado en el cronograma y seguramente terminará por encima del presupuesto establecido. Será necesario ampliar el cronograma del proyecto y/o obtener fondos adicionales para completar el proyecto.

Con todos estos datos, el Project Manager puede todavía determinar dos índices muy utilizados en Project Management, para la evaluación de desempeño de proyectos:

Índice de desempeño del coste (cost performance index - CPI): Véase también sección 7.3.1.4. Es una medida del valor ganado de un proyecto comparada a los costes reales incurridos. Los resultados obtenidos traducen las siguientes situaciones:

– CPI=1: El proyecto está gastando lo previsto.

– CPI>1: El proyecto está gastando menos de lo previsto.

– CPI<1: El proyecto está gastando más de lo previsto.

Índice de desempeño del cronograma (schedule performance index – SPI): Véase también sec-ción 6.6.1.2. Es una medida de progreso real del cronograma del proyecto. Los resultados obtenidos traducen las siguientes situaciones:

– SPI=1: El proyecto está en el plazo previsto.

– SPI>1: El proyecto está adelantado.

– SPI<1: El proyecto está retrasado.

Las fórmulas utilizadas para obtener los índices de coste y cronograma son las siguientes, respectivamente:

CPI = EV / AC

SPI = EV / PV

Si cogemos los números reales de nuestro ejemplo, obtendremos los siguientes índices:

Índice de desempeño de coste:

CPI = EV / AC

50.000 / 90.000 = 0.56

CPI = 0.56

Índice de desempeño del cronograma:

50.000 / 75.000 = 0.67

SPI = 0.67

146


Tal y como podemos apreciar, ambos índices son menores de uno, por lo tanto el proyecto necesita ser revisado. Si el proyecto sigue con esta tendencia, será necesario gastar 180.000 euros para com-pletar el proyecto, cuando su presupuesto planificado era de 100.000 euros.

Esta previsión de gasto de 180.000 euros se obtiene a través de otra variable llamada “estimación a la terminación” (EAC – estimate at complete), que calcula el total de los probables gastos al termino del proyecto, basado en los valores consumidos hasta el momento actual. Esta estimación es muy sencilla de ser realizada porque asume que los gastos que serán consumidos hasta la conclusión del proyecto serán los mismos consumidos hasta ahora. Claro, que las circunstancias futuras serán distintas a las ocurridas en el pasado. De todas formas, el EAC puede ser modificado de acuerdo con la evolución y los gastos del proyecto, para que su estimación sea actualizada y real. Más detalles en la sección a continuación (7.3.1.2 – Proyecciones).

El EAC es reflejado de forma gráfica, de la forma como ilustra la figura 74, que se muestra a continuación:

Figura 74: EAC

Para calcular la estimación a la terminación (EAC), se divide el presupuesto original por el índice de desempeño del coste (esta es la fórmula más básica, aunque hay otras formas de determinarlo).

EAC = BAC/CPI = 100.000 / 0.56

EAC = 180.000

Con toda esta información disponible, ya podremos contestar a una serie de preguntas acerca del estado general del proyecto:

¿Estamos por debajo o por encima del presupuesto proyecto?

CV: cost variance (desviación de coste) = EV - AC

50.000 – 9000 = - 40.000 euros

Respuesta: El valor ganado ha sido menor que el coste planeado. El presupuesto real del proyecto está excedido.

*Nota del autor: Los valores negativos o positivos de coste y plazos indican que el proyecto no se desarrolla exactamente como determina el plan. Una vez determinadas las variaciones existentes, es hora de identificar los factores que están causando estas variaciones y poner en marcha las medidas correctivas adecuadas. Para ello, es muy indicado utilizar una herramienta de causa-efecto, como es diagrama de ishikawa (Para más detalles, véase también el punto 8.3.1.7).

EV

AC

EAC

Fase Actualdel Proyecto

147

C7

¿Cómo de eficientemente estamos usando los recursos financieros del proyecto?

CPI: cost performance index (índice de desempeño de coste) = EV / AC

50.000 / 90.000 = 0.56

Respuesta: El nivel de eficiencia en el uso de los recursos financieros no es bueno. Por cada euro invertido en el proyecto este genera en términos de valor solamente 0,56 euros.

¿Cuál es el coste más probable del proyecto?

EAC: estimate at completion (coste estimado de terminación) = BAC / CPI

100.000 / 0.56 = 180.000

Respuesta: Indica que si la tendencia se mantiene a este ritmo de desfase, al finalizar las actividades del proyecto, este costará 180.000 euros.

7.3.1.2. Proyecciones (Forecasting)

Conforme el proyecto avanza, el Project Manager irá disponiendo de informaciones que le permitirán desarrollar proyecciones muy útiles para la toma de acciones preventivas y/o correctivas. Una técnica de proyección muy utilizada es la “proyección de la estimación por la conclusión” (estimate at com-pletion – EAC), que se define como: “El coste total esperado de una actividad o proyecto cuando todo el trabajo esté finalizado”, que, en algunos casos, pueden diferir de otro concepto de dirección de costes, conocido por “presupuesto hasta la conclusión” (budget at completion – BAC).

Los datos obtenidos de la EVM pueden proporcionar varias EAC, según diferentes escenarios. A con-tinuación, y acorde con el PMBOK®, se describirán tres de las más comunes:

– Proyección de la EAC basada en el trabajo correspondiente a la ETC, realizado según la pro-porción presupuestada: Este método de EAC toma en cuenta el desempeño real del proyecto a la fecha (ya sea favorable o desfavorable), como lo representan los costes reales, y prevé que el tra-bajo según la ETC se llevará a cabo de acuerdo con el ratio presupuestado. Cuando el desempeño real es desfavorable, el supuesto de que el desempeño futuro mejorará debe aceptarse únicamente cuando está sustentado por un análisis de riesgo del proyecto. Ecuación: EAC = AC + BAC - EV.

– Proyección de la EAC basada en el trabajo correspondiente a la ETC, realizado según el CPI actual: Este método supone que se espera que lo que el proyecto ha experimentado a la fecha continúe en el futuro. Se supone que el trabajo correspondiente a la ETC se realizará según el mismo índice del desempeño de coste (CPI) acumulativo en el que el proyecto ha incurrido a la fecha. Ecuación: EAC = BAC / CPI acumulativo.

– Proyección de la EAC basada en el trabajo correspondiente a la ETC, realizado conside-rando ambos factores (SPI y CPI): En esta proyección, el trabajo correspondiente a la ETC se realizará según una proporción de eficiencia que toma en cuenta tanto el índice del desempeño de costes como el índice de desempeño del cronograma. Supone un desempeño de costes negativo a la fecha y la necesidad de que el proyecto se comprometa firmemente a respetar el cronograma. Este método es tanto más útil cuanto el cronograma del proyecto es un factor que afecta el esfuerzo de la ETC. Las variaciones de este método miden el CPI y el SPI según dife-rentes valores (por ejemplo, 80/20, 50/50 o alguna otra proporción), de acuerdo con el juicio del Project Manager. Ecuación: AC + [(BAC – EV) / (CPI acumulativo x SPI acumulativo)].

Cada uno de estos métodos puede ser adecuado para cualquier proyecto dado y proporcionará al equipo de dirección del proyecto una señal de “advertencia temprana” si las proyecciones para la EAC no están dentro de las tolerancias aceptables.

148


7.3.1.3. Índice de desempeño del trabajo por completar (To–complete performance index – TCPI)

El TCPI es una proyección calculada del desempeño del coste que deberá lograrse para el trabajo restante, con el objetivo de cumplir con la meta establecida, tal como el BAC o la EAC. Según lo expli-cado en el punto anterior, cuando el BAC no se presenta viable, se proyecta entonces una EAC, que, una vez aprobada, sustituirá la BAC en vigor como meta de desempeño de costes.

La ecuación para el TCPI basada en el BAC es: (BAC - EV) / (BAC - AC)

Si el CPI acumulativo se presenta por debajo de la línea base del plan, todo el trabajo futuro tendrá que ser realizado inmediatamente en el rango de la TCPI para mantenerse dentro del BAC autorizado. Una vez que se reconozca que ya no es posible cumplir con el BAC, se preparará una nueva estimación a la conclusión (EAC), para el trabajo, y una vez aprobada, el proyecto utilizará el nuevo valor de la EAC. Este nivel de desempeño se muestra como la línea TCPI (EAC).

La ecuación para el TCPI basada en la EAC es: (BAC - EV) / (EAC - AC).

7.3.1.4. Índice del desempeño del coste (Cost performance index – CPI)

El índice del desempeño del coste (CPI) es una medida del valor del trabajo completado, en compara-ción con el coste o el avance real del proyecto. Es considerada la métrica más importante de la EVM (véase también sección 7.3.1.1) y mide la eficacia de la gestión del coste para el trabajo completado.

La fórmula utilizada para la obtención del CPI es la siguiente:

CPI = EV / AC

Los resultados obtenidos se traducen las siguientes situaciones:

– CPI = 1: El proyecto está gastando lo previsto.

– CPI > 1: El proyecto está gastando menos de lo previsto.

– CPI < 1: El proyecto está gastando más de lo previsto.

Para poner un ejemplo sobre la aplicación de la CPI, vamos suponer que un determinado trabajo tiene el valor de 750 euros (EV), pero ha costado en realidad 800 euros (AC). Esto quiere decir que cada euro consumido en este proyecto se ha pagado por un trabajo que valía 93,73 céntimos. Por lo tanto, es un proyecto ha sido presupuestado en 10.000 euros, si dividimos en CPI encontrado de .9373, tendremos como resultado el valor total de 10.669 euros de coste real, o un sobrecoste de 669 euros.

Figura 75: Los índices del EVM

BCWP (EV)

ACWP

BCWS

SPI = BCWP BCWS

CPI = BCWP ACWP

BCWP < BCWSSPI < 1

BCWP > BCWSSPI > 1

BCWP > BCWSSPI > 1

BCWP > ACWPCPI >1

BCWP > ACWPCPI > 1

BCWP > ACWPCPI > 1

149

C7

7.3.1.5. Software de gestión de proyectos (Project Management software)


7.3.1.6. Planificación adicional (Additional planning)


7.3.1.7. Sistema de control de cambios de costes (Cost change control system)


150


C8Dirección de calidad

152


8.1. Planificación de la calidad (proceso que corresponde a la fase de planificación del proyecto)8.1.1. Técnicas y herramientas

8.2. Aseguramiento de la calidad (proceso que corresponde a la fase de ejecución del proyecto)8.2.1. Técnicas y herramientas

8.3. Control de calidad (proceso que corresponde a la fase de control del proyecto)8.3.1. Técnicas y herramientas

153

Algunas cosas en las que NO puedes pensar acerca de la dirección de calidad

“Si añadimos más funciones, la calidad del producto aumentará”

Al principio, lo que suena como algo positivo podría provocar un gran dolor de cabeza. Añadir más ele-mentos a un producto y/o servicio sin que el cliente los hubiera solicitado podría incrementar sustancial-mente la probabilidad de riesgos en el proyecto, que, eventualmente, no finalizará dentro de los plazos y presupuestos establecidos. Y lo primero que el cliente dirá es que los problemas empezaron a partir del momento en que se ha decidido añadir elementos al producto. Al cliente se le debe entregar solamente lo solicitado. Añadir “extras” es una pérdida de tiempo y no aportará ningún beneficio al proyecto. Además, es importante recordar que el Project Manager debe respetar el enunciado del trabajo, que especifica exactamente los entregables del proyecto. En resumen, calidad significa “cumplir con las expectativas del cliente, asegurar que este recibirá exactamente lo solicitado, en el plazo y dentro del presupuesto”.

“Los requisitos del cliente están escritos en aquella servilleta de papel”

Los requisitos del cliente establecen detalladamente sus necesidades y expectativas, además de proporcionar la dirección por la cual el equipo tendrá que desarrollar la planificación del proyecto. Un factor clave del éxito del proyecto es la correcta documentación de estos requisitos, que deberá estar exhaustivamente detallada. Si un proyecto está basado en requisitos escritos en una servilleta, ya podemos conocer con mucha antelación que fin tendrá este proyecto.

“Todos los problemas serán priorizados como críticos”.

Este tipo de “estrategia” es muy frecuente en la ejecución de proyectos, y se puede decir, sin mediar pa-labras, que se trata de “pegar un tiro en el propio pie”. Imaginemos la siguiente situación: una casa antigua necesita cambiar el suelo de la cocina, renovar toda la pintura y cambiar todo el cableado eléctrico, cuyo mal estado contempla un alto riesgo de cortocircuito. ¿Es razonable decir que en el proyecto de reforma de esta casa se puede clasificar todo los problemas como críticos? Todos los problemas, en cualquier seguimiento, sea empresarial o personal, no pueden tener la misma prioridad. Cada uno requiere un tratamiento distinto, tendrá seguramente un coste distinto y necesita de grados diferentes de urgencia.

“Podemos entregarlo al cliente sin hacer las pruebas, estoy seguro de que todo funciona per-fectamente”

La verificación y validación de un producto es una actividad fundamental para asegurar su calidad an-tes de su puesta en funcionamiento, evitando, de esta forma, errores y costes imprevistos para corre-gir dichos errores. Las pruebas son generalmente consideradas como costosas y molestas, aunque sus beneficios se dejan notar en la empresa y, sobre todo, en la satisfacción del cliente. La empresa, por un lado, cumple con su compromiso de alcance, plazo, coste y calidad; por otro, el proyecto llega a su fase final entregando un producto considerado estable y seguro.

154


“No creo que el cliente necesite un manual”

Igual que las pruebas, algunas empresas consideran los manuales como un elemento innecesario y, muchas veces, una pérdida de tiempo. Felizmente, se ha notado que la gran mayoría de las empresas se ha dado cuenta de la importancia de los manuales, y hoy en día incluso una silla viene acompaña-da de su manual de uso y montaje. Esto se debe, sobre todo, por el nivel de exigencia del mercado consumidor y de la fuerte competencia que las empresas tienen que enfrentar, especialmente las multinacionales. Un manual es considerado como una parte integral del producto y una parte legal de la entrega, estando debidamente presente como uno de los criterios de aceptación final del proyecto.

Introducción

La calidad es algo muy subjetivo, puesto que cada persona posee grados distintos de valores y ex-pectativas. Lo que puede tener mucha calidad para una persona, puede tener poca o casi ninguna para otra. Por esta razón es fundamental entender lo que necesita el cliente (sus requisitos), en la fase inicial del proyecto, para poder asegurar que el producto y/o servicio que le será entregado atiende a sus expectativas y posee el nivel de calidad esperado.

La calidad es un concepto extremadamente amplio y difícil de explicar. La podemos definir de distintas formas:

– Grado en que el conjunto de características cumple con los requisitos establecidos.

– Conjunto de actividades que permiten satisfacer las necesidades de un individuo o de un colectivo.

– Satisfacción del cliente y conformidad con sus requisitos.

– Grado de satisfacción que produce al cliente.

Se pueden comprobar en la historia, que desde siempre el hombre ha buscado por la perfección y siempre ha tenido un especial interés por el trabajo bien hecho, inquietudes que, con el pasar de los siglos, han culminado en los estándares de calidad que conocemos actualmente.

Entre los años 2000 y 3000 a.C, los faraones egipcios construyeron pirámides que poseían paráme-tros que se acercaban casi a la perfección. El mismo nivel de calidad de ingeniería se puede apreciar en las pirámides aztecas, que atestiguan los increíbles avances en la arquitectura y la ingeniería que estos pueblos mesoamericanos lograron gracias a los métodos de inspección empleados durante su construcción.

Muchos siglos más tarde, en la edad media, surgió la figura del artesano, que acorde con la zona en donde habitaba, confeccionaba sus productos siguiendo las especificaciones establecidas por su gremio. Es por esta razón que, pasados 600 años, todavía es posible apreciar el sabor de un queso, de un pan o de un dulce exactamente como eran fabricados en aquella remota época.

Llega la revolución industrial y con ella, comienza a desaparecer la artesanía. Surgen las primeras gran-des fábricas que llevan a la población una novedad: productos industrializados, hechos en cantidades jamás imaginadas y con una característica novedosa: eran todos exactamente iguales.

Los dulces tenían todos el mismo sabor, las sillas las mismas dimensiones y las ropas el mismo diseño y características textiles. La producción masiva de productos ha logrado reducir sus costes de pro-ducción y atender a un público cada vez mayor, y con el paso del tiempo, más exigente.

Los años pasaron y finalmente surge el control de calidad moderno en las primeras décadas del siglo XX, con la aplicación industrial del cuadro de control ideado por el doctor Walter Shewhart, inventor de los conocidos gráficos de control (descritos detalladamente en la sección 8.3.1.4).

155

C8

Finalizada la II Guerra Mundial, los japoneses comienzan a dedicar una atención casi obsesiva a la calidad. Muchas empresas empiezan a trabajar con el concepto de “sistema integral de calidad”, que afecta al diseño, la fabricación y la comercialización, produciéndose un fenómeno singular que afectó a la comercialización y economía industrial de muchos países, como consecuencia del despegue de la industria japonesa, aplicando los conceptos del aseguramiento de la calidad y la prevención.

Los industriales japoneses aprendieron las enseñanzas de Deming y la calidad japonesa, la producti-vidad y su posición competitiva se mejoraron y reforzaron, para ser lo que son hoy en día. Es por ello que cada año se otorga en el Japón los muy deseados “Premios Deming” al individuo que muestre lo-gros excelentes en teoría o en la aplicación del control de la calidad por estadísticas, o aquella persona que contribuya notablemente a la difusión de las técnicas del control de calidad por estadísticas, así como a su aplicación. Las compañías japonesas que han obtenido dichos premios incluyen Nissan, Toyota, Hitachi y Nipon Steel. En 1989, la Florida Power and Light Company fue la primera compañía extranjera en ganar el “Premio Deming”.

8.1. Planificación de la calidad (proceso que corresponde a la fase de planificación del proyecto)

“Planificar la calidad” es el proceso por el cual se identifican los requisitos de calidad y/o normas para el proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento con los mismos. La planificación de la calidad debe realizarse en forma paralela a los demás procesos de planificación del proyecto. Por ejemplo, los cambios propuestos en el producto para cumplir con las normas de calidad identificadas pueden requerir ajustes en el coste o en el cronograma, así como un análisis detallado de los riesgos de impacto en los planes.

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección de calidad de un proyecto incluye los procesos y actividades de la organización ejecutante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por la cuales fue emprendido. Son ellos:

– Planificar la calidad.

– Realizar el aseguramiento de calidad.

– Realizar el control de calidad.


8.1.1.1. Análisis beneficio‑coste (Benefit‑cost analysis – BCA)

Es una herramienta utilizada para determinar si los beneficios obtenidos a través de la realización de un proyecto compensan los costes que serán generados para ponerlo en marcha. Se aplica muy frecuentemente para determinar cuál de las opciones disponibles ofrece mejor rendimiento sobre una inversión. Los beneficios pueden ser tangibles o intangibles. En el caso de los intangibles, sus bene-ficios son más difíciles de mesurar, por ejemplo, hacer una reforma en una oficina, modernizando a la vez el mobiliario y los equipos de trabajo, podrá incrementar de forma importante el nivel de satisfac-ción y motivación de los trabajadores, aumentando el nivel de producción.

156


El análisis beneficio-coste se desarrolla de la siguiente forma:

– Se lleva a cabo una tormenta de ideas (descrita en la sección 11.2.1.8). O se puede de forma más sencilla, reunir datos históricos, o incluso consultar a personas con experiencia (descrita en la sección 4.1.1.1).

– Determinar los costes relacionados con cada factor. Algunos costes, como mano de obra, podrán ser exactos, mientras otros menos conocidos, deberán ser estimados.

– Sumar los costes totales de cada decisión propuesta.

– Determinar los beneficios en Euros de cada decisión.

– Determinar la relación entre los beneficios y costes. Los beneficios tangibles se traducen en retor-no financiero y son más sencillos de cuantificar. La fórmula clásica del análisis beneficio-coste es muy sencilla y fácil de calcular:

Comparar los resultados de esta fórmula entre las diferentes propuestas. La mejor solución, en térmi-nos financieros es aquella con el mejor resultado. Para imputar los valores y realizar los cálculos, se puede utilizar una tabla como la que ampliamos a continuación:

Propuesta Costes Beneficios Beneficio coste¿Deseable?

Sí No

Figura 76: Tabla de análisis beneficio / coste

8.1.1.2. Análisis de los costes de calidad (Cost of quality analysis)

Desarrollar un sistema de calidad eficaz en un proyecto conlleva a un cierto incremento de costes. Puede que parezca más económico no establecer controles de calidad o ningún proceso de medición o monitorización del trabajo realizado. No obstante, es importante tener claro que es indiscutiblemente más cara las eventuales consecuencias provocadas por la no calidad.

*Nota del autor: Aunque sea deseable que los beneficios sean mayores que los costes, no existe una respuesta única que pueda determinar la mejor relación. Dependerá de cada caso.

Existen beneficios intangibles, como la seguridad, la motivación de los trabajadores o la tranquilidad que no pueden ser exac-tamente traducidos en beneficios financieros.

El análisis coste/beneficio por si solo puede no ser una referencia clara para tomar una determinada decisión. Existen otros pun-tos que deben ser llevados en cuenta y que pueden ser identificados a través de las herramientas presentadas en el Capítulo 3 – Selección de proyectos.

BENEFICIOCOSTE

157

C8

Básicamente, son cuatro los costes de calidad:

– Costes de prevención: El coste de corregir un defecto o problema generalmente es mayor que el coste de prevenirlo. El coste de prevención es el coste derivado de la planificación que se realiza antes de un proyecto para evitar que se comentan errores. Son acciones que buscan realizar el trabajo a la primera. Los costes de prevención generalmente involucran planes adicionales, for-mación del equipo inspecciones, pruebas y auditorías.

– Costes de evaluación: Es el resultado de las evaluaciones que se realizan en un producto ya acabado. Normalmente se realiza este proceso cuando la organización no está segura de que las acciones preventivas desarrolladas con anterioridad no hayan sido suficientes.

– Costes por fallos internos: Son aquellos en los que incurre la organización como consecuencia de errores cometidos durante el desarrollo, y que han sido detectados antes de que el producto o servicio sea entregado al cliente. También son conocidos como “costes de corrección” que ge-neralmente involucran retrabajo, reparación, substitución de piezas, perdida de futuros negocios con el cliente, problemas contractuales.

– Costes de errores externos: Son los costes incurridos debido a que el cliente detectó defectos. La organización tiene que asumir estos costes porque su sistema de evaluación no detectó los fallos. Estos costes desaparecerían si no se hubiera producido ningún defecto. Son los costes de garantías, costes de servicio técnico, manejo de quejas y pérdidas futuras del negocio.

La gestión eficaz de los costes, enfocando fundamentalmente en la prevención, generará a lo largo del desarrollo del proyecto una serie de beneficios, por ejemplo:

– Incremento en la satisfacción del cliente: El número de defectos o problemas es inversamente proporcional a la satisfacción del cliente. Un servicio de alta calidad dará al cliente una sensación muy buena durante su desarrollo, lo que se podrá traducir más adelante en nuevas ventas.

– Mayor productividad: Corregir errores continuamente y tener que realizar el mismo trabajo dos veces en tareas ya terminadas son factores que perjudican directamente la productividad. Si los entregables son producidos con la mejor calidad posible, la productividad del proyecto como un todo será muy efectiva.

– Costes más bajos / duración más corta: Para alcanzar un cierto nivel de calidad es necesario invertir dinero, tiempo y recursos. Sin embargo, todos estos esfuerzos serán compensados a partir del mo-mento que el nivel de retrabajo empieza a reducirse y los procesos fluyan naturalmente sin incidencias.

– Mayor moral del equipo: La moral del equipo se queda dañada siempre que se producen erro-res. A nadie le gusta cometer errores y las cosas se pueden volverse muy frustrantes si estos errores vuelven a repetirse.

– Menos errores y defectos: Un trabajo realizado con calidad es un trabajo que no presenta ningún defecto. En el mercado, un producto hecho con calidad presenta menos devoluciones, menos trabajo de mantenimiento y reparo y consecuentemente, menos costes a la empresa.

8.1.1.3. Diagramas de control (Control chart)


8.1.1.4. Estudios comparativos (Benchmarking)

El benchmarking es una técnica que empezó a emplearse a finales de los 70 en Estados Unidos. Con esta técnica se pretende descubrir y definir los aspectos que hacen que una organización sea más rentable que otra, o que tenga productos y servicios mejores. Este análisis aportará informaciones que ayudarán a la organización a mejorar sus propios servicios y productos.

158


Hay que tener presente que es una técnica que no implica prácticas fuera de legalidad. No se trata de espionaje o de copiar lo que hacen otras empresas, sino realizar una investigación que permita a la empresa mejorar sus procesos internos de gestión realizando comparaciones de sus servicios y productos con las mejores prácticas del mercado.

El término inglés benchmark proviene de las palabras “bench” (banquillo, mesa) y “mark” (marca, señal). El uso del término provendría de la Inglaterra del siglo 19, cuando los agrimensores hacían un corte o marca en una piedra o en un muro para medir la altura o nivel de una extensión de tierra. El corte servía para asegurar un soporte llamado bench, sobre el cual luego se apoyaba el instrumento de medición, en consecuencia, todas las mediciones posteriores estaban hechas con base en la posición y altura de dicha marca.

El benchmarking se puede encajar perfectamente con un texto del año 500 a. C. del General Sun Tzu que dice “Conoce a tu enemigo y conócete a ti mismo; en cien batallas, nunca saldrás derrotado. Si eres ignorante de tu enemigo pero te conoces a ti mismo, tus oportunidades de ganar o perder son las mismas. Si eres ignorante de tu enemigo y de ti mismo, puedes estar seguro de ser derrotado en cada batalla”.

Técnicas de Benchmarking

En función del objetivo y de la necesidad de la organización, se pueden desarrollar varios tipos de benchmarking:

– Benchmarking interno: En empresas de grande porte que cuentan con varias divisiones y depar-tamentos, muchos de los procedimientos y gestiones utilizados son similares. El benchmarking interno trata de comparar los procesos dentro de estos departamentos, para posteriormente aplicar las mejores prácticas en toda la organización. Es una de las formas más fáciles de de-sarrollar la práctica del benchmarking, ya que es posible acceder a una importante cantidad de información de la empresa.

– Benchmarking primario: Es un tipo de benchmarking en que la información es recabada direc-tamente de la competencia. Una forma muy común de realizar este tipo de benchmarking es consultando a los antiguos empleados de otras empresas. Actualmente algunas organizaciones están optando por formalizar un contrato de confidencialidad con sus empleados, en el momento de su admisión, lo que por lo menos teóricamente, les impediría de divulgar informaciones de su trabajo anterior. De todas formas, existen otras fuentes de información importantes como son los clientes y los proveedores de la competencia, a pesar de que en muchos casos, la información podrá llegar destorcida por interés del propio cliente o proveedor.

– Benchmarking cooperativo: En este tipo de benchmarking las empresas competidoras realizan un intercambio de información entre sí. Es una técnica más sencilla en el ámbito internacional, ya que la competencia es más lejana y se percibe menos directa que la competencia nacional. No obstante, es una técnica prácticamente inexistente en empresas pequeñas o en PYMES que suelen ser muy resistentes al intercambio de informaciones.

– Benchmarking secundario: Es la recopilación de información de dominio público, como puede ser por ejemplo y sin ir más lejos, la sacada de internet. De una forma rápida, sencilla y gratui-ta, se puede obtener a través de Internet, informaciones sobre un determinado sector, cuales son las empresas competidoras, como actúan y como ofrecen sus servicios, el perfil de los clientes, entre otras.

– Benchmarking genérico: Es desarrollado entre empresas de sectores distintos que desarrollan el mismo proceso. Muchas organizaciones son estructuradas de formas similares y desarrollan procedimientos muy parecidos. El beneficio de esta forma de benchmarking tiene la posibilidad de acceder de forma más amplia a las mejores prácticas.

159

C8

Aunque parezca una técnica sencilla, el benchmarking requiere una cierta inversión económica y, sobre todo, de tiempo. Todo estudio de benchmarking conlleva a una búsqueda y recogida de infor-mación que incluye el análisis de procesos, asistencia a congresos, visitas a empresas, entrevistas, charlas y mucha investigación, además de todo el proceso de implantación y adaptación de las prác-ticas aprendidas, que seguramente es una batalla a parte.

8.1.1.5. Diseño de experimentos (Design of experiments)

El diseño de experimentos es un método estadístico que permite identificar los factores que pueden influir sobre una determinada variable. Es una técnica que se aplica de forma más frecuente al produc-to generado por el proyecto. Tiene como objetivo:

– Seleccionar la experiencia ideal que permita obtener la información buscada con el mínimo coste.

– Evaluar los resultados obtenidos, buscando garantizar la fiabilidad de la información obtenida.

Ejemplo:

– Los diseñadores de un software pueden determinar qué características (cantidad de memoria, velocidad del procesador...) debe tener un equipo informático para que su aplicación sea ejecu-tada de forma rápida y sin errores.

– Un cocinero puede combinar diferentes ingredientes, hasta encontrar el sabor ideal para el plato que está preparando.

Este método consiste básicamente en variar un factor de cada vez, a partir de una determinada con-dición inicial, en que todos los factores estudiados permanecen constantes, con excepción de aquel que se está analizando. Se repite el mismo procedimiento con los otros factores, uno a uno. Cada respuesta obtenida será atribuida a la variación de cada factor analizado y por lo tanto obtendremos los efectos derivados de este factor.

Este método tiene el inconveniente de tener que probar un factor cada vez y en algunos casos, el nú-mero de factores a probar puede ser muy alto. Se trata de una operación que puede llegar a ser muy costosa. Es importante hacer una planificación previa, descartando algunos factores hasta alcanzar una cantidad manejable. Para asegurarse que se están descartando los factores de adecuadamente, se puede realizar el mismo experimento utilizando un modelo o prototipo más sencillo. Los resultados obtenidos determinarían los mejores factores para utilizar en el experimento completo.

Los resultados obtenidos deberán ser exhaustivamente analizados, sobre todo la respuesta de sus interacciones. Todo esto contrastado con la calidad deseada, podrá asegurar que el producto final generará los resultados esperados.

8.1.1.6. Muestra estadística (Statistical sampling)


8.1.1.7. Diagrama de flujo (Flowcharting)

Un diagrama de flujo es la representación gráfica de hechos, situaciones, decisiones o relaciones de todo tipo, a través de símbolos gráficos. El diagrama de flujo representa de inmediato una visión global de un determinado proceso y ayuda a comprender mejor las relaciones y dependencias de las activi-dades que forman parte de un determinado proceso.

160


Esta herramienta es útil para determinar cómo funciona un proceso completo y es, además, una herramienta muy útil para determinar si la organización está desarrollando algún proceso con tareas innecesarias, círculos de duplicación de trabajo o problemas potenciales.

El diagrama de flujo indica acciones en secuencia y para ello existen docenas de símbolos, sobre todo para uso especializado. La simbología más comúnmente utilizada es la siguiente:

Figura 77: Elementos de un diagrama de flujo

El diagrama de flujo puede ser aplicado en cualquier situación, como por ejemplo, procesos control de documentación, procedimientos de calidad, fases de fabricación de una pieza, encuestas de mar-keting... Confeccionado de forma adecuada, el diagrama de flujo proporcionará a los miembros un conocimiento común exacto del funcionamiento de un proceso. Existen casos, como, por ejemplo, en una cadena de producción, en que se puede estimar el tiempo necesario de duración de cada ac-tividad, asignando un tiempo estimado de cada actividad y el tiempo estimado total para el desarrollo de todo el flujo.

El mercado dispone de varios programas que facilitan la confección de un diagrama de flujo. Sin embargo, su confección es muy sencilla. Conociendo todo el proceso, se puede hacer un borrador utilizando un lápiz y un folio y pasarlo a una herramienta ofimática común. Básicamente, se puede confeccionar un diagrama de flujo utilizando correctamente los símbolos descritos en la figura 77. Un diagrama de flujo, no debe excluir ninguna actividad, tiene que ser confeccionado tal cual es realizado en la práctica y las personas responsables en llevar a cabo el proceso deben participar directamente de la confección de estos flujos.

La figura 78, que se presenta a continuación, ilustra un diagrama de flujo de un proceso de atención a un cliente usuario de un servicio de telefonía.

161

C8

Figura 78: Ejemplo de un diagrama de flujo de atención al cliente

8.1.1.8. Metodologías propietarias de dirección de calidad (Property quality management methodologies)

El mercado dispone de una importante gama de metodologías propietarias, donde podemos destacar las más utilizadas:

– Madurez máxima en dirección de proyectos a nivel organizacional (organizational Project Mana-gement maturity model – OPM3®).

– PRINCE2® (Projects in controlled environments).

– Método en V (V-Model – German project management method).

– HERMES.

– ISO 9000.

– ISO 10006.

– Modelo de madurez de capacidades (Capability caturity model – CMM®).

– Six Sigma®.

Véase también la información más ampliada de estas metodologías en la sección “referencias” de esta obra.

¿Es unproblemanivel 1?

SÍ

Analisa problema

NO

Recoje llamada

Repasallamada al

técnico nivel 2

Analisaproblema

Refleja solucióndel problemaen el sistema

¿Resuelve elproblema?

SÍ

Refleja solución delproblema en el sistema

Envia técnico aldomicilio del cliente

NO

Solucionaproblema

162


8.1.1.9. Análisis de campos de fuerza (Force field analysis)

El análisis de campos de fuerza es una herramienta utilizada para realizar una evaluación a fondo de un determinado cambio. Esta herramienta ve el cambio como un evento que trae consigo dos fuerzas antagónicas que compiten entre si: las fuerzas impulsoras (driving forces), que facilitan el cambio y conspiran a su favor y las fuerzas restringentes (restraining forces), que presionan contra el cambio. Este análisis nos ayuda, por lo tanto, a identificar los factores que pueden contribuir para el éxito o fracaso del cambio propuesto.

¿Cómo se desarrolla?

– De define el cambio deseado

– Se realiza una sección de tormenta de ideas para identificar las fuerzas impulsoras y restringentes.

– Se clasifica el orden de prioridad de cada fuerza.

– Se definen las acciones a tomar.

Figura 79: Ejemplo de aplicación del análisis de campo de fuerzas

Una vez desarrollado el gráfico de análisis de fuerzas y estudiando sus resultados, se decide si el cambio es viable en función de las fuerzas a favor y en contra. Si la decisión es llevar a cabo el cambio, se definirán acciones para intentar minimizar el impacto de los contras y aumentar la fuerza de los pros.

*Nota del autor: Teniendo en cuenta que cada fuerza tiene grados de intensidad e impacto diferentes sería interesante, y además muy recomendable, asignar pesos para cada fuerza identificada, utilizando, por ejemplo, una escala de 1 a 5 (1 para más débil y 5 para más fuerte). Al asignar pesos a las fuerzas, será posible conocer cuáles son las fuerzas impulsoras y res-tringentes más potentes, y de esta forma, poner en marcha acciones paralelas que logren aumentar la potencia de las fuerzas más favorables y reducir (o eliminar) la potencia de las fuerzas más restringentes. La puntuación se puede obtener por medio de la información disponible o simplemente por criterio de las personas involucradas en la decisión. En el segundo caso, pue-de ocurrir una manipulación de valores para obtener un valor favorable según determinados intereses personales. Por ello, es recomendable trasladar este criterio de valores a un juicio de expertos.

En la figura 80, podemos apreciar que la suma de puntos nos conducirá a la decisión de no realizar el cambio. No obstante, si somos capaces de debilitar o eliminar alguna de las fuerzas restringentes (por ejemplo, reducir el coste de implantación y/o eliminar los problemas de compatibilidad), podíamos cambiar el resultado final del análisis, favoreciendo por lo tanto, al cambio de tecnología. También se podría por otro lado, intentar potencializar alguna fuerza impulsora (logrando obtener mejores tasas de financiación) o incluyendo una nueva fuerza impulsora todavía no identificada.

FUERZAS IMPULSORAS (+)

NUEVATECNOLOGIA

TECNOLOGIAACTUAL

CAMBIODESEADO

(-) FUERZAS RESTRINGENTES

(4) Precio accesible(2) Baja tasa de financiación

(2) Capacidad de competición(5) Disminución de riegos

(5) Obtención rapida de resultados

La tecnologia anterior no se ha pagado (4)Alto coste de implantación (5)Dificultad de adaptación (3)Dificultad de mantenimiento (4)Problemas de compatibilidad (5)

TOTAL: 18 TOTAL: 21

163

C8

Figura 80: Análisis de campo de fuerzas incluyendo asignación de pesos

8.1.1.10. Listas de verificación (Checklists)


8.2. Aseguramiento de la calidad (proceso que corresponde a la fase de ejecución del proyecto)

El aseguramiento de calidad es el proceso que consiste en auditar los requisitos de calidad y los re-sultados obtenidos a partir de medidas de control de calidad, con el fin de garantizar que se utilicen definiciones operacionales y normas de calidad adecuadas.

Esta gestión también se encarga del proceso de mejora continua, que es un medio iterativo de mejora de la calidad de todos los procesos. El proceso de mejora continua reduce las actividades inútiles y elimina aquellas que no agregan valor al proyecto. El resultado es la obtención de un proceso que opera a nivel óptimo, evitando de esta forma, el consumo desnecesario de recursos


8.2.1.1. Auditorías de calidad (Quality audits)

En muchos casos, es importante realizar evaluaciones puntuales acerca del desarrollo de un proyecto a través de un proceso de verificación realizado por un agente externo. Este proceso de verificación es conocido como auditoría y es empleada para comprobar y evaluar las actividades relacionadas con el desarrollo de los productos y servicios de una organización. Su realización puede ocurrir por solicitud de la administración, por exigencia de un cliente, por solicitud de una entidad certificadora, por el gobierno, o incluso por exigencia del sistema de calidad adoptado por la organización. En cualquiera de los casos, es importante que la alta dirección facilite los medios adecuados para su realización, así como la mejora de las áreas no conformes con el modelo exigido. La filosofía de la auditoría de calidad será normalmente basada en la verificación y en la prevención, más que en la detección de problemas.

FUERZAS IMPULSORAS

NUEVATECNOLOGIA

TECNOLOGIAACTUAL CAMBIO DESEADO

FUERZAS RESTRINGENTES

(4) Precio accesible(2) Baja tasa de financiación

(2) Capacidad de competición(5) Disminución de riegos

(5) Obtención rapida de resultados

La tecnologia anterior no se ha pagado (4)Alto coste de implantación (5)Dificultad de adaptación (3)Dificultad de mantenimiento (4)Problemas de compatibilidad (5)

TOTAL: 18 TOTAL: 21

164


La persona que realiza la auditoría debe tener la cualificación apropiada para hacerlo, de preferencia debe poseer una formación específica y principalmente conocer el sector en que se realiza la auditoría. La documentación básica de un proceso de auditoría de calidad es la siguiente:

– Agenda de realización de la auditoría (audit agenda).

– Listas de verificación (Checklists).

– Informes de deficiencias y recomendaciones (audit report).

Las fases de una auditoría de calidad son las siguientes:

– Notificación: El Project Manager recibe una notificación del auditor en que se solicita una reu-nión para tratar de la agenda de la auditoría, los departamentos y personas que serán auditadas. Una vez establecida la agenda de la auditoría, el Project Manager deberá notificar a todo el personal afectado.

– Preparación: El auditor necesitará de algunas informaciones preliminares del proyecto que de-berán ser suministradas por el Project Manager. Es importante que, en esta fase, el auditor y el Project Manager intercambien informaciones para que la auditoría pueda ser realiza de forma más productiva posible.

– Auditoría: El auditor realizará las comprobaciones necesarias para verificar si el proyecto cum-ple con los procedimientos establecidos. En esta fase, el auditor detectará las conformidades y no conformidades.

– Análisis complementares: En algunos proyectos, una reunión suele ser suficiente. Sin embargo, en proyectos grandes y complejos, será necesaria la realización de otras reuniones en que el auditor realizará una sección de análisis y cuestionamientos complementares. Este tipo de acción podrá incluir reuniones con el cliente y análisis de la documentación técnica.

– Informe inicial: Tras la conclusión de las fases de recogida de datos y análisis de información, el auditor confeccionará los resultados en un informe que será entregado al Project Manager para su apreciación. Este informe incluirá también las recomendaciones y acciones que deberán ser llevadas a cabo para sanar las eventuales no conformidades;

– Reunión de revisión: Otra reunión entre el Project Manager y el auditor deberá ser realizada para discutir los puntos descritos en el Informe Inicial. El auditor realizará sus comentarios acerca de todo el informe, haciendo hincapié, sobre todo, en las no conformidades detectadas.

– Informe final: El Auditor finalmente, confeccionará y enviará al Project Manager el informe final, detallando los trabajos y resultados de todas las fases anteriores. Se realizará una junta con la dirección en que se discutirán los puntos del informe final y se decidirán las acciones para corregir las no conformidades encontradas y evitar que se produzcan los mismos errores.

8.2.1.2. Informe de auditoría (Audit report)

El informe de auditoría es un documento que expresa la opinión de un profesional cualificado acerca de la información y de la documentación de calidad de una organización. Constituye la etapa final del proceso de auditoría, en el mismo se recogen todos los hallazgos detectados y el soporte documental para sustentar el dictamen emitido, por lo que requiere de extremo cuidado en su confección.

La capacidad y habilidad del auditor en la redacción del informe, son fundamentales para que este lo-gre sus objetivos y cumpla con los propósitos de ofrecer los elementos que permitan al lector conocer, de forma fácil, los resultados del trabajo realizado por los auditores.

165

C8

8.3. Control de calidad (proceso que corresponde a la fase de control del proyecto)

La calidad es un concepto muy relativo y subjetivo, ya que diferentes personas pueden tener una percepción diferente de la calidad, es decir, lo que es bueno para unos puede no serlo para otros. Un producto o servicio es considerado de calidad cuando refleja exactamente las expectativas del cliente y será el factor que determinará su grado de satisfacción con los resultados generados.

Un control efectivo de la calidad es posible si los requisitos del cliente son claramente definidos y am-pliamente conocidos por todas las partes involucradas. Una vez finalizado un producto o servicio, se comparan si los resultados generados son exactamente los mismos especificados anteriormente por el cliente. En muchos proyectos estos requisitos no existen o no se tienen en cuenta. De esta forma, resulta imposible realizar un servicio o producto que pueda atender las expectativas del cliente. El con-trol de calidad además debe ser de carácter preventivo y es una gestión constante, que acompañara el ciclo de vida del proyecto en todas sus fases.

Entre otros aspectos, puede resultar útil para el equipo conocer la diferencia entre los siguientes pares de términos:

– Prevención (evitar que haya errores en el proceso) e inspección (evitar que los errores lleguen a manos del cliente).

– Muestreo por atributos (el resultado cumple o no con los requisitos) y muestreo por variables (el resultado se clasifica según una escala continua que mide el grado de conformidad).

– Tolerancias (rango especificado de resultados aceptables) y límites de control (umbrales que pue-den indicar si el proceso está fuera de control).


8.3.1.1. Mediciones de calidad (Quality control measurement)

Medir cosas es una práctica muy común en nuestro cotidiano. Todos los días, solemos medir pesos, alturas, temperaturas, ruidos, dimensiones y un sinfín de valores. Estas mediciones se realizan a través de un valor de referencia, que nos permite evaluar si nos situamos por debajo o por encima del valor deseado para alcanzar un determinado nivel de calidad. “Si usted no puede medir algo, es imposible que pueda mejorarlo”. Esta frase de Edward Deming traduce la importancia que las mediciones pro-porcionan a la calidad de los productos y/o servicios desarrollados en un proyecto.

Son muchos los argumentos que justifican el uso de mediciones de calidad. Normalmente las utilizamos para:

– Indicar la calidad del producto.

– Evaluar la productividad de la gente que desarrolla el producto.

– Evaluar los beneficios en términos de productividad y de calidad.

– Establecer una línea de base para la estimación.

– Ayudar a justificar el uso de nuevas herramientas o de formación adicional.

166


Las mediciones en la fase de control de calidad de un proyecto nos pueden aportar las informacio-nes necesarias para tomar las decisiones adecuadas, como por ejemplo, la puesta en marcha de medidas preventivas, si se constata que el producto no está logrando alcanzar la calidad adecuada. Además nos pueden contar si se está ejecutando el proyecto correctamente, si estamos obteniendo los objetivos buscados, si el cliente está satisfecho, si nuestros procesos son efectivos o es necesario mejorar algún aspecto del mismo, identificar tendencias, evaluar la implementación de cambios, efec-tuar análisis y proyecciones en general. Un buen programa de control de proyectos debería identificar, seleccionar y priorizar las métricas a utilizarse para el monitoreo de la performance del proyecto y el logro de sus objetivos.

Una buena medición debe cumplir los siguientes requisitos: sus resultados tienen que ser consisten-tes, entendibles, manejables, analizables y obtenidos de forma sencilla.

8.3.1.2. El Ciclo PDCA (PDCA cycle)

También conocido como “ciclo Deming”, fue creado por Edwards Deming, estadístico y profesor es-tadounidense. Se trata de una herramienta cuya función es crear una estrategia de mejora continua de la calidad en cuatro etapas, basada en un concepto creado por Walter A. Shewhart, considerado el padre del control estadístico de la calidad.

Figura 81: Ciclo PDCA

*Nota del autor: Los modelos de métricas de calidad más conocidos en los proyectos de desarrollo de software son los siguientes:

Modelo de MCCALL (1977)

– Describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre factores de calidad, en base a criterios.

– Los factores de calidad se concentran en tres aspectos importantes de un producto de software: características operativas, capacidad de cambios y adaptabilidad a nuevos entornos.

– Identifica una serie de criterios, tales como rastreabilidad, simplicidad, capacidad de expansión...

– Las métricas desarrolladas están relacionadas con los factores de calidad y la relación que se establece se mide en función del grado de cumplimiento de los criterios.

Modelo de FURPS (1987)

– Modelo desarrollado por Hewlett-Packard (HP) en 1987, desarrollando un conjunto de factores de calidad de software y sus respectivos atributos.

– Basado en el modelo de MCCALL.

– Se utilizan para establecer métricas de la calidad para todas las actividades del proceso de desarrollo de un software, inclu-sive de un sistema de información.

– FURPS es una sigla que significa: Functionality, Usability, Reliability, Performance y Supportability.

Modelo de DROMEY (1996)

– Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo do-cumentos de requerimientos, guías de usuarios, diseños y código).

– Sugiere el uso de cuatro categorías que implican propiedades de calidad, que son correcciones internas, contextuales y descriptivas.

167

C8

Las siglas PDCA son el acrónimo de Plan (planificar), Do (hacer), Check (verificar), Act (Actuar). Estas acciones consisten en:

– Planificar (plan): Prevenir y definir las actividades a desarrollar, identificando el proceso que se quiere mejorar y recopilando la información necesaria para profundizar el conocimiento del proceso para establecer los objetivos de mejora y definir los procesos necesarios para lograr estos objetivos.

– Hacer (do): Realizar las actividades definidas en el proceso anterior definidas y documentar las acciones realizadas.

– Verificar (check): Monitorizar el estado del proyecto. El Project Manager compara el resultado obtenido con el planificado y evalúa las diferencias.

– Actuar (act): Anticipar el problema, mitigando posibles riesgos.

– ... ¡¡¡y volver a empezar!!!

8.3.1.3. Inspección (Inspection)


8.3.1.4. Gráfico de control (Control chart)

El gráfico de control es utilizado para verificar si un proceso fluye normalmente, a través de la monitori-zación de su avance. Es una herramienta muy utilizada en procesos repetitivos, como son los de pro-ducción, pero muy útil para monitorizar variaciones de costes y plazos. Todo proceso está expuesto a variaciones que pueden ser resultantes de una causa puntual o de pequeñas incidencias que se van acumulando y que acaban generando una variación visible que necesita de acciones correctivas para que se mantenga estable otra vez. Cuando un proceso se encuentra dentro de los límites estableci-dos es porque su curso avanza de forma normal. Si el proceso sale de estos límites, es necesarios realizar reajustes.

La figura 82 es un ejemplo de un gráfico de control, en que un determinado proceso está bajo segui-miento del Project Manager y del equipo del proyecto. Los puntos ilustrados en el ejemplo tienen que estar dentro de la zona límite de normalidad. Si uno de estos puntos sobrepasa el límite, el proceso ha salido de control e inmediatamente el Project Manager deberá poner en marcha un plan de acción correctiva, como ocurre en el ejemplo ilustrado en la figura 82, donde se puede apreciar que algunos puntos han sobrepasado la zona de variación normal, situándose en la zona de control.

Figura 82: Ejemplo de gráfico de control

168



Es una herramienta que se utiliza para determinar la frecuencia que ocurre un evento a lo largo de un periodo de tiempo determinado. En esta lista se recoge información de cualquier clase de ocurrencias basándose en información histórica o en eventos que están ocurriendo.

Para demostrar un ejemplo de su uso, ilustraremos a continuación el caso de la empresa de informá-tica Alfa PC, que se dedica al montaje y la comercialización de ordenadores de sobremesa.

Su sistema de ventas consiste en comprar de mayoristas las piezas de los ordenadores (placas, memorias, discos duros...) y montar los equipos a medida para sus clientes que son en su mayoría, personas físicas. Una vez montado el equipo, este es entregado al cliente sin realizar ningún tipo de verificación, puesto que ellos contaban con las pruebas realizadas anteriormente por sus proveedores que certificaban que sus componentes eran probados y funcionaban perfectamente. No obstante, las quejas recibidas por parte de algunos de sus clientes no decían lo mismo.

Preocupados con su imagen, decidieron realizar un análisis más a fondo.

Tras verificar las notas de reparo del departamento técnico, se constató que durante los últimos doce meses, el 20% de los equipos vendidos presentó defectos. Un número bastante elevado que, ade-más de perjudicar su imagen, conllevaba a costes que a largo plazo la empresa Alfa PC no podría soportar.

Para intentar buscar una solución que pudiera reducir el número de equipos defectuosos, la gerencia de Alfa PC recogió toda la información de los equipos que presentaron problemas en estos doce meses y confeccionaron la lista a continuación:

Componentes Defectos

R Ratón 29

R Altavoces 29

R Disco duro 82

R Placa de red 51

R Monitor 13

R Teclado 20

R Placa base 109

R Memoria 67

Total 400

Figura 83: Ordenadores vendidos con defecto

Con esta sencilla herramienta fue posible identificar los componentes que presentaron problemas en todos los cuatrocientos equipos defectuosos que retornaron a la asistencia técnica para reparo.

Decidieron que, a partir de entonces, ningún equipo saldría de las tiendas de Alfa PC sin antes pasar por una serie de pruebas internas que garantizasen su correcto funcionamiento. Es decir, cada equipo tendría que presentar cero defectos para ser vendido. Para garantizarlo, cada equipo pasaría por un chequeo, utilizando la lista de verificación anteriormente confeccionada:

169

C8

A partir de entonces, no se ha vendido una sola unidad que presentara el mínimo defecto. Diez meses después, se podía apreciar la siguiente tabla de defectos:

Componentes Defectos

R Ratón 0

R Altavoces 0

R Disco duro 0

R Placa de red 0

R Monitor 0

R Teclado 0

R Placa base 0

R Memoria 0

Total 0

Figura 84: Ordenadores vendidos con defecto

La lista de verificación logró reducir a cero el número de equipos vendidos con defecto. Sin embargo, los defectos seguían ocurriendo en el taller de montaje de la empresa, durante las pruebas realizadas antes de la venta.

Sus proveedores garantizaban que las piezas eran probadas y no presentaban defectos. La única explicación plausible era que algún problema todavía no identificado podría estar ocurriendo en el taller de montaje de Alfa PC. Para llegar a la causa del problema sería necesario realizar un análisis más detallado, utilizando las herramientas que veremos a continuación.

8.3.1.6. Diagramas de Pareto (Pareto Chart)

El diagrama de Pareto, también llamado “curva 80-20” o “distribución A-B-C”, es una técnica de or-ganización de datos de forma que estos queden en orden descendente, de izquierda a derecha y separados por barras. Permite, pues, asignar un orden de prioridades.

El diagrama permite mostrar gráficamente el principio de Pareto (pocos vitales, muchos triviales), es decir, que hay muchos problemas sin importancia frente a unos pocos graves. Mediante la gráfica colocamos los “pocos vitales” a la izquierda y los “muchos triviales” a la derecha.

Su origen proviene de los estudios del economista italiano Wilfredo Pareto que desarrolló una teoría que afirmaba que el 80% de la riqueza en Italia estaba en manos de 20% de la población.

Siglos más tarde, J. Duran utilizó esta teoría para determinar que en tan solo el 20% de las actividades eran responsables por el 80% de los problemas.

Por lo tanto, el diagrama de Pareto es una técnica que separa los “pocos vitales” de los “muchos triviales”. Este diagrama consiste en un gráfico de barras que ordena la frecuencia de las ocurrencias por orden de importancia, de la mayor a la menor en un orden decreciente, ilustrando cuales son los problemas o incidencias más significativas y/o cuales son las incidencias que requieren más atención.

170


¿Cómo se confecciona un diagrama de Pareto?

Dando continuidad al ejemplo descrito en la sección anterior, la empresa Alfa PC cuantificó los defec-tos encontrados en los equipos informáticos que son vendidos en sus tiendas. Fueron identificados ocho tipos de defectos clasificados por componentes. A continuación, se realizó la distribución de la cantidad de defectos por componente y se ordenaron los datos por orden descendente. Se computó el porcentaje que cada componente representa en función del total. A continuación se computaron el porcentaje acumulado que necesariamente tiene que alcanzar el 100%.

Componentes Defectos % % Acumulada

A Placa base 109 27% 27%

B Disco duro 82 21% 48%

C Memoria 76 19% 67%

D Placa de red 51 13% 80%

E Altavoces 29 7% 87%

F Teclado 20 5% 92%

G Ratón 20 5% 97%

H Monitor 13 3% 100%

Total 400 100%

Figura 85: Tabla de distribución

Una vez identificados los componentes defectuosos en una tabla de distribución, según ilustra la figura 85, se confecciona el gráfico de Pareto. Para ello, es necesario seguir los pasos que vienen a continuación:

– Se trazan los ejes horizontales (componentes analizados) y verticales (de cero al total según se ha calculado).

– De la izquierda a la derecha se trazan las barras para cada componente en orden descendente.

– Se traza la línea de porcentaje acumulativo, empezando por el componente que acumuló el mayor número de defectos, se van sumando los porcentajes acumulativos. Se diseñan los puntos por-centuales que se conectarán hasta que se alcance el 100%.

Figura 86: Gráfico de Pareto

20%

40%

60%

80%

0%

100%

27%

48%

67%

80%

87%92%

97% 100%

100

50

0

250

200

150

350

300

cant

idad

es d

e de

fect

os

porc

enta

ge a

cum

ulad

o

A B C D E F G H

171

C8

En el caso de la empresa Alfa PC se llegó a una curiosa y hasta entonces desconocida constata-ción: el 80% de los defectos de los equipos correspondía a problemas en las placas internas de los equipos, y solamente el 20% de los defectos estaba vinculado a los accesorios externos (altavoces, teclado, ratón y monitor).

El uso de del diagrama de Pareto fue fundamental para llegar a esta conclusión. Ahora, la empresa Alfa PC es consciente de que el gran problema de sus equipos ocurre en los componentes internos de sus equipos. La pregunta ahora es: “¿cuál es la razón por el cual eso ocurre?”. La solución final de este problema será presentada a continuación, con el diagrama de causa-efecto.

8.3.1.7. Diagrama de causa‑efecto (Cause and effect diagram)

El diagrama de causa-efecto es una presentación gráfica de las causas de un determinado fenómeno. Fue concebido por el ingeniero japonés Kaoru Ishikawa en el año 1953 y consiste en una técnica que organiza y representa las diferentes teorías propuestas sobre las causas de un problema. Se conoce también como “diagrama de Ishikawa” o “diagrama de espina de pez” y se utiliza en las fases de diag-nóstico y solución de una determinada causa.

El ejemplo que sigue intenta identificar las causas por las que los componentes internos de los equi-pos informáticos montados en el taller de la empresa Alfa PC representan el 80% de los componentes defectuosos.

En una sección de brainstorming (descrita en la sección 11.2.1.9), el equipo responsable del montaje de los equipos de Alfa PC intenta identificar las causas principales y secundarias de los defectos en los componentes utilizados en el montaje de sus PC.

En este caso, los agentes que influyen directamente en el montaje de los equipos son:

– Los equipos auxiliares de montaje (herramientas, maquinaria).

– El método (la forma en que se montan los equipos).

– El material utilizado (la materia-prima incluyendo sus proveedores).

– El personal (la plantilla del taller y sus encargados).

– Las instalaciones (luz, mobiliario, espacio físico).

Analizando cada categoría, se identifican las posibles causas que pueden producir defectos.

Figura 87: Diagrama de Ishikawa

EQUIPOS METODO MATERIAL

PERSONAL INSTALACIONES

PROBLEMA

CAUSA

EFECTO

formación insuficiente

poco dedicado iluminación insuficiente

temperaturas altas

desfasados

mal calibrados

secuencia equivocada

mal planificado

mala calidad

material incorrecto

172


El resultado es el diagrama que ilustra la figura 87. Fueron identificadas dos causas para cada ca-tegoría y muy probablemente una de ellas es la causa real del problema encontrado en los equipos montados por Alfa PC.

Una vez identificadas las causas, se buscan soluciones para subsanarlas. Se verifican si las causas encontradas realmente presentan los problemas señalados por el equipo encargado durante la con-fección del diagrama. Si se comprueban que estos problemas realmente existen, se busca la forma más adecuada de resolverlos.

Figura 88: Solución propuesta

La figura 88 ilustra la ampliación de una de las “espinas” del diagrama. Se puede observar que las ins-talaciones físicas de la fábrica son poco iluminadas y a la vez producen mucho calor por tratarse de un ambiente poco ventilado. Estos dos factores influyen en el desempeño del personal que trabaja bajo con-diciones poco confortables, perjudicando también el funcionamiento de algunos equipos que se sobre-calientan. Eso puede explicar el hecho de que el 80% de los problemas provienen de los componentes internos de los equipos. Quizás esté ahí la raíz del problema que la gerencia de Alfa PC estaba buscando.

La solución para esta causa seria la puesta en marcha de las reformas adecuadas para resolver estos problemas. Una vez que ha sido posible identificar otras causas, la gerencia podrá aprovechar para resolverlas, poniendo en marcha las medidas correctivas convenientes.

8.3.1.8. Muestra estadística (Statistical sampling)

Esta técnica consiste en recoger una muestra representativa, a partir de un determinado universo de interés. Al elegir esta muestra, se espera que los resultados obtenidos sean fiables al universo total. Este proceso permite la obtención de resultados muy similares a los de un estudio exhaustivo de todo el uni-verso, pero de forma más rápida y menos costosa. En algunos casos, el muestreo puede aportar datos aún más exactos que los de una investigación completa ya que el manejo de un número menor de in-formación reduce la probabilidad de errores en su tratamiento. El tamaño del muestreo será determinado por la organización y deberá obtener un resultado fiable que deberá ser siempre inferior que el del univer-so total, pero suficiente para que la estimación de los resultados alcance el nivel de confianza adecuado.

Un ejemplo de uso de esta técnica son las encuestas electorales (barómetros), que buscan anticipar el ganador de una elección, o los formularios de opinión que buscan a través de un determinado número de personas, conocer la opinión general de la población acerca de un determinado tema de interés (la audiencia de un programa de televisión, la opinión acerca de algún proyecto del gobierno...).

*Nota del autor: Algunas recomendaciones:

– Defina el problema que pretende investigar de forma precisa: Es decir, evite términos abstractos o ideas muy genéricas que no permitirán identificar las causas reales.

– Identifique las causas del problema: La forma más adecuada es hacerlo en reuniones o secciones de brainstorming invitando personas involucradas en el proceso.

– Se concentre en las causas que realmente pueden ser resueltas: Si son encontradas causas que no podrán ser resuel-tas por alguna limitación, el diagrama de causa efecto pierde su aplicación práctica.

INSTALACIONES

poca iluminación

temperaturas altasNECESITA REFORMAS

173

C8

El tamaño de la muestra seleccionada puede variar de acuerdo con el tipo de estudio. Existen fórmulas complejas para determinar el porcentaje ideal de la muestra a ser analizada, pero de manera general si el universo contiene menos de cincuenta elementos, no se debe coger muestras. En este caso, se estudiará todo el universo. Cuando se rebasa esta cifra, la muestra deberá tener entre el 10% y el 15% del total de los elementos.

En el caso de proyectos, existen muchas situaciones en que se puede utilizar esta técnica, como, por ejemplo, en el caso de un proyecto que conlleve a la producción de una determinada pieza. Si una fábrica produce diez mil piezas de un determinado producto y necesita comprobar su durabilidad, se realizan pruebas en, por ejemplo, el 10% del total de las piezas producidas (es decir, mil piezas), cuyos resultados representarán la totalidad de la producción. Además de fiable (el margen de error suele ser marginal), teóricamente esta muestra estadística solamente habrá consumido el 10% de los recursos necesarios para realizar una prueba en la totalidad de piezas producidas.

8.3.1.9. Análisis de tendencias (Trend analysis)


8.3.1.10. Diagramas de flujo (Flowcharts)


8.3.1.11. Diagramas de interrelación (Interrelationship diagram)

El diagrama de interrelación muestra cómo diferentes factores están relacionados entre sí, basándose en causa y efecto. Es una herramienta que ayuda a identificar los aspectos del proyecto que están cau-sando problemas y que son el resultado de otra acción. También muestra la fuerza de cada influencia. El diagrama consiste en un conjunto de círculos (o cajas), que representan cada aspecto que debemos analizar, organizada de forma radial. Las líneas se dibujan entre los círculos para indicar su relación.

Figura 89: Diagrama de interrelación

*Nota del autor: Es más ventajoso realizar un estudio de calidad analizando una muestra en lugar de analizar toda la población por varias razones: – En algunos casos, la población es muy grande y, por lo tanto, imposible de analizar en su totalidad. – Las características o deseos de toda la población pueden variar si el estudio se prolonga demasiado tiempo. – Reducción de costes: al estudiar una pequeña parte de la población, los gastos de recogida y tratamiento de datos serán

menores que si los obtenemos de su totalidad. – Rapidez: el estudio de la muestra reduce el tiempo de recogida y tratamiento de los datos, proporcionando los resultados

en menos tiempo. – La elección de una muestra permite la realización de estudios que sería imposible hacerlo sobre el total de la población. – En algunos procesos es necesario destruir o consumir totalmente un componente para extraer los resultados deseados (por

ejemplo: vida útil de una bombilla, carga soportada por una cuerda, precisión de un proyectil...).

174


Principales usos

Los diagramas de interrelación pueden ser muy útiles cuando se trata de resolver la causa y el re-sultado de un problema específico. A pesar de que no se identifican las razones detalladas para el problema, sí nos permiten analizar las causas y los efectos que los aspectos causan unos a otros.

Cómo se desarrolla

– Se identifica un problema: Se decide cuál es el problema que debe ser solucionado mediante el análisis de sus diversos factores. Se posiciona este problema en el círculo superior del diagrama.

– Se Identifican los factores: Se realiza una sección de brainstorming (véase también sección 11.2.1.8) para producir todas las cuestiones clave, las ideas, motivos, causas…, para el proble-ma. Se organizan los resultados en los otros círculos del diagrama de forma aleatoria.

– Se conectan los factores: Se elige cualquiera de los resultados para empezar y se van conec-tando uno con los otros. Para que la herramienta pueda proporcionar los resultados adecuados, es importante definir qué elemento del diagrama es la causa y qué elemento es el efecto. Con una flecha se enlazan los dos elementos en el orden “causa-efecto”.

– Se define la intensidad: Si un elemento tiene una influencia particularmente fuerte en otro ele-mento, la flecha que los enlaza debe ser más oscura, si se trata de una relación débil, se utiliza una línea de puntos.

– Se analiza el diagrama: Cualquier elemento con una gran cantidad de flechas salientes es una causa fundamental del problema. Cualquier elemento con muchas flechas apuntando hacia él es un resultado principal.

– Se verifica la precisión: Es importante llevar los resultados a un juicio de expertos, para even-tualmente añadir otras cuestiones que puedan jugar un papel importante en el problema y luego discutir la forma de resolverlo, centrándose en la principal causa.

8.3.1.12. Diagramas de dispersión (Scatter diagram)

Un diagrama de dispersión es un tipo de diagrama matemático que utiliza las coordenadas cartesianas para mostrar los valores de dos variables para un conjunto de datos.

Los datos se muestran un conjunto de puntos, cada uno con el valor de una variable que determina la posición en el eje horizontal y el valor de la otra variable determinado por la posición en el eje vertical. Un diagrama de dispersión se puede llamar también “gráfico de dispersión”.

Esta herramienta se emplea cuando existe una variable que está bajo el control del experimentador. Si existe un parámetro que se incrementa o disminuye de forma sistemática por el experimentador, se le denomina “parámetro de control” o “variable independiente” y habitualmente se representa a lo largo del eje horizontal. La variable medida o dependiente usualmente se representa a lo largo del eje vertical. Si no existe una variable dependiente, cualquier variable se puede representar en cada eje y el diagrama de dispersión mostrará el grado de correlación (no causalidad) entre las dos variables.

Un diagrama de dispersión puede sugerir varios tipos de correlaciones entre las variables con un in-tervalo de confianza determinado. La correlación puede ser positiva (aumento), negativa (descenso), o nula (las variables no están correlacionadas). Se puede dibujar una línea de ajuste (llamada también “línea de tendencia”) con el fin de estudiar la correlación entre las variables. Una ecuación para la co-rrelación entre las variables puede ser determinada por procedimientos de ajuste. Para una correlación lineal, el procedimiento de ajuste es conocido como regresión lineal y garantiza una solución correcta en un tiempo finito.

175

C8

Uno de los aspectos más poderosos de un gráfico de dispersión, sin embargo, es su capacidad para mostrar las relaciones no lineales entre las variables. Además, si los datos son representados por un modelo de mezcla de relaciones simples, estas relaciones son visualmente evidentes como patrones superpuestos.

El diagrama de dispersión puede aportar los siguientes resultados:

Correlación positiva fuerte: El valor del eje “Y” aumenta así como el valor del eje “X”:

Figura 90: Correlación positiva fuerte

Correlación negativa fuerte: El valor del eje “Y” disminuye así como el valor del eje “X”:

Figura 91: Correlación negativa fuerte

176


Correlación positiva débil: El valor del eje “Y” aumenta superficialmente, así como el valor del eje “X”:

Figura 92: Correlación positiva débil

Correlación negativa débil: El valor del eje “Y” disminuye superficialmente, así como el valor del eje “X”:

Figura 93: Correlación negativa débil

177

C8

Correlación compleja: El valor de “Y” parece tener relación con el valor de “X”, pero esta relación no es fácilmente determinada:

Figura 94: Correlación compleja

Sin correlación: No hay cómo comprobar una conexión entre las variables.

Figura 95: Sin correlación

178


8.3.1.13. Diseño de experimentos (Design of experiments)

Desarrollada por Ronald Fisher, considerado como el padre del diseño experimental, esta herramienta es un método estadístico que identifica los factores que pueden influir en variables específicas de un producto o proceso en fase de desarrollo de producción. El diseño experimental es una técnica esta-dística que permite identificar y cuantificar las causas de un efecto dentro de un estudio experimental. En un diseño experimental se manipulan deliberadamente una o más variables, vinculadas a las cau-sas, para medir el efecto que tienen en otra variable de interés. El diseño experimental prescribe una serie de pautas relativas a qué variables hay que manipular, de qué manera, cuántas veces hay que repetir el experimento y en qué orden para poder establecer con un grado de confianza predefinido la necesidad de una presunta relación de causa-efecto.

Ejemplo de aplicación:

Se pretende evaluar la resistencia de una pieza metálica sometida a temperaturas cambiantes. La pieza puede ser elaborada con tres tipos de metales distintos. De ahí que se plantee las siguientes preguntas:

– ¿Qué efecto tienen la composición de la pieza y la temperatura en la resistencia de la pieza?

– ¿Existe algún material con el que la pieza resulte más resistente que con cualquiera de los otros dos independientemente de la temperatura?

Para darles respuesta, se realiza una serie de experimentos. Cada uno de ellos consiste en tomar una pieza de un material dado, someterla a una temperatura prefijada y aplicarle una presión hasta que la pieza se quiebre. El grado de presión necesario será la medida de resistencia de la pieza.

Por fijar ideas, se seleccionan tres temperaturas, -20ºC, 20ºC y 60ºC. Por lo tanto, se realizarán nueve pruebas, (tres temperaturas diferentes por tres tipos de metal). Para dar más credibilidad a los resulta-dos de las pruebas, se repite cada una de las nueve pruebas cuatro veces cada una. Normalmente, se realizan las pruebas de forma aleatoria.

Tras realizar los experimentos, se obtiene 36 resultados, es decir, 4x9 medidas de resistencia distintas. A partir de ese momento, se realiza un estudio cuantitativo utilizando técnicas estadísticas, que ya no forman parte propiamente de la fase del diseño experimental.

8.3.1.14. Histogramas (Histograms)

La palabra “histograma” tiene origen en el vocablo griego “histos”, que significa “tela”. Por otro lado, la palabra “gramma” significa “letra” o “texto”. Se considera que la unión de estas dos pala-bras ha resultado en el nombre “histograma”, tal y como lo conocemos actualmente. No obstante, existe una otra versión (quizás la más verosímil), que defiende que este término ha sido creado en 1895, por Karl Pearson, un prominente científico y matemático, que estableció la disciplina de la estadística matemática.

Un Histograma es un tipo especial de gráfico de barras que despliega la variabilidad dentro de un proceso. Su técnica empieza con la toma datos variables, tales como alturas, pesos, densidades, tiempo, temperaturas, entre otros, y despliega su distribución. Los patrones inusuales o sospechosos pueden indicar que un proceso necesita investigación para determinar su grado de estabilidad.

Distinta del Pareto, cuya finalidad es priorizar acciones para la mejoría, el histograma permite la inter-pretación de grandes volúmenes de datos sobre una determinada variable que deseamos analizar. Su diseño presenta diferentes configuraciones, acorde con el resultado que genere, según la naturaleza, calidad y cantidad de datos utilizados en su confección. A continuación, veremos los resultados más comunes encontrados en los histogramas.

179

C8

Los datos indican una distribución normal. Se puede concluir que el proceso es estable.

Figura 96: Simétrico, forma de campana (normal)

Los datos están hacia la izquierda de la media. La distribución no es normal y el proceso debe ser investigado.

Figura 97: Diagrama (izquierda) negativo

Los datos están hacia la derecha de la media. La distribución no es normal y debe ser investigado.

Figura 98: Diagrama (derecho) positivo

Los datos pueden venir de dos procesos diferentes. Por ejemplo, es posible que datos de la opera-ción de día y de noche hayan sido combinados para formar el histograma.

Figura 99: Bimodal

100

50

0

250

200

150

300

350

100

50

0

250

200

150

300

350

100

50

0

250

200

150

300

350

180


8.3.1.15. Diagrama matricial (Matrix diagrams)

El diagrama matricial es una herramienta utilizada para identificar las relaciones que pudieran existir entre dos o más factores, sean problemas, causas y procesos, métodos y objetivos, o cualquier otro conjunto de variables. Una aplicación frecuente de este diagrama es el establecimiento de relaciones entre reque-rimientos del cliente y características de calidad del producto o servicio. Tiene las siguientes finalidades:

– Visualizar claramente los patrones de responsabilidad para que haya una distribución pareja y apropiada de las tareas.

– Ayudar al equipo a llegar a un consenso en relación a pequeñas decisiones, mejorando la calidad de, y el apoyo a, la decisión final.

– Mejorar la disciplina de un equipo en el proceso de observar minuciosamente un gran número de factores de decisión importantes.

Cómo se desarrolla un diagrama matricial

La confección del diagrama matricial se realiza básicamente a través de seis pasos:

– Definir el objetivo de la construcción del diagrama.

– Establecer el tipo de diagrama que será utilizado.

– Identificar los factores correspondientes a cada uno de los tipos implicados en el estudio.

– Dibujar el diagrama.

– Identificar y establecer la intensidad de las relaciones entre los factores de los diferentes tipos.

– Rotular el diagrama y añadir la información relevante.

Estos pasos serán ampliamente detallados a continuación:

PASO 1: Definir el objetivo de la construcción del diagrama:

Para empezar el proceso de desarrollo del diagrama matricial es necesario establecer el objetivo del estudio que será realizado para poder identificar los tipos de factores que deben intervenir en el análisis. La definición “tipo” se entiende como “un conjunto de factores que tienen una característica común para su agrupación” (por ejemplo: Tipo A: características del servicio, Tipo B: necesidades del cliente). Para que la herramienta pueda ser viable, el número de tipos implicados podrá ser como máximo cuatro.

PASO 2: Establecer el tipo de diagrama que será utilizado:

En función del resultado del paso anterior (número de tipos de factores implicados en el análisis), se elige el tipo de diagrama más adecuado. Son cinco los tipos más utilizados:

– Matriz tipo “L”.

– Matriz tipo “A”.

– Matriz tipo “T”.

– Matriz tipo “Y”.

– Matriz tipo “X”.

181

C8

MATRIZ TIPO “L”: Es la más básica de las cinco, y se utiliza para representar relaciones entre dos fac-tores distintos (“A” y “B”), mediante una disposición de columnas y filas. Ejemplo: En la columna de tipos “B” se pueden enumerar las “necesidades del cliente” y en la fila de tipos “A”, “características del servicio”.

Figura 100: Matriz tipo “L”

MATRIZ TIPO “A”: Es un caso particular de la matriz tipo “L”. Se utiliza básicamente para representar las relaciones entre los factores que componen un tipo determinado. Por ejemplo, el tipo “A”, “carac-terísticas del servicio”.

Figura 101: Matriz tipo “A”

MATRIZ TIPO “T”: Se trata de una combinación de 2 diagramas matriciales de tipo “L”. Su principal característica es la posibilidad de representar las relaciones entre 3 tipos de factores distintos (“A”, “B” y “C”, agrupándolos de la siguiente forma: Relaciones entre el tipo “A”, las “características del servicio” y el tipo “B”, “necesidades del cliente” o relaciones entre el tipo “A” “características del servicio” y un tercer tipo, el “C”, “características del servicio de la competencia”.

Figura 102: Matriz tipo “T”

a3

b6

...

...

b3

b4

b5

b2

b1

a1

B

a2 a4 a5 a6 ... ... ...

A

Aa1 a2 a3 a4 a5 ...a6

…..

a3

b1

…..

b4

b3

b2B

a2 a4 a5 …….

C

c1

c4

c3

c2

a1A

182


MATRIZ TIPO “Y”: Es la combinación de tres diagramas tipo “L”. Se utiliza básicamente para representar las relaciones entre tres tipos distintos (“A”, “B” y “C”), agrupándolos de una forma diferente al tipo “T”:

– Relaciones entre el tipo “A”, “características del servicio” y el tipo “B”, “necesidades del cliente”.

– Relaciones entre el tipo “B”, “necesidades del cliente” y el tipo “C”, “características del servicio de la competencia”.

– Relaciones entre el tipo “C” “características del servicio de la competencia”. y el tipo “A”, “carac-terísticas del servicio”.

Figura 103: Matriz tipo “Y”

MATRIZ TIPO “X”: Es la combinación de 4 diagramas tipo “L”. Se utiliza básicamente para represen-tar, de esta vez, las relaciones entre cuatro tipos distintos (“A”, “B”, “C” y “D”):

– Relaciones entre el tipo “A”, “características del servicio” y el tipo “B”, “necesidades del cliente”.

– Relaciones entre el tipo “B”, “necesidades del cliente” y el tipo “C”, “características del servicio de la competencia”.

– Relaciones entre el tipo “C”, “características del servicio de la competencia” y el tipo “D”, “precio”.

– Relaciones entre el tipo “D”, “precio” y el tipo “A”, “características del servicio”.

Figura 104: Matriz tipo “X”

…..

a3

b1

…..

b4

b3

b2

a2 a4 a5

d1

d4

d3

d2

a1c3c4 c2 c1c5

b1

B

C A

D

183

C8

PASO 3: Identificar los factores correspondientes a cada uno de los tipos implicados en el estudio:

La identificación de los factores integrantes de cada tipo puede ser realizada a través de una herra-mienta auxiliar de toma de datos, como por ejemplo:

– Tormenta de Ideas: Descrita en la sección 11.2.1.8;

– Entrevistas: Descrita en la sección 5.1.1.1;

– Técnica Delphi: Descrita en la sección 6.4.1.7;

– Juicio de Expertos: Descrita en la sección 4.1.1.1.

PASO 4: Dibujar el diagrama

El diagrama será confeccionado según el modelo elegido y acorde con la necesidad y el tipo y numero de factores que serán analizados. Tomaremos como ejemplo, la confección de un diagrama de tipo “L”, que deberá cumplir con los siguientes requisitos:

– Establecer los tipos que serán representados en las respectivas columnas y filas;

– Dibujar tantas filas y columnas como factores tengan los tipos correspondientes, añadiéndoles un espacio para cada tipo;

– Rotular los factores pertenecientes a cada tipo en las filas y columnas.

Un buen entendimiento del diagrama exigirá que los rótulos elegidos sean claros y autoexplicativos.

Modelo de radio

PC1 PC2 PC3 PC4 PC5 PC6

Defe

cto

Memoria

Disco duro

Procesador

Altavoces

Teclado

Figura 105: Diagrama matricial en “L” de un ordenador personal

PASO 5: Identificar y establecer la intensidad de las relaciones entre los factores de los diferentes tipos

Este es un paso fundamental para extraer la información precisa del diagrama matricial. Este paso se ejecuta básicamente en cuatro acciones:

Primero, se toma el primer elemento de las filas y se repasa cada uno de los elementos de las colum-nas, identificando todos los que están relacionados con aquél.

Se determina la intensidad de la relación entre los factores. Para ello, se pueden utilizar las mismas herramientas mencionadas el paso 3.

184


Se utilizan símbolos para representar las escalas de intensidad, que son establecidas con un míni-mo de dos niveles y un máximo de 4. Las escalas más comúnmente utilizadas internacionalmente son las siguientes:

Figura 106: Símbolos de intensidad

Distribuir los símbolos de intensidad en las casillas correspondientes:

Modelo de radio


Defe

cto

Memoria •

Disco duro •

Procesador

Altavoces •

Teclado • • •

Figura 107: Diagrama matricial en “L” completo

PASO 6: Rotular el diagrama y añadir la información relevante

Para finalizar el diagrama, se añaden informaciones complementares de identificación (título, leyenda y/o cualquier otra información considerada oportuna), para facilitar su entendimiento por cualquiera de los implicados en el proyecto.

*Nota del autor: Observaciones generales con respecto a algunas deficiencias que esta herramienta puede presentar:

La confección de un diagrama matricial se realiza, basándose normalmente en datos subjetivos, como por ejemplo, la opinión de expertos o entrevistas con profesionales veteranos. Esto da lugar a la deficiencia más habitual en su interpretación: confundir esta disposición de las relaciones y su intensidad con los datos reales, sin una comprobación empírica previa.

El diagrama matricial debe ser utilizado, por lo tanto, como un guía en el análisis del tema en estudio y es necesario comprobar la exactitud de las ideas que de su interpretación se obtengan.

Las causas posibles de inexactitudes en la asignación de intensidades a las relaciones serán:

– El uso de datos obsoletos.

– Evaluación tendenciosa de expertos (visión subjetiva, desconocimiento parcial del tema, entre otros).

– Evaluaciones superficiales sin contar con expertos.

Otra de las principales causas de deficiencias en la interpretación del diagrama matricial es la falta de elementos o factores clave en el análisis del tema en estudio. En general, este hecho se produce por la deficiente utilización de las herramientas utilizadas para su identificación.

INTENSIDAD SIMBOLO

Muy fuerte

Fuerte

Débil

Inexistente

INTENSIDAD SIMBOLO

Fuerte

Débil

Inexistente

INTENSIDAD SIMBOLO

Existente

Inexistente

185

C8

Modelo de radio


Defe

cto

Memoria •

Disco duro •

Procesador

Altavoces •

Teclado • • •

• = Relación fuerte = Relación débil

Las evaluaciones se basan en los datos de todas las reparaciones efectuadas en el taller de reparación en un mes.

Figura 108: Diagrama matricial con elementos explicativos

8.3.1.16. Matriz de priorización (Prioritization matrix)

La matriz de priorización es una técnica muy utilizada cuando es necesario priorizar problemas u ob-tener un consenso acerca de una determinada cuestión. Sus resultados permiten ver con claridad cuáles son los problemas más importantes sobres los que se debe trabajar primero. Esta técnica se elabora de la siguiente forma:

– Se lleva a cabo una tormenta de ideas (véase también sección 11.2.1.8) sobre los problemas detectados en el proyecto.

– Se cumplimenta la matriz de priorización, conforme ilustra la figura 109. En la primera columna se ponen los problemas detectados en la tormenta de ideas. De la segunda a la cuarta columna se establecen los criterios, que pueden ser: frecuencia, importancia, factibilidad, probabilidad, impacto, costes... Los criterios son libres y si bien existe un número ilimitado de criterios, tres o cuatro es la cantidad recomendada para confeccionar correctamente una matriz.

– Los problemas deberán ser priorizados, de acuerdo con la suma de los puntos presentada en la matriz.

Problema Frecuencia Importancia Factibilidad Puntos

X 10 10 50 70

Y 15 5 35 55

Z 5 10 20 35

Figura 109: Matriz de priorización básica

186


C9Dirección de RRHH

188


9.1. Desarrollo de los recursos humanos (proceso que corresponde a la fase de planificación del proyecto)9.1.1. Técnicas y herramientas

9.2. Adquisición de personal (proceso que corresponde a la fase de ejecución del proyecto)9.2.1. Técnicas y herramientas

9.3. Desarrollo del equipo (proceso que corresponde a la fase de ejecución del proyecto)9.3.1. Técnicas y herramientas

9.4. Gestión del equipo (proceso que corresponde a la fase de ejecución del proyecto)9.4.1. Técnicas y herramientas

189

Algunas cosas en las que NO puedes pensar acerca de la dirección de RRHH

“No tenemos tiempo para dar formaciones al equipo. Ya irán aprendiendo sobre la marcha”

Una importante cantidad de proyectos fracasan a un ritmo impresionante, casi en la mitad de los ca-sos, según algunas estimaciones. Curiosamente, un gran número de empresas que han pasado por la mala experiencia de asumir el fracaso de un proyecto, contaban con los procedimientos y la docu-mentación adecuada, y además, tenían una estructura apropiada, además de estar económicamente preparadas para afrontar un gran proyecto. Uno de los factores clave del fracaso de un proyecto es la falta de formación adecuada. Desde de la antigüedad, la capacitación de todos los eslabones que forman un emprendimiento ha sido condición necesaria para que la misma pueda sacar el máximo rendimiento de sus proyectos y para que encuentre su camino hacia la excelencia.

“No pierdas tiempo con un proceso selectivo que nos costará tiempo y dinero. Tengo un primo que está en el paro y seguro que sirve para el puesto”

Desconozco el currículo del primo del autor de esta frase, pero si hay un factor que determina el éxito o el fracaso de un proyecto es la capacidad profesional y las habilidades de cada una de las personas in-volucradas. El PMDCF (Project Manager competency development framework) es una guía publicada por el PMI que establece, entre otras cosas, las tres dimensiones básicas para el desarrollo correcto de las competencias de un Project Manager, y por qué no decirlo, de cualquier profesional asignado a un proyecto. Estas dimensiones se dividen en “conocimiento” (se refiere al conocimiento que el profesional debe poseer con respecto a la aplicación de los procesos, herramientas y técnicas en las actividades del proyecto), “desempeño” (se refiere a como un profesional debe emplear su conocimiento para conseguir los requisitos u objetivos del proyecto) y “comportamiento” (se refiere a como un profesional se comporta ante un determinado contexto o ambiente de proyecto). Formar parte de un proyecto con-lleva asumir unas responsabilidades que requieren la correcta selección de profesionales capacitados.

Introducción

Cada proyecto tiene características propias que demandarán profesionales de diferentes áreas. Hay proyectos que necesitan un equipo muy grande y hay otros que pueden ser ejecutados con un grupo de profesionales más limitado. Conseguir el personal adecuado, decidir qué hacer con el equipo tras la conclusión del proyecto y, sobre todo, cómo distribuir correctamente el tiempo de cada profesional en diferentes proyectos simultáneos, son los grandes desafíos que implican la dirección de RRHH.

Definitivamente, un proyecto no se resume solamente en su alcance, los plazos y los costes asignados para ponerlo en marcha. Uno de los factores clave más importantes para el éxito de un proyecto es tener a disposición las personas adecuadas en los momentos oportunos, que es sin duda, una combi-nación muy difícil de obtener. Es una fórmula que el Project Manager intentará buscar constantemente.

190


En muchas empresas, algunos recursos son asignados a un proyecto sobre todo porque están dis-ponibles y no porque son la mejor elección. Realmente, un equipo debería ser montado solamente cuando se haya conocidos los requisitos técnicos del proyecto. De esta forma, es más fácil escoger el perfil del profesional adecuado. No obstante, las empresas normalmente no pueden darse el lujo de contar con una plantilla muy amplia. Lo más común es asignar el mismo profesional a muchos proyec-tos a la vez. La regla general normalmente es: se asigna quien esté disponible.

La asignación de profesionales para un proyecto es una de las preocupaciones más importantes de un Project Manager. El alma del proyecto son las personas que lo desarrollan. Cada trozo de un pro-yecto lleva la “firma” de sus ejecutores, y esta es una de las muchas razones por las cuales es muy importante poder contar con los recursos adecuados.

Un proyecto según lo definido en el capítulo 1, “es realizado por personas”. Puede ser desarrollado por una única persona o por todo un departamento. Puede involucrar una pequeña oficina o pueden cruzar fronteras afectando a decenas de multinacionales. Además, un proyecto es afectado por una serie de agentes internos y externos que ejercen a todo momento, de una forma u de otra, su influen-cia sobre él, pudiendo incluso, impactar negativa o positivamente en sus resultados.

Figura 110: Los interesados de un proyecto

Todas las personas involucradas, directa o indirectamente en el proyecto son llamados “interesados” (en inglés, stakeholders). Un interesado se caracteriza principalmente en función de su influencia o participación en el proyecto, como por ejemplo:

– Asumir pérdidas o ganancias acorde con el resultado final.

– Proveer fondos al proyecto.

– Invertir recursos humanos o infraestructura.

– Participar activamente en los procesos de planificación, control y ejecución.

Tal y como ilustra la figura 110, los interesados tanto pueden ser personas como pueden ser departa-mentos o empresas. El Project Manager, además de controlar la ejecución del proyecto y hacer con que las actividades avancen según el plan establecido, deberá tener la capacidad de gestionar las expectativas de los interesados del proyecto. Muchos de ellos se relacionan entre sí, y normalmente ocurren conflictos que pueden ser de todo tipo: filosóficos, culturales, profesionales, personales, ad-ministrativos, políticos, etcétera. Los Interesados pueden además tener diferentes prioridades, formas distintas de trabajar, o incluso formas diferentes de enfrentar un riesgo. El Project Manager necesitará, por lo tanto, buscar constantemente un punto de equilibrio que logre mantener una constante armonía en las relaciones establecidas durante el desarrollo del proyecto.

191

C9

El equipo del proyecto

El equipo del proyecto se define como un grupo de personas de conocimientos diversos, que se complementan en función del proyecto, y donde se les asignan responsabilidades y objetivos con-cretos. Para que su trabajo en equipo funcione eficazmente, sus esfuerzos individuales necesitan coordinación, como un equipo de fútbol, donde esta coordinación es realizada por el entrenador que dedica horas de entrenamientos, formaciones tácticas y jugadas ensayadas.

Algunos integrantes del equipo trabajan en momentos muy puntuales del proyecto, otros estarán pre-sentes desde el comienzo hasta el cierre de los trabajos. Generalmente, es formado por los emplea-dos de la empresa encargada de la ejecución del proyecto, pero también podrá incluir profesionales de otras empresas y en muchos casos algún representante del cliente.

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección de RRHH de un proyecto incluye pro-cesos y actividades necesarios para organizar, gestionar y conducir el equipo del proyecto. Son ellos:

– Desarrollar el plan de recursos humanos.

– Adquirir el equipo del proyecto.

– Desarrollar el equipo del proyecto.

– Dirigir el equipo del proyecto.

9.1. Desarrollo de los recursos humanos (proceso que corresponde a la fase de planificación del proyecto)

Acorde con el PMBOK®, el desarrollo de los recursos humanos es el proceso por el cual se identifi-can y documentan los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación, y se crea el plan para la dirección de personal. La planificación de los recursos humanos se utiliza para determinar e identificar aquellos recursos humanos que posean las habilidades requeridas para el éxito del proyecto. El plan de recursos humanos documenta los ro-les y responsabilidades dentro del proyecto, los organigramas y el plan para la dirección de personal, incluyendo el cronograma para la adquisición y posterior liberación del mano de obra. También puede incluir la identificación de necesidades de capacitación, las estrategias para fomentar el espíritu de equipo, los planes de reconocimiento y los programas de recompensas, las consideraciones en torno al cumplimiento, los asuntos relacionados con la seguridad y el impacto del plan para la dirección de personal a nivel de la organización.


9.1.1.1. Organigramas (Organization charts)

Es una representación gráfica de la estructura de una organización que permite de forma muy sencilla y visual distinguir las estructuras departamentales y en algunos casos, las personas que las dirigen, haciendo un esquema sobre las relaciones jerárquicas en vigor en la organización. Se compone a través de rectángulos que representan los departamentos y puestos ocupados por cada integrante de la organización. La unión de estos rectángulos es representada por líneas que determinan los canales de la jerarquía.

192


Figura 111: Organigrama

El organigrama no debe contener toda la información necesaria para conocer como es la estructura de una empresa, no obstante debe cumplir los siguientes requisitos:

– Ser fácil de entender y sencilla de utilizar.

– Contener únicamente los elementos indispensables.

El diseño de un organigrama es libre, pero existen diferentes tipos que reúnen algunas características especiales:

– Organigrama vertical: Muestra las jerarquías según una pirámide, de arriba abajo.

– Organigrama horizontal: Muestra las jerarquías de izquierda a derecha.

– Organigrama mixto: Es una combinación entre el horizontal y el vertical.

– Organigrama circular: La autoridad máxima está en el centro, alrededor de él se forman círculos concéntricos donde se nombran a los jefes inmediatos.

– Organigrama escalar: Se usan sangrías para señalar la autoridad, cuanta mayor es la sangría, menor es la autoridad de ese cargo.

9.1.1.2. Relaciones de Trabajo o Redes Sociales (Networking)

Según el sociólogo francés Joseph Folliet, en su obra, El hombre Social - Ensayo de Antropología Social, “por lejos que nos remontemos en el pasado histórico, lo encontramos (al hombre) siempre viviendo en sociedad”. Es decir, desde tiempos muy remotos, el hombre se dio cuenta que no lograría supervivir en un mundo hostil si no se aliara a sus semejantes. Desde entonces, y durante toda la evolución del hombre hasta los días actuales, nos hemos encontrado con la necesidad de vivir en so-ciedad. La “técnica” de reunir un grupo de personas para actuar en conjunto con el objetivo de lograr un objetivo común, ha recibido el nombre de networking.

Entre otros factores, ha sido el networking que ha posibilitado a la humanidad de avanzar y progresar a través de los siglos. Para poner un ejemplo histórico, Cristóbal Colón solo ha podido llevar adelante su plan de crear una nueva ruta hacia las indias por el océano Atlántico, porque había logrado, a través de su red de contactos, acceder a los Reyes Católicos (Fernando II de Aragón e Isabel I de Castilla), que aportaron los fondos necesarios para poner en marcha su proyecto, que culminaría posteriormente con el descubrimiento de un nuevo continente.

El proyecto de Colón no es distinto de un proyecto empresarial, puesto que contempla una serie de riesgos, de restricciones financieras, de cumplimiento de plazos y depende, sobre todo, del apoyo de un grupo de interesados.

193

C9

En la actualidad principalmente la calidad de la red social de una persona, que le posibilitará transfor-mar buenas oportunidades en grandes proyectos.

Las redes sociales son de lo más fuerte que hay en internet actualmente y es un fenómeno que se debe gracias al poder de comunicación que la internet puede proporcionar. En ellas podemos compar-tir opiniones, fotos, videos y una infinidad de información a nuestra red de contactos. Las redes socia-les más populares en internet son el Facebook, el Twitter y el Hi5, además de los blogs y de los foros.

9.1.1.3. Matriz de responsabilidades (Responsibility assignment matrix – RAM)

Delegar es una de las acciones primarias de un Project Manager y, para hacerlo de forma adecuada, es importante identificar los roles y responsabilidades del proyecto lo antes posible. Para ello, se utiliza la matriz de responsabilidades (responsabilitiy assignment matrix – RAM, también conocida como RACCI – sigla que significa las atribuciones: responsible, countable, consulted, informed), es decir:

Rol Descripción

R Responsible Responsable

Este rol realiza el trabajo y es responsable por su realiza-ción. Lo más habitual es que exista solo un R, si existe más de uno, entonces el trabajo debería ser subdividido a un nivel más bajo, usando para ello las matrices RASCI. Es quien debe ejecutar las tareas.

A Accountable Aprobador

Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve responsable por él. Solo pue-de existir un A por cada tarea. Es quien debe asegurar que se ejecutan las tareas.

C Consulted ConsultadoEste rol posee alguna información o capacidad necesa-ria para terminar el trabajo. Se le informa y se le consulta información (comunicación bidireccional).

I Informed InformadoEste rol debe ser informado sobre el progreso y los re-sultados del trabajo. A diferencia del consultado, la co-municación es unidireccional.

Figura 112: Matriz RACI

También existe la matriz RASCI, que es una variación de la RACI. La única diferencia es la adición de un nuevo rol: el de soporte.

Rol Descripción

s Supportive Soporte Este rol proporciona recursos adicionales para realizar el trabajo.

Figura 113: Matriz RASCI

En la matriz RACI o en la RASCI, se asignan el rol que cada recurso deberá ejecutar para cada acti-vidad del proyecto. No es necesario incluir los cuatro o cinco roles en la misma actividad, pero estas deberían contar con por lo menos el de encargado y responsable.

194


Esta herramienta se utiliza muy frecuentemente en conjunto con la EDT (Véase también sección 5.3), donde se recogen las actividades identificadas del proyecto, y a través de la RACI se complementa con los recursos asignados.

*Nota del autor: Existe una infinidad de herramientas similares que agregan nuevos roles, las más comunes son:

RACI-VS o VARISC

Al igual que la RASCI, es una variación de la RACI. Los roles adicionales son:

Rol Descripción

V Verify VerificadorEste rol se encarga de comprobar si el producto es acorde a los criterios de aceptación establecidos en la descripción del producto.

S Sign FirmanteEste rol aprueba las decisiones de V y autorizan la salida del producto. Lo lógico es que el trabajo de un S preceda siempre al de un A.

Figura 114: Matriz VARISC

RACIO

Esta es una versión ampliada, basada en el estándar RACI, con un tipo de participación adicional.

Rol Descripción

O Omitted OmitidoEstablece los individuos o grupos que no forman parte de la tarea. Es-pecificar que un recurso no participa puede ser tan beneficioso para la finalización de una tarea como especificar aquellos que lo reciben.

Figura 115: Matriz RACIO

RSI

Es la variación utilizada por el PMI - Project Management Institute

Rol Descripción

R Responsible ResponsableSon los encargados de ejecutar la actividad. Tiene la responsabilidad de finalizar la tarea según el alcance definido, obedeciendo los plazos y cos-tes establecidos. También tienen poderes de toma de decisión.

S Sponsor PatrocinadorEs el propietario del proyecto o de la actividad. Es el rol encargado de firmar la aceptación de la actividad una vez que esté finalizada.

I Informed InformadoSon roles que no participan directamente, pero que necesitan estar in-formados acerca de la evolución de las actividades y/o del proyecto como un todo.

Figura 116: Matriz RSI

Otras variaciones de matriz de responsabilidades:

– DACI: Versión más utilizada para centralizar la toma de decisiones y aclarar los roles que pueden levantar cuestiones acerca del proyecto. Incluye los siguientes roles: conductor (driver), aprobador (approver), contribuyente (contributor) e informado (informed).

– PARIS: Incluye los roles: primario (primary) que es básicamente el responsable por la actividad, asignado (assigned), revisión necesaria (review required), entrada requerida (input required) y firma requerida (signature required).

– OARP: Al igual que con los otros modelos, este modelo se utiliza para la designación de roles en el proceso de toma de decisiones. Incluye el propietario (owner), aprobador (approver), crítico (reviewer) y participante (participant).

195

C9

9.1.1.4. Estructura de desglose de la organización – EDO (Organization breakdown structure – OBS)

La estructura de desglose de la organización es una descripción jerárquica de la organización del proyecto, como si de un organigrama se tratara.

No obstante, su función es potencializada cuando sus datos son combinados con los paquetes del trabajo establecidos en la estructura detallada de trabajo – EDT (véase también sección 5.3) y con las unidades ejecutantes de la organización que se encuentran en la matriz de responsabilidades (véase también la siguiente sección).

En otras palabras, se utilizada la EDO de la siguiente forma:

– Para combinar la EDT, la RAM y la EDO, es fundamental que todo el alcance previsto en la EDT esté completamente establecido y aprobado por la dirección.

– Se coge entonces la EDO de la organización, y a través de la RAM, se define quienes serán los encargados de cada actividad de la EDT y cuáles serán sus roles y responsabilidades.

– Es importante además consultar el calendario de la organización para certificarse de que los re-cursos de la EDO estarán disponibles para el proyecto.

– Definida la EDT y la RAM y conociendo cuáles serán los recursos disponibles, es posible combi-nar sus datos y entonces, empezar el desarrollo del diagrama de red del proyecto (véase también sección 6.2.1.1), que servirá de base para confeccionar el cronograma del proyecto.

Figura 117: Relación entre EDT, EDO y RAM

9.2. Adquisición de personal (proceso que corresponde a la fase de ejecución del proyecto)

El éxito de un proyecto depende mucho de la capacidad y de las habilidades del Project Manager y su equipo. Cuando nos encontramos en la fase de adquisición de personal no podemos limitarnos a realizar una selección considerando solamente el conocimiento técnico necesario para llevar a cabo las actividades del proyecto. Es importante que exista una química favorable entre el Project Manager y su equipo, y principalmente entre los propios miembros del equipo. Poder contar con gente que, además de poseer los conocimientos adecuados, estén motivados y tengan ganas de trabajar en equipo, estimularán la unión, la sinergia y la armonía.

En algunos casos, el Project Manager podrá equivocarse a la hora de elegir los integrantes de su equipo, pero esto es uno de los riesgos que deberán ser considerados.

EDT

EDO

RAM

A

D

B

E

C

F

inicio fin

196


Normalmente, un equipo de proyecto está estructurado por tres componentes:

– El Project Manager.

– El líder técnico.

– El equipo de la plantilla.

– El equipo subcontratado.

El Project Manager

Es el líder del proyecto. Es el responsable de hacer cumplir los plazos planificados, los costes asigna-dos en el presupuesto y el alcance de acuerdo con las especificaciones establecidas. Es el Project Manager quien representa el proyecto para la organización y para el cliente.

¿Cuál es el momento adecuado de elegir el Project Manager?

No hay una regla sobre el momento adecuado para elegir el Project Manager. Naturalmente, esta elección deberá ocurrir en el momento que se publica el acta de constitución del proyecto. Normal-mente, el Project Manager no es asignado hasta que el proyecto es aprobado por la organización. Por regla general, y según algunos autores, el momento más adecuado para la entrada de un Project Ma-nager en un proyecto es inmediatamente después de la firma del contrato entre el cliente y la empresa adjudicataria del proyecto. Cuanto más temprano esté involucrado, mayores serán las posibilidades de ejecutar el proyecto con más seguridad. Esto también vale para otros integrantes cuya experiencia pueda ser muy útil en la fase inicial de planificación del proyecto. Todo conocimiento que se puede aportar en la fase de planificación será muy beneficioso para las fases a continuación

El equipo de la plantilla

Son los que realmente ejecutarán el proyecto, tendrán que tomar decisiones importantes (sobre todo técnicas) y tendrán la difícil misión de cumplir los planes establecidos.

¿Cuando se eligen los integrantes del equipo del proyecto?

Dependerá del papel que cada integrante tendrá en el proyecto y también en qué fase del proyecto participarán. En el caso de la construcción de un edificio, el pintor empezará a actuar, por ejemplo, en la fase final. Por otro lado, el personal de excavaciones entrará en el comienzo. Ingenieros, y apare-jadores serán asignados antes de la fase de ejecución de las obras, puesto que sus conocimientos serán muy útiles a la hora de estimar plazos y actividades.

Como en el caso del Project Manager, los integrantes de un proyecto pueden estar asignados a más de un proyecto simultáneamente, fraccionando sus tiempos de trabajo. Por ejemplo: 25% en el pro-yecto “A”, 50% en el proyecto “B” y 25% en el proyecto “C”. Mientras este trabajador no termine sus trabajos en unos de estos tres proyectos, no podrá ser asignado a ningún otro más. Es importante establecer una sincronía entre los cronogramas en que un mismo integrante este adjudicado, para evitar que este su tiempo disponible se solape.

El equipo subcontratado

Actualmente las empresas están subcontratando mucha mano de obra externa para la ejecución de sus proyectos. Es una forma efectiva de reducción de costes y también de riesgos. En muchos casos se trata de profesionales muy especializados que se incorporan al equipo en el momento en que las actividades por las cuales fueron asignados empiezan. Al finalizarlas, ellos dejan el proyecto y retornan a sus empresas.

197

C9

Implicaciones en utilizar recursos subcontratados en un proyecto

Como comentado anteriormente, la subcontratación de mano de obra conlleva a asumir una serie de riesgos que deberán ser considerados:

– El cronograma no podrá sufrir muchas variaciones en los plazos, pues es posible que el recurso contratado no este disponible.

– Su compromiso a veces no corresponde a las expectativas del Project Manager, pues en mu-chos casos este tipo de recurso tiene otras prioridades. Este factor puede influir directamente en la calidad de su trabajo.

– Como en muchos casos el recurso subcontratado no suele acompañar toda la evolución del proyecto es necesario dedicar un tiempo importante para situarle en el estado actual de los trabajos realizados.


9.2.1.1. Asignación previa (Pre–assignment)

Existen proyectos que, por su naturaleza, demandan una promesa de recursos humanos previa a su aprobación, como puede pasar en los siguientes casos:

– Licitaciones públicas cuyo concurso exige que la empresa participante ya cuente con un grupo de profesionales contratado.

– El proyecto tiene un objetivo tan específico, que necesita de la experiencia de determinados pro-fesionales extremadamente especializados (por ejemplo, el estudio de una vacuna, o la moderni-zación de toda red de telefonía de un país).

En casos como los anteriormente descritos, la organización tendrá que anticipar todo el proceso de selección, para de esta forma asegurar al contratante de que dispone de toda la plantilla necesaria para su puesta en marcha. La asignación previa es una técnica que tiene un cierto grado de riesgo, puesto que proyectos como los que demandan un alto nivel tecnológico, necesitan de presupuestos muy elevados, y por ello, pueden tardar meses en empezar, o incluso no llegar a llevarse a cabo.

9.2.1.2. Negociación (Negotiation)

En muchos proyectos, las asignaciones de personal se negocian. Por ejemplo, el equipo de dirección del proyecto podría necesitar negociar con:

– Gerentes funcionales, para asegurar que el proyecto reciba personal con las competencias apro-piadas dentro del plazo necesario y que los miembros del equipo del proyecto cuenten con la capacidad, disposición y autorización necesarias para trabajar en el proyecto hasta completar sus responsabilidades.

– Otros equipos de dirección del proyecto dentro de la organización ejecutante a fin de asignar de forma adecuada recursos humanos escasos o especializados.

– Organizaciones externas, vendedores, proveedores, contratistas, entre otras, para obtener re-cursos humanos adecuados, escasos, especializados, calificados, certificados o de otro tipo específico. Deberá prestarse especial atención a las políticas, prácticas, procesos, pautas, dis-posiciones legales y a otros criterios de negociación externos.

198


La capacidad del equipo de dirección del proyecto de influir en otras personas desempeña un papel importante en la negociación de asignaciones de personal, del mismo modo que las políticas de las organizaciones implicadas. Por ejemplo, un gerente funcional evaluará los beneficios y la visibilidad de proyectos que compiten, a la hora de determinar a dónde asignar a las personas con un excelente desempeño, que son requeridas por diferentes equipos del proyecto.

9.2.1.3. Adquisición (Adquisition)

Cuando la organización ejecutante no cuenta con el personal interno necesario para completar un pro-yecto, los servicios requeridos pueden adquirirse de fuentes externas. Esto puede implicar contratar consultores individuales o subcontratar trabajo a otra organización.

9.2.1.4. Equipos virtuales (Virtual teams)

El uso de equipos virtuales crea nuevas posibilidades a la hora de adquirir a los miembros del equipo del proyecto. Los equipos virtuales pueden definirse como grupos de personas con un objetivo co-mún, que cumplen con sus respectivos roles pasando poco o nada de tiempo en reuniones cara a cara. La disponibilidad de medios de comunicación electrónica como el correo electrónico, las audio conferencias, los encuentros por internet y las videoconferencias, ha hecho posible la existencia de estos equipos.

El formato de equipo virtual permite:

– Formar equipos de personas de la misma empresa que viven en áreas geográficas dispersas.

– Aportar experiencia especial a un equipo del proyecto, incluso si el experto no se encuentra en la misma área geográfica.

– Incorporar empleados que trabajan desde oficinas instaladas en sus domicilios.

– Formar equipos de personas que trabajan en diferentes turnos u horarios.

– Incluir personas con limitaciones de movilidad o discapacidades.

– Avanzar en proyectos que habrían sido descartados debido a los gastos de desplazamiento.

La planificación de las comunicaciones adquiere una importancia cada vez mayor en el entorno de un equipo virtual. Puede ser necesario dedicar tiempo adicional para establecer expectativas claras, facilitar las comunicaciones, desarrollar protocolos para la resolución de conflictos, incluir personas en la toma de decisiones y compartir los méritos del éxito.

9.3. Desarrollo del equipo (proceso que corresponde a la fase de ejecución del proyecto)

Formar un equipo de proyecto no se limita tan solamente a asignar un grupo de personas a determina-das tareas. Un equipo de proyectos es un grupo especializado, que asume el compromiso de realizar su trabajo correctamente y son capaces de aportar valor al proyecto.

Una de mayores preocupaciones de un Project Manager es la preparación de su equipo. El éxito o fracaso de un proyecto puede tener como factor principal el nivel de preparo del equipo ejecutor. El de-sarrollo del equipo es actualmente un gran desafío que consiste en transformar un conjunto de personas en un equipo profesional que sepa responder a las demandas del proyecto y sobre todo de sus clientes.

199

C9

Una vez que el equipo este formado, es importante definir los procedimientos y compromisos que nortean el proyecto. Estableciendo estos elementos, el Project Manager deberá asegurarse de que el equipo conoce:

– Los objetivos del proyecto y de cada objetivo individual.

– El papel y compromiso de cada integrante.

– Las herramientas y recursos disponibles.

– La relación que los integrantes mantendrán entre si durante el desarrollo del proyecto.


9.3.1.1. Teoría de Tuckman (Tuckman theory)

Bruce Wayne Tuckman es un psicólogo estadounidense que estudió en profundidad el comporta-miento de los grupos. Su obra más importante, publicada en 1965, se titula Desarrollo secuencial en grupos pequeños y es un modelo que llegó a ser muy influyente en la teoría de desarrollo de grupos. Este modelo se divide en cinco etapas:

– Formación (Forming).

– Enfrentamiento (Storming).

– Normalización (Norming).

– Desempeño (Performing).

– Disolución (Adjourning).

Esta teoría es interesante porque encaja perfectamente en lo que se refiere al desarrollo de un equipo en un proyecto. Normalmente, los integrantes de un equipo provienen de diferentes departamentos de la empresa y son reunidos única y exclusivamente para la ejecución de un determinado proyecto. Una vez que finalizado, el grupo es disuelto y sus integrantes regresan a su departamento de origen, donde siguen desarrollando sus labores diarias, hasta que sean convocados para formar parte de un nuevo proyecto.

– Formación (Forming): Fase de iniciación del equipo de proyecto: Si aplicamos la teoría de Tuckman, veremos que en la etapa de formación, los integrantes del equipo no se conocen y no tienen claro todavía los objetivos del proyecto. Cada integrante trae consigo un cierto grado de incertidumbre y es natural que se sientan todavía inseguros en relación a lo que le puede venir por delante. Es una fase en que cada uno adopta una postura neutral, evitando cualquier conflicto, asumiendo una postura pasiva.

– El Project Manager debe realizar una serie de entrevistas con cada integrante del equipo para identificar las expectativas que cada uno tiene con el grupo y con el proyecto con lo cual ha sido asignado. Es el momento para establecer con el grupo las “reglas del juego” (ground rules). Se trata de una lista de comportamientos aceptables e inaceptables adoptados por el equipo de proyecto para mejorar la relación de trabajo, efectividad y la comunicación. Estas reglas deben ser expuestas, compartidas y aceptadas por el equipo.

– Enfrentamiento (Storming): Fase en que las ideas compiten, a veces de forma agresiva, para que se lleven en cuenta. Una vez superada la fase inicial, el equipo empezará a trabajar en un ambiente que se espera, sea armónico. No obstante, eventuales conflictos son inevitables. Cada persona es dotada de una personalidad y expectativas diferentes y consecuentemente los obje-

200


tivos de cada uno se verán muchas veces enfrentados. El Project Manager tendrá que intentar conducir el equipo hacia la misma dirección, y para ello, tendrá que asumir un papel activo de negociación para que de alguna forma, todos los integrantes puedan llegar a un acuerdo que les permita seguir sin percances. Para ello, las reglas del juego establecidas en el punto anterior, serán de gran valía.

– Normalización (Norming): Una vez superadas las fases anteriores, lo más probable es que los integrantes del equipo empiecen a confiar unos en los otros y en el grupo como un todo. Depen-diendo del grado de madurez del grupo, será posible incluso disfrutar de alguna autonomía en la toma de decisiones, rompiendo un poco la dependencia que a veces tienen del Project Manager.

– Desempeño (Performing): En esta fase, el equipo del proyecto ha alcanzado la madurez nece-saria para funcionar como una unidad. El grupo es plenamente capaz de hacer que el trabajo sea realizado de forma fluida y con eficacia, sin conflictos inadecuados o necesidad de supervisión externa. El grado de interferencia del Project Manager disminuye sensiblemente y los buenos resultados se hacen notar en poco tiempo. No obstante, no es común alcanzar este nivel de des-empeño, el grupo depende totalmente de la capacidad de cada uno de los integrantes y sobre todo de la buena voluntad de resolver conflictos. Cuando el grupo alcanza este tipo nivel de toma de decisión, el Project Manager tiene la posibilidad de fomentar la “potenciación” del equipo.

– Potenciación (Empowerment): Significa dar libertad a un empleado para que tome decisiones asumiendo su propio nivel de riesgo. Esto es la actitud que un Project Manager tiene cuando existe una relación de plena confianza con su equipo. Por lo tanto dar poder a los empleados es básicamente: establecer una relación de confianza, darles libertar de toma de decisiones, adquirir experiencia propia y legitimar la asunción de riesgos.

– Disolución (Adjourning): Cuando el proyecto termina, el grupo se deshace. La satisfacción de haber logrado terminar el proyecto muchas veces se ve empañada por el “sentimiento de pérdida” que los integrantes sienten por tener que abandonar el equipo (o a veces, sucede lo contrario). Los integrantes del equipo vuelven a sus departamentos de origen, para cuidar de sus labores diarias. Ha llegado el momento del Project Manager realizar las evaluaciones de los integrantes, cuyos resultados, muchas veces, son encaminados a los superiores directos de cada integrante del equipo del proyecto. Si los resultados han sido satisfactorios, este mismo equipo podrá ser convocado para asumir proyectos similares.

9.3.1.2. Habilidades interpersonales (Interpersonal skills)

Las habilidades interpersonales son aquellas que te permiten tener una mejor comunicación con otras personas. Los profesionales con estas habilidades colaboran a mejorar las relaciones entre el equipo y entablar relaciones duraderas, proporcionando al proyecto una fluidez en las comunicaciones y un intercambio de mensajes claros y eficientes, lo que contribuye al proyecto una reducción importante de errores y consecuentemente de riesgo.

Para potenciar tus habilidades interpersonales en el trabajo debes tener en cuenta lo siguiente:

– Centrarse en la conversación.

– Mostrar disposición.

– Superar la timidez.

Las personas hábiles para relacionarse en el trabajo observan a los demás, se comunican con ellos y fomentan el establecimiento de relaciones. Entablan amistad en reuniones cortas y encuentran posi-bilidades donde parece no haberlas.

201

C9

9.3.1.3. Formación (Training)

La capacitación ha sido, desde siempre, una de las condiciones necesarias para una empresa sacar el máximo provecho del rendimiento de sus trabajadores y, así, volverse competitiva, apostando por la diferenciación de la competencia en base al valor añadido que supone tener una organización, un ca-pital humano formado en todas sus parcelas, puede lograr tener una ventaja competitiva considerable.

La formación aporta un sinnúmero de beneficios a la empresa y su adecuado desarrollo contribuye a:

– Optimizar la utilización de los recursos humanos, ayudando a los empleados a alcanzar los obje-tivos de la organización, así como sus metas individuales.

– Proporcionar oportunidades y amplía la capacidad de desarrollo de la habilidades de los trabaja-dores. Colabora además, con la consecución de crecimiento personal.

– Aumentar la productividad de los empleados que contribuye a la organización el logro de sus objetivos.

– Inculcar el sentido del trabajo en equipo y la colaboración entre personas.

– Desarrollar y mejorar la cultura de aprendizaje dentro de la organización.

– Construir una percepción positiva y un sentimiento sobre la organización.

– A la mejora de la calidad de la vida laboral.

– Mejorar la salud y la seguridad de la organización evitando así la obsolescencia.

– Crear una mejor imagen corporativa.

– Desarrollar habilidades de liderazgo, motivación, lealtad, mejores actitudes, y otros aspectos que los trabajadores y gerentes de éxito suelen mostrar.

– Demostrar el compromiso de mantener a los empleados a la vanguardia del conocimiento y la práctica.

9.3.1.4. Reglas básicas (Ground rules)

El objetivo del Project Manager durante el desarrollo del equipo es intentar que, entre los integrantes del equipo ejecutor del proyecto, empiece a surgir un cierto grado de armonía, que confíen uno en el otro y que tengan la capacidad de desarrollar una relación de trabajo. Y sobre todo que las reglas del juego estén claras y aceptadas por todos.

9.3.1.5. Reubicación (Co–location)

La reubicación es una acción que implica reunir a varios integrantes del equipo del proyecto en la mis-ma ubicación física para mejorar su capacidad de trabajo en equipo. Esta reubicación puede ocurrir en cualquier fase del proyecto, siempre y cuando el Project Manager lo estime necesario. Las estra-tegias de reubicación incluyen principalmente una sala de reuniones para el equipo, lugares para la publicación de cronogramas e informes de rendimiento y todas las facilidades necesarias para mejorar la comunicación y el trabajo del equipo del proyecto. En algunos proyectos la reubicación puede ser realizada a través de medios virtuales (teleconferencia, chats, foros, plataformas web y otros).

202


9.3.1.6. Reconocimiento y recompensas (Recognition and awards)

Son muchos los factores que pueden motivar a los integrantes de un proyecto. Beneficios económicos, poder, logros, oportunidades de promoción.... Pero hay un factor muy importante que es el reconocimiento.

Un trabajador que está satisfecho con su trabajo y sus aportes a la empresa son más propensos a estar motivados. Cuando se le reconoce por sus esfuerzos, la tendencia es dar seguimiento a su afán de superación y esforzarse en mantener su trabajo en la empresa.

Existen muchas organizaciones que invierten mucho dinero en la formación y capacitación de sus em-pleados, pero no son capaces de mantenerles en la organización a largo plazo. Esto ocurre porque en muchos casos, los trabajadores no se sienten reconocidos o no vislumbran una posibilidad de promoción.

A veces, pequeños gastos invertidos en un premio o en una promoción interna, pueden transmitir al trabajador una sensación real de reconocimiento por su trabajo bien hecho y reforzar su deseo de mantenerse en la empresa.

9.4. Gestión del equipo (proceso que corresponde a la fase de ejecución del proyecto)

Acorde con el PMBOK®, la gestión del equipo es el proceso que consiste en dar seguimiento al des-empeño de los integrantes del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto. El equipo de dirección del proyecto observa el comportamiento del equipo, gestiona los conflictos, resuelve los problemas y evalúa el desempeño de los miembros del equipo. Como consecuencia de dirigir el equipo del proyecto, se envían solicitudes de cambio, se actualiza el plan de recursos humanos, se resuelven los problemas, se suministran datos de entrada para las evaluaciones de desempeño y se añaden lecciones aprendidas a la base de datos de la organización. Gestionar el equipo del proyecto requiere una variedad de habilidades de gestión para fomentar el trabajo en equipo e integrar los esfuerzos de sus miembros, a fin de crear gru-pos de alto desempeño. La dirección del equipo implica una combinación de habilidades con especial énfasis en la comunicación, la gestión de conflictos, la negociación y el liderazgo. El Project Manager debe proponer a los miembros del equipo tareas estimulantes y recompensar el alto desempeño.


9.4.1.1. Evaluación de rendimiento (Project performance appraisals)

Las evaluaciones de rendimiento son normalmente utilizadas por el Project Manager para analizar la evolución del equipo en diferentes ámbitos del proyecto durante su desarrollo. Normalmente se utiliza una escala de números para facilitar y agilizar el cumplimento de la evaluación. Una vez cumplimen-tada, es fundamental calcular las valoraciones realizadas, a fin de conocer sus promedios y con esto poder poner en marcha acciones preventivas o correctivas que el Project Manager juzgue necesarias.

La evaluación de rendimiento puede contener los siguientes puntos:

Nº Artículo 1 2 3 4 5 61 El equipo está alineado con los objetivos del proyecto 1 2 3 4 5 62 El equipo participa activamente de las actividades de control 1 2 3 4 5 63 Las decisiones son realizadas con consenso 1 2 3 4 5 64 El equipo está motivado 1 2 3 4 5 65 Los conflictos son resueltos de forma armónica 1 2 3 4 5 6

Figura 118: Ejemplo de evaluación de rendimiento

203

C9

Por otro lado, la evaluación de rendimiento también es muy útil para conocer el grado de satis-facción y expectativas de cada integrante del proyecto, acerca de su trabajo, del trabajo de sus compañeros, del ambiente del grupo en general o de sus relaciones con sus pares, superiores o subordinados.

Estas evaluaciones pueden ser realizadas por cualquier persona involucrada en el proyecto. Es decir, el Project Manager puede realizar evaluaciones de sus subordinados, así como estos pue-den realizar evaluaciones del Project Manager o de cualquier líder del proyecto. También se puede hacer entre pares, un integrante evaluando a su compañero, o un Project Manager evaluando al líder técnico.

Algunos ejemplos de cuestiones que pueden aparecer en una evaluación de rendimiento:

“En general, ¿está usted de acuerdo en cómo su responsable gestiona su departamento?”

1. Mucho

2. Bastante

3. Regular

4. Poco

5. Nada

6. No lo sé

“¿Cómo describiría el clima de trabajo con sus compañeros?”

1. Muy bueno

2. Bueno

3. Regular

4. Malo

5. Muy Malo

6. No lo sé

Es importante facilitar campos libres para permitir a los participantes expresar libremente sus comen-tarios, sugerencias o quejas.

Para garantizar la confidencialidad y la calidad de los datos, estas evaluaciones suelen ser realizadas de forma anónima, y se instituye el principio del “360-degree feedback”. Este principio establece lo siguiente: Todo aquél que realice evaluaciones de sus compañeros o superiores, recibirá posterior-mente, las evaluaciones realizadas por los demás, sobre su propio rendimiento, siempre de forma anónima, como dicho anteriormente.

Las respuestas obtenidas ayudarán a cada integrante del proyecto a conocer las sensaciones ge-nerales de todo el grupo, pero principalmente, le permitirá conocer las sensaciones que los demás tienen de sí mismo. Se trata además una importante fuente de información acerca de las fortalezas y debilidades del proyecto, del entorno y del equipo en general.

204


Tan importante como evaluar la performance del equipo y las impresiones personales de los integran-tes del equipo, evaluar las capacidades del Project Manager también es una forma de conocer la evolución del grupo como un todo. Algunos de los puntos que se pueden evaluar acerca de la perfor-mance del Project Manager son:

Nº Artículo 1 2 3 4 5 6

1 Capacidad de liderazgo 1 1 1 1 1 1

2 Capacidad de comunicación 2 2 2 2 2 2

3 Capacidad cumplimiento de objetivos 3 3 3 3 3 3

4 Capacidad de resolución de conflictos 4 4 4 4 4 4

5 Habilidad de cumplimiento de plazos 5 5 5 5 5 5

Figura 119: Ejemplo de evaluación de las capacidades del Project Manager

No existe un modelo específico de Evaluación de Rendimiento, una vez que cada empresa o departa-mento posee expectativas y necesidades diferentes acerca de su grupo y de los proyectos que está llevando a cabo.

9.4.1.2. Gestión de conflictos (Conflict management)

La gestión de conflictos es la capacidad de administrar una situación donde las personas involucradas en un determinado proyectos poseen intereses diferentes.

9.4.1.3. Registro de incidencias (Issue log)

Este documento es utilizado para recoger, registrar y controlar todas las incidencias que puedan generarse durante el desarrollo del proyecto. Es uso efectivo de este documento permitirá al Project Manager gestionar correctamente las incidencias ocurridas, minimizando sus impactos y consecuen-temente, garantizando de alguna forma, el buen progreso del proyecto.



9.4.1.5. Diagramas de red (Network diagrams)


9.4.1.6. Histograma de recursos (Resource histogram)

Los histogramas son herramientas muy prácticas en la planificación de control de los recursos. Per-mite gestionar de forma adecuada las horas de trabajo de los integrantes de un equipo de proyecto. Entre otras cosas, permite visualizar:

– Si un recurso tiene más horas de trabajo que las que le fueron originalmente asignadas.

– Si un recurso tiene demasiado tiempo ocioso, mientras que otro recurso similar está sobrecargado.

205

C9

Para confeccionar un histograma de recursos es necesario saber básicamente:

– Quiénes son los integrantes del proyecto y a cuales tareas han sido asignados.

– Cuáles son las tareas del proyecto y sus respectivas duraciones.

En el ejemplo que viene a continuación, podremos visualizarlo de forma ilustrada:

Actividad Pedro Mariano María Montse

Requisitos 4 horas – 2 horas 6 horas

Diseño 10 horas 12 horas 10 horas –

Codificación 60 horas 40 horas 20 horas 10 horas

Documentación 5 horas 1 hora 6 horas 3 horas

Pruebas – 2 horas 2 horas –

Total horas 79 55 40 19

Figura 120: Tabla de asignación de horas y recursos humanos a las actividades

Figura 121: Grafico de asignación de horas y recursos humanos a las actividades

En este ejemplo, se puede observar claramente que Pedro y Mariano están trabajando en este pro-yecto mucho más horas que los demás, es decir, no hay un equilibro de horas de dedicación entre los cuatro integrantes de este proyecto.

No obstante, tenemos que saber si María y Montse están asignados a otros proyectos y por esta razón tienen que repartir sus horas. Además, es fundamental tener en cuenta la cantidad de horas necesarias para completar una actividad, o sea, puede que no sea necesario tener mucha gente dedicada a la misma actividad. En cualquier caso, el Project Manager deberá equilibrar está relación, para evitar que sus recursos estén ociosos o sobrecargados.

05

1015202530354045

REQ

UIS

ITO

S

DIS

EÑO

COD

IFIC

ACI

ON

DO

CUM

ENTA

CIO

N

PRU

EBA

S

PEDRO

MARIANO

MARIA

MONTSE

206


9.4.1.7. Calendario de recursos (Resource calendar)

El calendario de recursos es una herramienta muy utilizada por el Project Manager para organizar y consultar la disponibilidad de los integrantes del equipo del proyecto.

Estos calendarios deben reflejar quienes son recursos que están solamente disponibles durante el horario laboral, quienes pueden trabajar por la noche o quienes se encuentran indisponibles por vaca-ciones, bajas médicas, formación o porque están asignados a otro proyecto.

El calendario de recursos debe estar disponible en una red compartida, que permita que cualquier involucrado en el proyecto pueda conocer la disponibilidad de determinados recursos.

C10Dirección de RRHH

208


10.1. Identificación de los interesados (proceso que corresponde a la fase de inicio del proyecto)10.1.1. Técnicas y herramientas

10.2. Planificación de las comunicaciones (proceso que corresponde a la fase de planificación del proyecto)10.2.1. Técnicas y herramientas

10.3. Distribución de la información (proceso que corresponde a la fase de ejecución del proyecto)10.3.1. Técnicas y herramientas

10.4. Gestión de las expectativas de los interesados (proceso que corresponde a la fase de ejecución del proyecto)10.4.1. Técnicas y herramientas

10.5. Informes de rendimiento (proceso que corresponde a la fase de control del proyecto)10.5.1. Técnicas y herramientas

209

Algunas cosas en las que NO puedes pensar acerca de la dirección de comunicación

“No controlo mucho de francés, pero creo que entiendo más o menos lo que este documento propone”

¿Cuantas veces has intentado traducir un documento utilizando los típicos programas gratuitos de tra-ducción, que no hacen otra cosa que crear más confusión? Hay un pasaje en el viejo testamento que refleja exactamente la ejecución de un proyecto y los problemas resultantes de la mala traducción o interpretación de un idioma extranjero: la Torre de Babel. Definida como una escalera entre el cielo y la tierra, la Torre de Babel figura en el texto del Génesis, donde se relata que los hombres, reunidos en la llanura de Shinear, resolvieron levantar una torre gigantesca. Dios, al ver lo que intentaban, obstaculizó sus planes “confundiendo sus lenguas” de modo que los obreros no pudieran entenderse entre sí. Al quedar incapacitados de trabajar de común acuerdo, los constructores abandonaron el proyecto y se dispersaron en diferentes direcciones. La Torre de Babel se convierte entonces en símbolo de la confu-sión y las desastrosas consecuencias que invaden al hombre cuando no puede comunicarse con sus semejantes, porque cada uno emplea su propio idioma o la comunicación no fluye de forma adecuada.

“No hace falta que me envíes ningún e-mail. Me acordaré perfectamente de todo lo que hemos acordado esta mañana”

La comunicación escrita tiene varias ventajas, pero una de ellas es incontestable: ¡Tiene permanencia! Es decir, que la información estará siempre disponible en cualquier momento que la necesitemos. La comunicación escrita además, nos permite pensar y definir claramente lo que queremos expresar, lo que reduce drásticamente la posibilidad de interpretaciones equivocadas (que es una importante fuente de problemas en proyectos). Además, una vez finalizado el proyecto, toda la comunicación escrita generada puede ser utilizada como fuente de consulta (lessons learned), como medio de in-formación ya que está escrita permanentemente.

“No tengo las instrucciones completas, pero me dejaron algo escrito en este post-it”

Una vez Peter Drucker dijo que “El 60% de los problemas empresariales son consecuencia de una mala comunicación”. Es imprescindible tener en cuenta que uno de los motores que mueven un proyecto es la comunicación, que tiene que ser generada, transmitida y recibida correctamente, o al contrario, podrá provocar daños importantes al proyecto. ¿Cuántas veces hemos realizado mal un tra-bajo porque el mensaje nos ha llegado incorrecto, incompleto o equivocado? La mala comunicación puede ser la causa del fracaso de un proyecto.

Introducción

Imagine que acabas de planificar un viaje de coche que exigirá cruzar algunos miles de kilómetros. Antes de realizarla, has tomado todas precauciones necesarias para empezar un largo viaje: dispones de los mapas del recurrido, te has informado acerca de la previsión del tiempo y has realizado una revisión completa en el coche. No hay razón para preocupaciones.

210


Sales con el coche, recurres los primeros kilómetros, pero durante el trayecto, te das cuenta que están haciendo obras en la carretera que te obligarán a hacer un recorrido muy distinto del planifica-do. No habían puesto ninguna señal de obras durante el recorrido, lo que podría haberte ayudado a realizar alguna acción correctiva (coger un desvío) antes de acercarse a la obra, para de esta forma no tener tantos trastornos.

Ocurre que ahora te encuentras en el medio de un atasco de coches monumental, la gasolina no será suficiente para recorrer el tramo provisional y tú no tienes ninguna información acerca de la lo-calización de la próxima gasolinera. Todos estos incidentes, te hicieron consumir mucho más horas de las planificadas, lo que te obligará a pasar la noche en un hotel en una ciudad que desconoces completamente. Todo el plan original del viaje tendrá que ser revisado. Quizás ni siquiera valdrá la pena seguir con el viaje.

Si los responsables de la obra hubiesen realizado una sencilla labor de comunicación a los conducto-res a través de una señalización adecuada, con una antelación que pudiera te permitir revisar tu plan, quizás tu proyecto de viaje no habría sido tan gravemente perjudicado.

Normalmente, un Project Manager suele consumir entre el 75% y el 90% de su tiempo realizando gestiones relacionadas con la comunicación del proyecto. Casi todos los documentos generados en un proyecto son remitidos al Project Manager y es él normalmente la persona encargada de transmi-tirlos. Esta información normalmente viene de distintas personas y suelen llegar en los más variados formatos, que necesitarán de un tratamiento adecuado para poder ser transmitido de forma clara e inequívoca a los involucrados del proyecto.

La comunicación eficaz es una de las claves de un proyecto de éxito. En resumen, es compartir los mensajes adecuados en los momentos oportunos a las personas correctas.

La dirección de comunicación incluye los elementos necesarios para una adecuada generación, co-lecta, diseminación y almacenamiento de las informaciones del proyecto. Hay estudios que compro-baron que existe un alto porcentaje de atritos, frustraciones y ineficiencias que tiene como origen una comunicación escasa.

Modelos de comunicación

El modelo clásico de comunicación se encuentra ilustrado a continuación, en la figura 122. Consiste en un emisor que transfiere una información a través de un canal de comunicación a un receptor. Cuando el receptor recibe el mensaje, se la decodifica y la analiza. Normalmente, el receptor respon-de al emisor a través de un canal de retorno, con la respuesta del mensaje recibido. Este ciclo es conocido como “loop de comprensión”.

Figura 122: Canal de comunicación

211

C10

Saber comunicarse es una de las habilidades más importantes de un Project Manager y será una de las herramientas más eficaces a la hora de hacer con que el proyecto se ejecute acorde con el plan. Además, durante su ejecución, todos los interesados deberán ser comunicados acerca de la evolu-ción de los trabajos realizados. Es muy importante que el Project Manager desarrolle una estructura de comunicación. Normalmente está estructura incluirá:

– La planificación de la comunicación: analiza las necesidades de información de cada interesa-do y desarrolla los canales de comunicación que serán utilizados en el proyecto.

– La distribución de la información: es el proceso que desarrolla el sistema de recogida y distribu-ción de la información de forma en que la información llegue al receptor de forma clara y correcta. Podrá ser formal o informal, escrita o oral, o de otra forma.

– Informes de seguimiento: Es un documento que transmite a los interesados sobre la situación ac-tual del proyecto, los problemas encontrados y las previsiones y estimativas de las siguientes fases.

Objetivos de la dirección de comunicación

– Facilitar la toma de decisiones.

– Coordinar mejor los departamentos involucrados en el proyecto.

– Favorecer la participación.

– Mejorar la eficiencia.

La forma de transmitir un mensaje, es muchas veces tan o más importante que el propio mensaje en sí.

Tipos de comunicación

– Escrita u oral: Dependerá de la situación. Un mensaje escrito permitirá preparar un primer borra-dor, y luego realizar las debidas correcciones hasta llegar al exacto contenido del mensaje que se quiere transmitir. Además, los mensajes escritos se quedan registrados para posteriores consul-tas o comprobaciones. Sin embargo, en muchos casos, un mensaje escrito puede ser mal inter-pretado ya que la entonación o el sentimiento son muy difíciles de ser transmitidos en este tipo de mensaje. Una comunicación oral, permite un feedback rápido, que muchas veces aporta ahorro de tiempo y agilidad. Sin embargo, en situaciones más delicadas, podrá llevar a situaciones de nerviosismo que el transmisor del mensaje podrá no saber cómo actuar.

– Formal o Informal: La comunicación formal es realizada utilizando documentos previamente es-tablecidos por el Project Manager y su equipo, como son las actas de reunión, memorandos o plantillas de e-mail. La comunicación informal, es básicamente compuesta por las conversaciones e intercambios de ideas entre los afectados del proyecto, durante la ejecución de los trabajos previstos. En muchas ocasiones, durante una conversa informal se generan decisiones muy im-portantes que deberán posteriormente ser compartidas formalmente con los demás integrantes del proyecto. Las comunicaciones informales tienen dos desventajas importantes: como no hay ningún registro, mucha información valiosa se pierde. Además, algunos conflictos pueden gene-rarse por una decisión tomada informalmente.

– Individual o colectiva: Transmitir un mensaje a un grupo tiene una ventaja muy clara: asegura que todo el grupo ha escuchado exactamente el mismo mensaje y bajo las mismas circunstancias. No obstante, las interpretaciones por parte de algunas personas podrán ser distintas, de acuerdo con la percepción o expectativa de cada miembro del grupo.

Saber elegir la mejor forma de hacer llegar un mensaje a una persona o grupo de personas, es impor-tante para que el proyecto avance sin incidencias. La tardanza en una respuesta, la mal interpretación de un mensaje o la omisión de una información, perjudicará el buen avance del proyecto.

212


Las reuniones del proyecto

La reunión de proyecto es una cita obligatoria. Reunir el equipo de proyecto es fundamental, sobre todo cuando es posible reunir todos los integrantes. Es una oportunidad de revisar el progreso del proyecto, la documentación generada y las próximas actividades y principalmente compartir infor-mación. La reunión de proyecto debe ser realizada regularmente. Si posible, es aconsejable que el equipo del proyecto organice reuniones siempre en el mismo día y hora, creando así, una rutina de seguimiento. Infelizmente, la reunión de proyecto es con frecuencia, vista con antipatía, como si el tiempo invertido en estos encuentros fuese un tiempo perdido. De hecho, las reuniones de proyecto deberían ser tratadas como una actividad del proyecto, y por ello deberían ser incluir en el cronograma.

Algunas recomendaciones sobre la organización de reuniones:

Realizar reuniones solamente cuando necesario: Las reuniones podrán perder su efecto si convo-cadas sin una agenda fuerte. No convoque una reunión si:

– Los temas pendientes pueden ser resueltos por e-mail.

– Lo que tienes que decidir, lo podrás decidir solo.

– No hay temas importantes por decidir.

Sé claro en relación al propósito de la reunión: Los objetivos y la agenda de la reunión deben ser claros y propuestos en el momento adecuado. Se pueden clasificar una reunión por tipo, y normal-mente los tipos más importantes de reunión son:

– Reunión de progreso: Su fin es evaluar estado actual del proyecto y tratar de determinar estrate-gias para la ejecución de las próximas actividades.

– Reunión de decisión: Consiste en decidir sobre un tema pendiente, un evento inesperado o una estrategia puntual.

– Reunión de acuerdo: Ocurre cuando hay la necesidad de llegar a una decisión conjunta sobre un determinado tema.

– Reunión de información: Es realizada para comunicar alguna decisión importante o algún aconte-cimiento importante para el proyecto.

– Reunión de opinión: Su necesidad viene por una necesidad de dialogar con el equipo con el fin de colaboración en una decisión importante.

– Reunión de instrucción: Tiene por fin determinar la dirección de un evento o incrementar el cono-cimiento sobre un determinado aspecto.

– Reunión de revisión: es realizada normalmente cuando se acerca el fin de una determinada fase. Analiza algunos aspectos como los resultados de una determinada operación.

Organice una reunión de forma sistemática: Reuniones bien estructuradas y bien organizadas sue-len ser eficaces. Es importante seguir un guión como el de la continuación:

– Preparando una reunión

∙ Determine el objetivo o propósito.

∙ Prepare un previo comentario.

213

C10

∙ Prepare la agenda.

∙ Determine su duración.

∙ Invite las personas necesarias.

∙ Convoque la reunión con una antelación razonable.

– Comenzando una reunión

∙ Explique el propósito de la reunión.

∙ Anuncie la agenda.

∙ Este seguro que todos los participantes entendieron el objetivo de la reunión.

– Asegure la atención y la participación del equipo

∙ Permita que el equipo colabore con sus opiniones.

∙ Controle las discusiones y desentendimientos.

∙ No permita que la reunión salga de sus objetivos.

∙ Asegure que los temas sean concluidos.

– Cierre la reunión

∙ Termine la reunión en tiempo.

∙ Desarrolle un plan de acción con las decisiones tomadas.

∙ Intente obtener compromiso por parte del equipo.

– Actividades tras el cierre

∙ Confeccione un acta de reunión y envíela en veinticuatro horas como mucho.

Una reunión bien estructurada y con un guión concreto proporcionará un tono bastante formal e in-centivará la participación del equipo. Si los integrantes de un equipo empiezan a ausentarse de las reuniones, la información se quedará dispersa y será necesario dedicar más tiempo para hacer con que el mensaje llegue a todo el equipo.

* Nota del autor: Centro de mando (War room)

El concepto de war room se refiere, en términos militares, a un lugar donde el comandante jefe se reúne con su mando para desarrollar y dar seguimiento a tácticas, planes y estrategias de combate, antes de su ejecución en el campo de batalla. Histó-ricamente, podemos retroceder a la segunda guerra mundial, más precisamente al nº 10 de Downing Street (Londres), donde Winston Churchill conducía todo el esfuerzo bélico ingles en el sótano, transformado en Centro de Mando. De las innúmeras reuniones mantenidas en aquel local, salieron muchos de los planes que culminarían posteriormente con la victoria de los alia-dos en 1945. En la actualidad, se sabe que en la Casa Blanca en Washington, existe un local conocido como Situation Room (Sala de Situación), utilizada por el presidente estadounidense y su mando militar en situaciones de emergencia, como en los atentados del 11-S.

En el ámbito del Project Management, un local como este se hace extremadamente necesario, aunque parezca exagerado. Un proyecto, igual que un conflicto bélico (guardando las debidas proporciones), puede sufrir graves incidencias y terribles consecuencias. Por esta razón sería muy interesante que la organización pudiese disponer un lugar especial, con las facilidades necesarias para el desempeño de un grupo de trabajo. Es importante tener en cuenta que una situación de crisis normalmente ocurre en un momento inestable y por esta razón el Centro de Mando debe estar integrado por personas específicamente invo-lucradas en el perfil de situaciones de conflicto o crisis específicas que sean capaces de tomar las rápidamente las decisiones necesarias para la corrección de un determinado problema.

214


Canales de comunicación

Los canales de comunicación son un importante aspecto en la dirección de comunicación. Es impor-tante entender las relaciones entre personas que se comunican y percibir que la a medida que más gente se involucra en una conversación más difícil será transmitir con claridad un mensaje concreto.

– Canal circular: El canal circular de comunicación es una estructura de comunicación en círculo, según ilustra la figura 123. En este tipo de canal, el mensaje necesita pasar por varias personas, hasta llegar al receptor del mensaje. Cuanto más grande sea el círculo, más personas estarán entre el emisor y el receptor del mensaje. Hay que tener un especial cuidado de preservar el con-tenido original del mensaje, durante su recorrido hasta el receptor final.

Figura 123: Canal circular

– Canal en cadena: En este tipo de comunicación, el mensaje sale del emisor y es pasada a los integrantes de la cadena uno a uno, hasta llegar al receptor, según ilustra la figura 124. Este tipo de canal de comunicación es donde ocurre más frecuentemente problemas de comunicación, ya que el mensaje suele tener su contenido original ligeramente cambiado toda vez que llega a uno de los integrantes, pudiendo llegar bastante cambiada al receptor. Se puede comprobar esto haciendo una sencilla prueba. En un grupo de 10 personas, un integrante comenta una noticia en privado con otro integrante. Este integrante repasa la noticia en privado al siguiente, hasta que la noticia finalmente llega al décimo integrante. Al final se compara la noticia transmiti-da por el emisor original y el receptor final. Normalmente las dos versiones presentadas son completamente distintas.

Figura 124: Canal en cadena

215

C10

– La rueda: Este tipo de canal de comunicación centraliza y da poder al individuo del centro, según ilustrado en la figura 125. Todas las informaciones se dirigen al centro y solamente el centro pro-vee información para los otros individuos de la cadena. En este tipo de canal, el centro ocupa una situación privilegiada, por ser el único detector de toda la información que proviene de varias fuentes. De esta forma, podrá filtrar determinadas informaciones o no hacerlas llegar a su destina-tario, si así le parece conveniente.

Figura 125: La rueda

– Canal de Comunicación Abierto: La figura 126 ilustra un canal de comunicación abierto. Cada nodo del canal puede comunicarse con cualquier otro nodo. Eso significa que la información de un individuo puede ser transmitida a cualquier otro individuo en el diagrama. La comunicación en este tipo de canal es difícil de controlar porque la información fluye fuera de un orden y puede venir de cualquier nodo del diagrama. Según el número de individuos incremente, los nodos de comunicación incrementarán también.

El número de canales de comunicación posibles puede ser calculado a través de la siguiente formula:

Canales = [N x (N – 1)] / 2

Por ejemplo, si existen 6 personas en el equipo del proyecto y es necesario que ellos se comuniquen entre ellos, ¿cuantos canales de comunicación son necesarios?

Canales = [ 6 x ( 6 – 1 ) ] / 2

Canales = [ 6 x ( 5 ) ] / 2

Canales = 30/2

Canales = 15

216


Figura 126 – Canal de comunicación abierto

*Nota del autor: Principales barreras de comunicación

Barreras Logísticas

– Geográficas.

– Husos horarios.

– Métodos (e-mail, videoconferencias, audio conferencias...).

– Diferencias multiculturales.

Barreras idiomáticas

– Diferentes terminologías.

– Gestos u otras comunicaciones no verbales.

– Problemas de traducción.

– Desconocimiento del idioma.

Aspectos personales

– Educación.

– Valores.

– Actitudes.

– Estatus social.

Organizacionales

– Cultura organizacional.

– Rumores.

– Conflictos de interés.

– Relaciones entre departamentos.

– Diferentes prioridades.

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección de comunicación de un proyecto incluye procesos y actividades necesarios para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto sean adecuados y oportunos. Son ellos:

– Identificar a los interesados.

– Planificar las comunicaciones.

– Distribuir la información.

– Gestionar las expectativas de los interesados.

– Informar el desempeño.

217

C10

10.1. Identificación de los interesados (proceso que corresponde a la fase de inicio del proyecto)

Acorde con el PMBOK®, la identificación de los interesados consiste en identificar a todas las per-sonas u organizaciones impactadas por el proyecto y en documentar información relevante relativa a sus intereses, participación e impacto en el éxito del proyecto. Los interesados en el proyecto son personas y organizaciones (por ejemplo, clientes, patrocinadores, la organización ejecutante o el pú-blico) que están activamente involucrados en el proyecto, o cuyos intereses pueden verse afectados de manera positiva o negativa por la ejecución o terminación del proyecto. Ellos también pueden influir sobre el proyecto y sus entregables. Los interesados pueden encontrarse en diferentes niveles dentro de la organización y poseer diferentes niveles de autoridad, o bien pueden ser externos a la organización ejecutante del proyecto. Para el éxito del proyecto, resulta fundamental identificar a los interesados desde el comienzo del mismo y analizar sus niveles de interés, expectativas, importancia e influencia. Se puede elaborar entonces 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 mitigar los im-pactos negativos potenciales. La evaluación y la estrategia correspondiente deben revisarse de forma periódica durante la ejecución del proyecto para ser ajustadas frente a eventuales cambios.

La mayoría de los proyectos tendrán gran cantidad de interesados. Dado que el tiempo con el que cuenta el Project Manager es limitado y debe usarse con la mayor eficiencia posible, estos interesa-dos deberían ser clasificados según su interés, influencia y participación en el proyecto. Esto permite que el Project Manager se concentre en las relaciones necesarias para asegurar el éxito del proyecto.


10.1.1.1. Matriz poder/interés (Power/interest matrix)

Descrito en la sección 1.7.3.1.1.



10.2. Planificación de las comunicaciones (proceso que corresponde a la fase de planificación del proyecto)

Acorde con el PMBOK®, planificar las comunicaciones es el proceso para determinar las necesida-des de información de los interesados en el proyecto y para definir cómo abordar las comunicaciones.

El desarrollo del proyecto puede ponerse en peligro por una comunicación pobre. Por ello, hay que cerciorarse de realizar un ejercicio efectivo y constructivo de comunicación y gestión documental. To-das las personas involucradas en el proyecto deben comprender cómo afectan las comunicaciones al proyecto como un todo.

Mediante la definición de un proceso de planificación de las comunicaciones se podrán determinar las necesidades de información y comunicación de los interesados, así como determinar una forma adecuada de satisfacer esas necesidades, por ejemplo, quién necesita qué información, cuándo la necesitará, cómo le será suministrada y por quién. Si bien todos los proyectos comparten la necesi-dad de comunicar información del proyecto, las necesidades de información y los métodos de distri-bución varían ampliamente.

218



10.2.1.1. Análisis de requisitos de comunicaciones (Communication requirement analysis)

El PMBOK® define el análisis de requisitos de Comunicación como una herramienta que determina las necesidades de información de los interesados. Estos requisitos se definen combinando el tipo y el formato de la información necesaria con un análisis del valor de dicha información. Los recursos del proyecto se utilizan únicamente para comunicar información que contribuya al éxito o cuando una falta de comunicación puede conducir al fracaso.

Asimismo, el Project Manager debe considerar la cantidad de canales o rutas de comunicación po-tenciales como un indicador de la complejidad de las comunicaciones de un proyecto. La cantidad total de canales de comunicación potenciales es igual a n(n-1)/2, donde n representa la cantidad de interesados. Por consiguiente, un proyecto con diez interesados tiene 10(10-1)/2 = 45 canales de co-municación potenciales. Por lo tanto, un componente clave de la planificación de las comunicaciones reales del proyecto son la determinación y delimitación de quién se comunicará con quién y de quién recibirá qué información.

Entre la información normalmente utilizada para determinar los requisitos de comunicación del proyec-to, se incluyen:

– Organigramas.

– La organización del proyecto y las relaciones de responsabilidad de los interesados.

– Las disciplinas, departamentos y especialidades con implicación en el proyecto.

– La logística de cuántas personas participarán en el proyecto y en qué ubicaciones.

– Las necesidades de información interna (por ejemplo, comunicaciones entre diferentes empresas).

– Las necesidades de información externa (por ejemplo, comunicaciones con los medios).

– La información sobre los interesados proveniente del registro de interesados.

10.2.1.2. Tecnología de las comunicaciones (Communication technology)

La comunicación es un elemento vital y uno de los factores de éxito de cualquier proyecto. Se equi-voca quienes piensan que una empresa que cuenta con un moderno sistema de comunicación tiene asegurado un eficaz flujo de información y habrá fomentado correctamente la comunicación entre los interesados del proyecto. Hay empresas que están dotadas de dichos sistemas pero la comunicación sigue siendo escasa. Los sistemas de intercambio de información son independientes de modernos sistemas informáticos. Un equipo de proyecto puede comunicarse perfectamente a desde breve con-versaciones, hasta reuniones prolongadas. La cuestión es que, durante un proyecto, una cantidad importante de información tiene que ser generada y tanto el Project Manager como su equipo deben tener en cuenta una serie de factores importantes:

– La urgencia de la necesidad de información: ¿El éxito del proyecto depende de contar con información actualizada frecuentemente y disponible de inmediato, o bastaría con emitir periódi-camente informes escritos?

– La disponibilidad de la tecnología: ¿Los sistemas con los que ya se cuenta son apropiados o las necesidades del proyecto justifican un cambio? Por ejemplo, ¿el o los interesados previstos tienen acceso a la tecnología de comunicaciones seleccionada?

219

C10

– El personal previsto para el proyecto: ¿Los sistemas de comunicación propuestos son com-patibles con la experiencia y conocimientos de los participantes del proyecto o se requiere una capacitación y un aprendizaje exhaustivos?

– La duración del proyecto: ¿Es probable que la tecnología disponible cambie antes de la finali-zación del proyecto?

– El entorno del proyecto: ¿El equipo se reúne y trabaja cara a cara o en un entorno virtual?

10.2.1.3. Modelos de comunicación (Communication models)

Tal y como he comentado anteriormente, la comunicación constituye una de las herramientas más importantes que los profesionales tienen a disposición para desempeñar correctamente sus funcio-nes. Toda la investigación moderna sobre la comunicación se basa en el artículo que describe el acto de comunicar, publicado en 1948 por el científico político americano Harold Lasswell. Este artículo describe el acto de la comunicación como un proceso que debería seguir un recorrido unidireccional. Para demostrarlo, ha creado una formula que es conocida como el Paradigma de Lasswell: “¿Quién dice qué, a quien, por qué canal y con qué efecto?”.

La figura 127 muestra un modelo de comunicación básico que representa como una información se envía y se recibe entre dos partes, definidas como el “emisor” y el “receptor”. Los principales elemen-tos de este modelo son:

– Emisor: Persona o equipo que intenta enviar un mensaje al receptador.

– Receptor: Persona que recibe la información.

– Canal: Medio físico por el que se transmite el mensaje (internet, teléfono, carta, fax...).

– Codificación: Forma que toma la información que se intercambia entre la el emisor y el receptor.

– Mensaje: Es lo que se quiere transmitir.

– Decodificación: La metodología utilizada para “traducir” el mensaje recibido.

– El ruido: Toda interferencia que pueda perjudicar el entendimiento del mensaje.

Figura 127: Modelo de comunicación básica

Codificador

Decodificador

Decodificador

Codificador

Emisor Receptor

Mesaje

Respuesta-Mesaje

MedioRuido

Ruido

220


A pesar de los años transcurridos y de haber sido superado por otras visiones analíticas más mo-dernas y acordes con el panorama mediático actual, el Paradigma de Lasswell sigue conservando muchas de aquellas virtudes que permitieron el despegue de los estudios sistemáticos de la comuni-cación. Algunos de los modelos de comunicación que surgieron a partir de la teoría de Lasswell son:

– Modelo de Braddock: Incorpora al modelo de Lasswell dos aspectos: las circunstancias en las que se envía un mensaje y el propósito con el que el comunicador comienza el proceso.

– Modelo de Shannon y Weaver: Basado en el paradigma de la teoría matemática de la comuni-cación, fue una obra pionera y ha influido notablemente en los estudios de comunicación.

– Modelo de Hennings: Centrándose más en la comunicación interpersonal entre el emisor y el receptor, establece que hay una serie de estímulos verbales físicos, vocales, y situacionales que determinan la codificación de la información por el emisor y la decodificación de la misma por parte del receptor. En este sentido las nuevas tendencias recepcionistas de la comunicación vienen a indicar que lo importante no es lo emitido sino lo recibido, lo cual le dará al estudio del receptor y a sus características fisiológicas, educativas y culturales que facilitaran o dificultaran su participación en el proceso.

– Modelo de Comunicación de Schramm: Establece que la comunicación es un proceso deter-minado por compartir, es decir, por establecer relaciones entre personas que tengan en común tres componentes como mínimo, tales componentes son: la fuente (puede ser una persona, una cadena de televisión, un medio impreso...), el mensaje (verbal o no verbal, diferentes formas de expresión) y el destino (la persona que escucha o recibe el mensaje).

– Modelo de Katz y Lazarsfeld: Conocido también como two-step-flow, este modelo dice que la influencia de los medios de comunicación de masas no se produce de manera lineal y directa, sino que se produce a través de los líderes de opinión, y del papel que desempeñan como es-tructuradores y reestructuradores de la información.

– Modelo de Comunicación de Maletzke: El modelo destaca su riqueza y amplitud. Es un modelo en el que se analizan cinco submodelos: 1. El comunicador y el mensaje. 2. El comunicador y el medio. 3. El comunicador y el receptor. 4. El mensaje y el medio. 5. El receptor y el medio.

10.2.1.4. Métodos de comunicación (Communication methods)

Acorde con el PMBOK®, existen varios métodos de comunicación que se emplean para compartir la información entre los interesados en el proyecto. De manera general, estos métodos pueden cla-sificarse en:

– Comunicación interactiva: Entre dos o más partes que realizan un intercambio de información de tipo multidireccional. Resulta la manera más eficiente de asegurar entre todos los participantes una comprensión común acerca de temas específicos, e incluye reuniones, llamadas telefónicas, videoconferencias...

– Comunicación de tipo push: Enviada a receptores específicos que necesitan conocer la infor-mación. Esto asegura la distribución de la información, pero no garantiza que efectivamente haya llegado a la audiencia prevista ni que haya sido comprendida. Este tipo de comunicación incluye las cartas, los memorandos, los informes, los correos electrónicos, los faxes, los correos de voz, los comunicados de prensa…

– Comunicación de tipo pull: Utilizada para grandes volúmenes de información o para audiencias muy grandes, que requieren que los receptores accedan al contenido de la comunicación según su propio criterio. Entre los métodos, se incluyen los sitios intranet, el aprendizaje virtual, los servi-dores de contenido... En función de los requisitos de comunicación, el Project Manager decide qué métodos de comunicación deben utilizarse dentro del proyecto, cómo y cuándo hacerlo.

221

C10

10.3. Distribución de la información (proceso que corresponde a la fase de ejecución del proyecto)

La distribución de la información es el proceso que consiste en poner a disposición de los interesados toda la información relevante del proyecto de acuerdo con el plan establecido. Es un proceso que se ejecuta a lo largo de todo el ciclo de vida del proyecto, y tiene como principal premisa la distribución de la información adecuada en el momento oportuno a las personas que correspondan.


10.3.1.1. Sistemas de gestión de la información (Information management system)

El concepto de sistema de gestión de la información puede ser muy amplio. El PMBOK® lo define como un sistema que gestione información; conoce, incorpora y vincula todos los tipos de datos, de todas las áreas de la organización y se relaciona con todos los procesos, desde la generación de información interna y la selección y adquisición hasta la organización de su uso.

Utiliza recursos básicos (económicos, físicos, humanos, materiales) para manejar información dentro y fuera de la entidad. Cuenta con un instrumento por excelencia que es el análisis de información, cuyo objetivo es la captación, evaluación, selección y síntesis, de contenidos de documentos, lo cual adquiere una relevancia extraordinaria ante la creciente circulación de datos e información. Su realiza-ción exitosa y eficiente genera una mejor utilización de la información disponible en aras de acelerar el proceso de acceso y utilización.

Exige, la aplicación de nuevas tecnologías de información y comunicación. Sin embargo, la tecnología por sí sola no es suficiente para lograr una buena gestión de información. Son diversos los procesos que conforman los sistemas de gestión de información; ellos generan las entradas y salidas del siste-ma o de otros procesos relacionados; también pueden identificarse, controlarse, corregirse o actuali-zarse en la medida en que se producen las transformaciones del entorno y evoluciona la organización, como vía incuestionable para garantizar su calidad, eficiencia y mejora continua.

10.3.1.2. Lista de distribución de la información (Information distribution tools)

Uno de los factores clave de éxito de un proyecto es la distribución eficaz de la información. Es fun-damental que todos los implicados estén informados del avance de los trabajos, de las decisiones tomadas, de las estimaciones previstas o de cualquier otro dato que sea relevante para el desarrollo de su labor. La distribución de la información consiste en recoger, compartir y distribuir la información a las partes interesadas en el proyecto en el momento adecuado. La tecnología de la información ha posibilitado que la distribución de la información sea realizada de forma sencilla y rápida. No obstante, todavía existe un cierto descontrol a la hora de distribuir la información, sobre todo cuando la informa-ción llega a quienes no deberían recibirla, un hecho muy grave, una vez que muchas informaciones de un proyecto son confidenciales. Una forma eficaz de distribuir la información correctamente es utilizando una lista de distribución.

La lista de distribución es un conjunto de direcciones que son utilizadas para enviar la información a un grupo determinado de personas de forma organizada. Normalmente, se asigna a una persona que de-berá encargase de la gestión de esta lista, que tendrá que poner en marcha las siguientes acciones:

– Creación y mantenimiento de los grupos de interés.

– Actualización y mantenimiento de las direcciones.

– Creación de perfiles de acceso.

– Gestión de altas y bajas de usuarios.

– Gestión y control de las informaciones enviadas.

– Gestión de contraseñas de acceso.

222


10.3.1.3. Control de versiones (Revision control)

El control de versiones está directamente vinculado a la lista de distribución. La información, además de ser enviada a las personas correctas en el momento adecuado, debe estar actualizada. Se conoce como “control de versiones”, a la gestión de los cambios que se realizan sobre los documentos de un proyecto. El sistema de control de versiones facilita la administración de las distintas versiones de un documento. Para mantener un control eficaz de versiones, es importante que a todos los documentos del proyecto se les incluya una tabla como la que presentamos a continuación:

Versión Descripción Fecha

1.0 Descripción de la actualización realizada [Fecha]



Figura 128: Control de versiones de un documento

A cada versión realizada se le asigna un número y se describe el cambio realizado en el documento, vinculando siempre una fecha a cada versión del documento.

Todos los documentos deben ser guardados con un número de versión en su nombre de fichero, por ejemplo “cronograma proyecto Alfa-v3.doc”, a cada cambio realizado se guardaría el fichero, cam-biándole el número de versión. De esta forma, se conservaría un registro histórico de las acciones rea-lizadas en cada documento, posibilitando volver o recuperar un estado anterior de este documento, evitando de esta forma, conflictos de versiones, documentación duplicada o pérdida de información. También es recomendable que solamente una persona o un reducido grupo de personas esté au-torizado para realizar cambios en la documentación y generar versiones. Los demás integrantes que no estén autorizados, deberán enviar sus modificaciones al personal encargado, solicitando que se genere una versión nueva del documento correspondiente.

10.4. Gestión de las expectativas de los interesados (proceso que corresponde a la fase de ejecución del proyecto)

Acorde con el PMBOK®, la gestión de las expectativas de los interesados es el proceso que consiste en comunicarse y trabajar en conjunto con los interesados para satisfacer sus necesidades y abordar los problemas a medida que se presentan. Implica actividades de comunicación dirigidas a los interesados en el proyecto, para influir en sus expectativas, abordar sus inquietudes y resolver asuntos, tales como:

– Gestionar activamente las expectativas de los interesados para aumentar la probabilidad de acep-tación del proyecto, negociando y ejerciendo influencia sobre sus deseos para alcanzar y mante-ner los objetivos del proyecto.

– Abordar inquietudes que aún no representan incidentes, por lo general relacionadas con la anticipa-ción de problemas futuros. Es preciso revelar y tratar estas inquietudes, así como evaluar los riesgos.

– Aclarar y resolver los incidentes identificados. La resolución puede generar una Solicitud de Cam-bios o puede abordarse fuera del proyecto, por ejemplo, puede posponerse para otro proyecto o fase, o derivarse a otra entidad de la organización.

223

C10

Gestionar las expectativas de los interesados ayuda a aumentar la probabilidad de éxito del proyecto al asegurar que los interesados comprenden los beneficios y riesgos del mismo. Esto les permite apoyar el proyecto de forma activa y ayudar en la evaluación de los riesgos asociados con las elecciones del proyecto. Al anticipar la reacción de las personas frente al proyecto, pueden implementarse acciones preventivas a fin de obtener su apoyo o minimizar los impactos negativos potenciales.

El Project Manager es responsable de gestionar las expectativas de los interesados. La gestión activa de estas expectativas disminuye el riesgo de que el proyecto no alcance sus objetivos y metas por cau-sa de incidentes no resueltos a nivel de los interesados, y limita las interrupciones durante el proyecto.


10.4.1.1. Métodos de comunicación (Communication methods)




10.4.1.3. Habilidades de gestión (Management skills)

Descrito en la sección 15.3.

10.5. Informes de rendimiento (proceso que corresponde a la fase de control del proyecto)

Acorde con el PMBOK®, informar el rendimiento es el proceso de recopilación y distribución de in-formación sobre el desempeño, incluidos informes de estado, mediciones del avance y proyecciones. El proceso de informar el rendimiento implica la recopilación y análisis periódicos de datos reales y su comparación con la línea base a fin de comprender y comunicar el avance y desempeño del pro-yecto, así como proyectar los resultados del mismo. Los informes de desempeño deben suministrar información en un nivel adecuado para cada audiencia. El formato puede variar desde un informe de estado simple hasta informes más elaborados. Un informe de estado simple puede revelar información sobre el desempeño, como el porcentaje completado o los indicadores de estado para cada área (el alcance, el cronograma, los costes y la calidad).

Entre los informes más elaborados, se incluyen:

– El análisis del desempeño pasado.

– El estado actual de los riesgos e incidentes.

– El trabajo completado durante el período.

– El trabajo que se completará a continuación.

– El resumen de los cambios aprobados en el periodo.

– Otra información relevante que debe ser revisada y analizada.

Un informe completo también debería incluir la conclusión proyectada del proyecto (incluidos el tiempo y el coste). Estos informes pueden elaborarse con regularidad o de manera excepcional.

224



10.5.1.1. Análisis de variación (Variance analysis)


10.5.1.2. Métodos de proyección (Forecasting methods)

El método de la proyección consiste en predecir el desempeño futuro de un proyecto basándose en el desempeño real hasta la fecha. Son varios los métodos de proyección, que pueden ser clasificados en diferentes categorías:

– Métodos de serie de tiempo: Se utilizan datos históricos como base para la estimación de re-sultados futuros. Como ejemplo se incluyen el método del valor ganado (véase también sección 7.3.1.1), el promedio móvil, la extrapolación, la predicción lineal, la estimación de tendencias y la curva de crecimiento.

– Métodos causales/econométricos: Son métodos que se basan en la hipótesis de que es po-sible identificar los factores subyacentes que pueden llegar a influir en la variable que se está proyectando. Por ejemplo, las ventas de balones pueden asociarse con el mundial de futbol. Entendiendo las causas, es posible proyectar las variables que influyen y usarse en la proyección.

– Métodos de juicio: Se incorporan juicios intuitivos, opiniones de expertos y estimaciones de proba-bilidad. En los ejemplos de métodos en esta categoría, se encuentran proyecciones compuestas, las encuestas (véase también sección 5.1.1.6), la técnica Delphi (véase también sección 6.4.1.7), la elaboración de escenarios (véase también sección 11.3.1.4) y la proyección por analogía.

– Otros métodos: Incluyen la simulación, las proyecciones probabilísticas y las proyecciones en-semble (proyecciones combinadas).

10.5.1.3. Sistemas de informes (Report systems)

Un sistema de informes es una herramienta muy útil que registra, almacena y distribuye a los intere-sados cualquier información importante acerca de los proyectos (seguimiento de costes, avance del cronograma y desempeño del proyecto en general). El uso de un sistema de informes permite al Pro-ject Manager administrar toda la comunicación generada durante el proyecto, utilizando un formato estándar de fácil entendimiento.

10.5.1.4. Análisis de tendencias (Trend analysis)


10.5.1.5. Análisis del valor del trabajo realizado (EVM methods)


C11Dirección de riesgos

226


11.1. Planificación de la dirección de riesgos (proceso que corresponde a la fase de planificación del proyecto)11.1.1. Técnicas y herramientas

11.2. Identificación de riesgos (proceso que corresponde a la fase de planificación del proyecto)11.2.1. Técnicas y herramientas

11.3. Análisis cualitativo de riesgos (proceso que corresponde a la fase de planificación del proyecto)11.3.1. Técnicas y herramientas

11.4. Análisis cuantitativo de riesgos (proceso que corresponde a la fase de planificación del proyec-to)11.4.1. Técnicas y herramientas

11.5. Plan de respuesta al riesgo (proceso que corresponde a la fase de planificación del proyecto)11.5.1. Técnicas y herramientas

11.6. Supervisión y control de riesgos (proceso que corresponde a la fase de control del proyecto)11.6.1. Técnicas y herramientas

227

Algunas cosas en las que NO puedes pensar acerca de la dirección de riesgos

“Nuestro proyecto no tiene riesgos”

Creo que de todas las cosas en las que no puedes pensar en el Project Management, quizás esta afirmación sea la más absurda. Quien conoce o ha oído hablar de la ley de Murphy, seguramente conocerá su máxima más conocida: “Si algo puede salir mal, saldrá mal”. Esta afirmación que denota una actitud extremadamente pesimista, se aplica a cualquier situación, desde las más banales de la vida cotidiana hasta otras más trascendentes. Por lo tanto, es una estupidez pensar que un prometo no tiene riesgos.

“El proyecto es demasiado pequeño para contener riesgos”

En las estadísticas de la DGT (Dirección General de Tráfico), los trayectos cortos se presentan como los más peligrosos. Esto ocurre por un exceso de confianza al volante por conocer la vía por la que se viaja habitualmente. Con los proyectos pequeños ocurre algo similar. Existe un exceso de confianza que tiende a depreciar eventuales riesgos. Hay que tener claro que ningún proyecto está totalmente exento de riesgos y todos necesitan de un plan de prevención y respuesta adecuadas.

“Gestionaremos el riesgo cuando este ocurra”

Como me encantan los refranes, no podría encontrar un apartado más apropiado para mencionar el muy conocido “más vale prevenir que curar”. Empezar a ejecutar un proyecto sin haber realizado una estrategia previa frente a eventuales riesgos que puedan llegar a ocurrir, equivale a garan-tizarnos tropiezo tras tropiezo, ineficiencias, retrabajos y un sinfín de incidencias que acabarán redundando en un considerable aumento de costes, desmotivación del equipo y desconfianza por parte del cliente.

“Tranquilo, seguro que esto no nos va a ocurrir”

Muchas veces frases como estas han sido dichas segundos antes de que ocurriera un grave acci-dente. Es el resultado de subestimar los riesgos, uno de los grandes errores de la humanidad. Han pasado milenios, desde el surgimiento de las primeras civilizaciones, y el hombre todavía no ha apren-dido a valorar debidamente el riesgo. Muchos de los desastres que vemos a diario en la tele, como la caída de aviones de pasajeros, grandes inundaciones, incendios o derrumbes de edificios son más que nada el resultado de uno o más riesgos que han sido ignorados o subvalorados por las personas implicadas en su gestión. Cualquier proyecto conlleva al surgimiento de determinados riesgos, de menor o mayor proporción, pero que deben ser correctamente valorados y gestionados.

228


Introducción

La dirección de riesgos es una de las más importantes áreas de gestión de un proyecto y deberá ser realizada durante todo el ciclo de vida de un proyecto. La identificación de probables riesgos es relativamente sencilla, sobre todo si el proyecto cuenta con el apoyo de expertos. Sin embargo, estos riesgos deberán ser revisados durante todo el avance de los trabajos, ya que algunos de ellos podrán ser descartados y otros deberán tener una atención redoblada. Además, la posibilidad de surgimiento de nuevos riesgos será una constante durante todo el desarrollo del proyecto.

Uno de las labores más importantes y sin embargo, más difíciles en la dirección de riesgos es la toma de decisiones. Tanto el Project Manager como su equipo afrontarán una infinidad de situaciones que les obligará a tomar decisiones que les pueden llevar tanto al éxito como al fracaso del proyecto.

En un mundo ideal, el Project Manager debería tener a su disposición todas las informaciones nece-sarias para poder decidir con una alta probabilidad de acierto. No obstante, en el mundo real, el nivel de incertidumbre es muy alto, lo que hace con que la toma de decisiones sea una gestión bastante difícil de llevarse a cabo. Para sanarlo es importante que se disponga de una cantidad de información importante para poder reducir el nivel de esta incertidumbre.

La incertidumbre se define como la falta de información de un futuro evento. Normalmente, cuanto mayor el emprendimiento, mayor será su grado de incertidumbre y consecuentemente mayor será su riesgo. Todo eso unido a un plan detallado y teniendo en manos la información necesaria acerca de los factores que influyen en el proyecto, reducirá el nivel de incertidumbre y hará con que el equipo pueda trabajar bajo estimaciones más seguras.

Para alcanzar el éxito, minimizando la ocurrencia de incidencias, es importante que el equipo identifi-que los riesgos involucrados. Tome, por ejemplo, un viaje de vacaciones: si llevamos en cuenta sola-mente el precio, será más barato coger un autobús que un avión, sin embargo si empezamos a añadir otros factores como seguridad, será necesario analizar las estadísticas de accidentes entre ambos transportes. Otros factores, como tiempo de desplazamiento, comodidad..., deberán ser evaluados. En este ejemplo, llegar tarde podrá ser un riesgo aceptable, pero no llegar con seguridad será, sin duda, un riesgo inaceptable.

De acuerdo con el PMBOK®, la definición de riesgos es: “Un evento o una condición que, si ocurre, tiene un efecto positivo o negativo sobre los objetivos del mismo. Un riesgo tiene una causa, y si ocu-rre, una consecuencia”. Conceptualmente, podemos definir el riesgo como “un resultado no deseado” o irónicamente como una “sorpresa inesperada”. No importa cómo se nombre, el riesgo es un factor muy sensible y necesita ser tratado con la atención adecuada.

Existen factores de riesgo (conocidos o no) que pueden perfectamente arruinar meses de trabajo.

El nivel de riesgo depende sobre todo de la cantidad de información disponible. Cuanto menos infor-mación, mayor será el riesgo, ya que el nivel de incertidumbre es muy alto. Según el proyecto avance, el nivel de incertidumbre disminuye, puesto que el Project Manager contará con un nivel de informa-ción cada vez mayor.

Figura 129: Cantidad de riesgo

CANTIDAD DE RIESGO

Sin Información

TotalIncetidumbre

AlgunaInformación

RelativaIncertidumbre

InformaciónCompleta

Total Certeza

229

C11

Por otro lado, aunque el grado de incertidumbre disminuya considerablemente, el riesgo todavía será alto, una vez que cualquier problema surgido en una fase avanzada del proyecto tendrá un impacto muy alto. El riesgo siempre tendrá una importancia muy relevante, o por falta de informaciones en el comienzo de un proyecto o por el impacto que podrá causar cualquier percance en una fase avanza-da del proyecto. La figura 130 ilustra estas dos situaciones:

Figura 130: Matriz de incertidumbre x riesgo

En un proyecto se toman decisiones casi a diario y cada decisión tomada, conlleva en asumir un determinado grado de riesgo. En un mundo perfecto, las decisiones serian tomadas con una proba-bilidad de acierto casi segura, ya que toda la información necesaria estaría disponible, lo que conlle-varía a resultados siempre positivos. Infelizmente en el mundo real, está situación es muy poco fre-cuente, sobre todo cuando se tratan de proyectos que, según sus características, conllevan a la puesta en marcha de algo nunca haya sido hecho anteriormente. Sin la información necesaria, la probabilidad de resultados positivos es baja. En muchos casos el grado de incertidumbre, asociado a la complejidad del proyecto.

Figura 131: Alta complejidad, baja incertidumbre

FASES

RIE

SGO

INCERTIDUMBRE IMPACTO

BA

230


Figura 132: Baja complejidad, alta incertidumbre

Figura 133: Alta complejidad, alta incertidumbre

Figura 134: Baja complejidad, baja incertidumbre

La dirección de riesgos siempre lidiará con incertidumbres y, en muchos casos, el Project Manager no sabrá de la existencia de un determinado riesgo hasta que ocurra o esté a punto de ocurrir. La incertidumbre no puede ser totalmente eliminada, pero puedo mitigarse si se siguen algunas pautas:

– Definir la probabilidad de ocurrencia.

– Cuantificar sus impactos.

– Determinar sus causas y eventuales daños.

Además, el Project Manager deberá desarrollar estrategias que busquen reducir la posibilidad de incidencias. Una dirección de riesgos apropiada podrá convertir un riesgo en una oportunidad.

¿Y cómo un Project Manager podrá saber si puede asumir un riesgo? Todo dependerá del nivel del riesgo, su impacto (negativo o positivo) y, en muchos casos, del perfil del Project Manager. Profe-sionales de perfil conservador tendrán un nivel de tolerancia para los riesgos muy bajo y buscarán siempre evitarlos o por lo menos reducir su posibilidad de ocurrencia. Ya un Project Manager agresivo tenderá a afrontar los riesgos y asumir sus consecuencias, aunque sus impactos sean altos, pues normalmente querrá arriesgarse en busca de resultados muy positivos.

BA?

BA?

?

?

BA

231

C11

El gráfico 151 ilustra algunos de los principales factores de riesgo de un proyecto.

Figura 135: Principales factores de riesgo de un proyecto

Factores de riesgo – Inicio del proyecto

R01 à El proyecto no dispone de un análisis de beneficio/coste.

R02 à El proyecto no dispone de un estudio de viabilidad.

R03 à Hay poca o ninguna información acerca del proyecto.

R04 à El proyecto no cuenta con el apoyo apropiado de la dirección.

Figura 136: Principales factores de riesgo en la fase inicial de un proyecto

Factores de riesgo – Fase de planificación

R05 à El plan no ha sido desarrollado por personas con experiencia en proyectos similares.

R06 à El plan no es un documento escrito, formalizado y debidamente aprobado.

R07 à El plan está incompleto.

R08 à Algunos capítulos del plan no fueron aprobados.

R09 à El equipo del proyecto no ha participado.

R10 à Los procedimientos del proyecto no están claros.

Figura 137: Principales factores de riesgo en la fase de planificación de un proyecto

INICIO PLANIFICACIÓN EJECUCIÓN / CONTROL CIERRE

R01R02R03R04

R05R06R07R08R09R10

R11R12R13R14R15R16

R17R18

232


Factores de riesgo – Fase de ejecución / Control

R11 à La necesidad del cliente ha cambiado.

R12 à Los informes de seguimiento son inconsistentes.

R13 à Sustitución de integrantes del equipo del proyecto.

R14 à Presupuesto insuficiente.

R15 à Plazos incumplidos.

R16 à Número elevado de fallos en las pruebas realizadas.

Figura 138: Principales factores de riesgo en la fase de ejecución/control de un proyecto

Factores de riesgo – Fase de cierre

R17 à Los resultados del proyecto no fueron aprobados por el cliente.

R18 à Miembros del equipo fueron adjudicados a otros proyectos antes del cierre formal.

Figura 139: Principales factores de riesgo en la fase de cierre de un proyecto

Bajo el enfoque de la cuarta edición del PMBOK®, la dirección de riesgos de un proyecto incluye los procesos y las actividades necesarias para llevar a cabo la planificación de la gestión, la identifi-cación, el análisis, la planificación de respuesta a los riesgos, así como su monitorización y control en un proyecto. Los objetivos de la dirección de los riesgos del proyecto son aumentar la probabili-dad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos negativos para el proyecto.

Figura 140: Ciclo de dirección de riesgos

controlar

identificar

analizarplanificar

mon

itore

ar

233

C11

11.1. Planificación de la dirección de riesgos (proceso que corresponde a la fase de planificación del proyecto)

La planificación de la dirección de riesgos es el proceso por el cual se define cómo se gestionarán las actividades de dirección de riesgos para un proyecto. La realización de una plantación cuidadosa mejora la probabilidad de éxito de los otros procesos de dirección de riesgos. La planificación es una gestión fundamental y puede aportar los siguientes beneficios:

– Puede asegurar que el nivel, el tipo y la visibilidad de dirección de riesgos se encuentran acordes tanto con los riesgos como con la importancia del proyecto para la organización.

– Proporciona los recursos y el tiempo suficientes para las actividades de dirección de riesgos.

– Establece una base acordada para la evaluación de riesgos.

El proceso de planificar la dirección de riesgos debe iniciarse tan pronto como se concibe el proyecto y debe completarse en las fases tempranas de planificación del mismo.


11.1.1.1. Análisis y reuniones de planificación (Planning meetings and analysis)

Las reuniones de planificación son las que definen los planes a alto nivel para la realización de una correcta dirección de riesgos, sobre todo en lo que se refiere a las metodologías de aplicación de las reservas para contingencias en materias de riesgo. Además, se establecerán los parámetros de riesgo del proyecto, como, por ejemplo, las categorías y los tipos de riesgos, sus niveles, las probabilidades de ocurrencia y eventuales impactos...

Un proyecto planificado adecuadamente dará al Project Manager y a su equipo la seguridad y las con-diciones necesarias de poder anticiparse y afrontar los riesgos previstos. Eso resultará en mantener los plazos y los costes originales y los objetivos determinados. Por otro lado, un gran abanico de proble-mas pueden afectar al proyecto, comprometiendo la calidad del servicio y/o producto especificado.

11.2. Identificación de riesgos (proceso que corresponde a la fase de planificación del proyecto)

Durante todo el ciclo de vida del proyecto, el Project Manager y su equipo se encontrarán delante de determinadas situaciones que podrían ocasionar la ocurrencia de alguna incidencia o evento de riesgo que podrían comprometer el buen avance del proyecto. Los riesgos, aparte de su tipo, suelen tener unas características en común: poseen una probabilidad de ocurrencia y un impacto, pueden ser conocidos o desconocidos y pueden generar en algunos casos, una oportunidad de negocio.

Figura 141: Ciclo de dirección de riesgos: Identificación

234


El primer paso en la dirección de riesgos es intentar identificar los riesgos y determinar los desafíos que podrían venir por delante. ¿Cuáles serán los escollos que impedirán al Project Manager de lograr sus objetivos? Como comentado anteriormente, todo empieza con una gran incertidumbre, un total des-conocimiento de cómo el proyecto evolucionará y como los factores internos y externos colaborarán para su éxito o fracaso.

La identificación de riesgos es el proceso de identificación de las amenazas y oportunidades que podrán ocurrir no solamente durante el ciclo de vida del proyecto, como en todo el ciclo de vida del producto o del servicio generado.

Por ejemplo, el proyecto de construcción de un nuevo puente puede haber sido un éxito, pero es importante considerar que una corrosión en su estructura a lo largo de los años podría resultar en una tragedia, es decir, que los materiales utilizados para la construcción de este nuevo puente también deben ser considerados a la hora de identificar un riesgo en potencial. Por ello, es importante a la hora de planificar un proyecto tener en cuenta todos los riesgos involucrados.

No existe una solución mágica para salir de la zona gris de desconocimiento. La identificación de los riesgos dependerá básicamente del juicio de expertos en proyectos similares, de la experiencia del Project Manager y de su equipo y de la cantidad de información disponible.

Tipos de Riesgo

Existen varias formas de clasificar los riesgos de un proyecto. En el ámbito del Project Management, los riesgos pueden ser clasificados de la siguiente forma:

– Estratégicos: Cambios de demanda, propiedad intelectual…

– Organizativos: Infidelidad de empleados, falta de comunicación…

– Personales: Huelga, absentismo…

– Operacionales: Incendios, fallos logísticos, control de calidad…

– Medio Ambientales: Inundación, vientos, terremotos…

– Políticos y Legales: Cambio de legislación y de gobierno…

– Mercado: Competencia, reducción de márgenes…

– Económico Financieros: Tipos de interés y de cambio, impuestos…

– Imprevisibles: Estadísticamente alrededor del 10% de los riesgos de un proyecto pueden ser considerados imprevisibles.

– Riesgo Residual: Riesgo remanente que existe después de que se hayan tomado las medidas de seguridad.

El síndrome del iceberg

John Jeston y Johan Nelis describen en su libro Business Process Management: Practical Guide-lines to Successful Implementations, el síndrome del iceberg, una teoría que puede perfectamente aplicarse en el proceso de identificación de riesgos, y que dice lo siguiente:

235

C11

Los icebergs normalmente solo dejan expuesta un pequeño porcentaje de su masa sobre la superficie del agua. Lo que se encuentra sumergido es totalmente desconocido. Durante el proceso de identifi-cación de riesgos, muchas personas se concentran solamente en lo que ven, y por consiguiente, desarrollan estrategias de respuesta enfocadas solamente a la parte visible del problema.

Figura 142: La punta del iceberg

Sin embargo, la realidad en muchos casos no es completamente visible, sobre todo en la fase inicial del proyecto, cuando el grado de incertidumbre es muy alto. Lo que se encuentra “por debajo del agua” y que todavía no conocemos es lo que representa exactamente el riesgo que el equipo proba-blemente tendrá que enfrentar. Es lo que llamamos de unknowns unknowns (desconocidos desco-nocidos), o en otras palabras, un evento imposible de prever, o totalmente desconocido. Para hacer frente a esta situación se establecen algunas reservas de tiempo, coste y de recursos que podrán reducir el impacto causado por un factor de riesgo todavía desconocido.

Figura 143: La verdad por debajo del iceberg


11.2.1.1. Revisión de la documentación (Documentation reviews)

En general, lo que inicialmente hacen los equipos de proyecto es una revisión estructurada de los planes de proyecto, incluso en los archivos de proyectos anteriores y de otras fuentes de información. Es importante disponer de una documentación completa acerca de proyectos similares, realizados anteriormente. La “lecciones aprendidas” de otros proyectos forman parte importante en las reuniones de identificación de riesgos, ya que aportan información muy útil.

La documentación generada en la dirección de plazos (los diagramas de red, cronogramas) y la direc-ción del alcance (por ejemplo, la EDT) serán de gran utilidad al Project Manager y su equipo.

236


11.2.1.2. Técnicas de recopilación de información (Information gathering techniques)

Algunos ejemplos de técnicas de recopilación de información utilizadas en la identificación de riesgos son:

– Tormenta de ideas: Descrita en la sección 11.2.1.8.

– Técnica delphi: Descrita en la sección 6.4.1.7.

– Entrevistas: Descrita en la sección 5.1.1.1.

– Técnica de grupo nominal: Descrita en la sección 11.2.1.19.

– Técnica crawford slip: Descrita en la sección 11.2.1.11.



11.2.1.4. Análisis de hipótesis o supuestos (Assumptions analysis)

El análisis de hipótesis es una técnica que permite a los involucrados la identificación de posibles es-cenarios para el proyecto que, de otra forma, no sería posible. La gran ventaja de esta técnica reside en la simulación de distintas hipótesis que podrá demostrar cómo responderá el proyecto a los esce-narios identificados. De esta forma, será posible desarbolar planes de mitigación de riesgo o incluso eliminar riesgos que todavía no habían sido identificados.

Esta técnica obedece el siguiente proceso: se formulan posibles hipótesis que tengan por objeto re-flejar e inspirar posibles estrategias de dirección de riesgos. Las hipótesis se pueden clasificar como “generales” y “específicas”. Las hipótesis generales ofrecen información sobre los posibles enfoques que se pueden utilizar para reducir el riesgo sin definir una estrategia concreta.

Las hipótesis específicas se pueden interpretar como la medida de los efectos de una posible estrategia, para ver cómo cabe esperar que funcione. También puede ayudar a establecer si hay dificultades, sal-vedades o cuestiones que se deben tener en cuenta al evaluar el rendimiento previsto de la estrategia.

11.2.1.5. Técnicas de diagramación (Diagramming techniques)

– Diagramas de causa-efecto: También conocido como diagrama Ishikawa o “espina de pez”. Es una de las diversas herramientas surgidas a lo largo del siglo XX en el ámbito de la industria y, posteriormente, en el de los servicios, para facilitar el análisis de problemas y sus soluciones en esferas como es la calidad de los procesos, los productos y servicios (para más detalles, véase también sección 8.3.1.7).

– Diagrama de flujo: Consiste en representar gráficamente hechos, situaciones, movimientos o relaciones de todo tipo, por medio de símbolos (para más detalles, véase el punto 8.1.1.7).

– Diagrama de influencia: Se trata de una representación gráfica de un problema mostrando las influencias causales, el orden en el tiempo de los sucesos y otras relaciones entre las variables y los resultados. Al analizar decisiones, se busca obtener claridad ante situaciones complejas y confusas. La modelización de las decisiones a través de herramientas específicas nos brinda ma-yor comprensión ya que nos permite visualizar gráficamente sus elementos clave. El diagrama de influencia es una herramienta que nos ayuda a identificar a las variables “no controlables” (eventos inciertos con distintos grados de probabilidad) con sus interrelaciones. El diagrama nos permitirá considerar todas las variables clave antes de tomar la decisión y entender cómo se impactan unas a otras y al resultado final esperado.

Todas estas técnicas utilizadas por separado, o en conjunto, podrán ayudar a identificar los riesgos más importantes para el proyecto. Toda esta información disminuirá el grado de incertidumbre y, por consiguiente, la probabilidad de ocurrencia de algún evento de riesgo.

237

C11

11.2.1.6. Análisis DAFO (SWOT analysis)

El análisis DAFO es una herramienta que analiza el ambiente externo e interno de una organización. En el eje externo del análisis organizacional se encuentran las oportunidades y las amenazas, mientras que en el ambiente interno están las fortalezas y debilidades.

Es una herramienta que produce la confrontación de las variables externas e internas, facilitando la generación de alternativas en el caso puntual de identificar algún riesgo potencial.

Figura 144: Análisis DAFO

– Las fortalezas corresponden a los recursos y capacidades de la empresa que, combinados, pueden generar importantes ventajas competitivas en relación a la competencia.

– Las debilidades son los factores más vulnerables de una organización en relación con la competencia.

– Las oportunidades corresponden a las posibilites de crecimiento, fortalecimiento de la empresa, generación de nuevos negocios, entre otros.

– Las amenazas son los cambios en el ambiente que pueden comprometer seriamente la super-vivencia de la empresa.

Los resultados obtenidos a través de la combinación de los cuatro factores del Análisis DAFO podrán aportar lo siguiente:

– Indicar el camino más apropiado para que la empresa pueda desarrollar su estrategia competitiva.

– Establecer los cambios necesarios para que la empresa pueda sacar mejor partido de su plantilla, recursos y posibilidades.

– Ayudar a elegir a trazar estrategias de participación en el mercado, alternativas de inversión, fu-siones, entre otras.

11.2.1.7. Juicio de expertos (Expert judgment)


SWOT

fortalezas

oportunidades amenazas

debilidades

INTERNAS

EXTERNAS

POSI

TIVA

SN

EGA

TIVAS

238


11.2.1.8. Tormenta de ideas (Brainstorming)

Muy utilizada en las empresas, esta técnica consiste en obtener una lista exhaustiva de soluciones y alternativas para un determinado problema. Bajo el liderazgo de un facilitador (que puede ser el Project Manager), se incentiva al equipo para generar toda y cualquier idea que les ocurra sin debatirlas. Cada integrante del grupo tendrá a su disposición un bloque de notas, donde podrá plasmar cualquier idea que pudiera generar algún beneficio para el proyecto. Al cabo de pocos minutos, se obtendrá un lis-tado bastante amplio de soluciones y alternativas que serán analizadas y clasificadas posteriormente. Este análisis descartará las sugerencias que no pueden ser implementadas y combinará las alternati-vas válidas en probables soluciones para el problema.

A pesar de ser una técnica bastante sencilla y muy fácil de ponerse en marcha, es importante respetar algunas reglas básicas:

– Todas las ideas, a principio, son buenas.

– Asegúrese de que sus ideas tienen sentido, no utilice una palabra clave cuyo significado podría olvidarse posteriormente.

– Asegúrese de todas las ideas están escritas en un papel adecuado que posibilite un manipulado y clasificado adecuado.

– Ideas duplicadas deben ser aceptadas. A veces, dos sugerencias parecen idénticas, pero luego cada una puede tener un significado distinto.

– Déjese llevar por la imaginación, cualquier idea puede ser válida.

– Plasme su idea inmediatamente, sin discutirlas con nadie.

Una sección de tormenta de ideas realizada adecuadamente y enfocada en la identificación de riesgos podrá aportar mucha información útil. Los resultados obtenidos podrían identificarnos lo siguiente:

– Riesgos en el alcance: Añadidos en el alcance por parte del cliente, trabajos que no pueden ser definidos, alcance sobreestimado, cambios en el objetivos del proyecto…

– Riesgos en los plazos: Duración de las actividades sobreestimadas, retrasos en las fechas de finalización de actividades, cronogramas irreales, aprobaciones tardías…

– Riesgos en los materiales: Materia prima escasa, retraso en la entrega por parte de los provee-dores, baja calidad, precio elevado, defectos…

– Riesgos en los equipos, suministros y maquinaria: Disponibilidad escasa, baja calidad, incom-patibilidades diversas, limitaciones, poca adaptabilidad…

– Riesgos en los RRHH: Cambios en el equipo, costes inesperados, poca disponibilidad, conflic-tos de interés…

– Riesgos organizacionales: Liderazgo insuficiente, limitaciones políticas, comunicación insuficien-te, limitación de presupuesto, conflictos entre departamentos, apoyo limitado de la dirección, otras prioridades…

– Riesgos de personal: Vacaciones, enfermedades, despidos, temas familiares, conflictos de inte-rés, cuestiones éticas, morales, religiosas…

– Riesgos profesionales: Baja productividad, conflictos de interés, poca motivación, baja calificación…

– Riesgos de influencias externas: Clima, desastres naturales, regulaciones del gobierno, propie-dad intelectual, problemas económicos, políticos, sociales y legales.

239

C11

Ventajas y desventajas

– Ventajas

∙ Estimula la interacción del grupo.

∙ Es rápida.

∙ Tiene un bajo coste.

– Desventajas

∙ Puede ser dominada por el integrante más influyente.

∙ Solo puede ser utilizada en determinadas áreas.

∙ Requiere un mediador muy capacitado.

∙ Puede ser tendenciosa.

11.2.1.9. Técnica de grupo nominal (Nominal group technique)

Desarrollada por Delbecq y Van de Ven, es una técnica que consiste en conducir grupos incorporando un análisis de las ideas presentadas, mientras que el brainstorming, presentado en el punto anterior, es una técnica que se limita a la generación de dichas ideas. Es una técnica que valora, sobre todo, el proceso de decisión asegurando la participación igualitaria de todo el grupo.

Está técnica se desarrolla de la siguiente forma:

– Preparación: Es la primera fase de la actividad. Se confecciona la cuestión objeto de la reunión, cuya redacción debe contener una amplia gama de detalles.

– Generación de Ideas: Una vez presentada la cuestión, los participantes tendrán un periodo limita-do de tiempo (normalmente diez minutos), para desarbolar por escrito, en silencio y sin discusión cualquier idea que pueda generar la solución para la cuestión presentada.

– Ronda de Ideas: En este momento se exponen las ideas desarrolladas. Cada uno expone su idea, obedeciendo el orden físico de la mesa, dando la “vuelta al grupo”. Se registra solamente una Idea por persona y no se hacen críticas o alabanzas a las ideas presentadas.

– Discusión de ideáis: Ha llegado el momento de discutir todas las ideáis presentadas. Se analiza una idea a la vez, valorando sus pros y sus contras. Es fundamental limitar el tiempo de discusión de cada idea, para evitar que la reunión se prolongue demasiado.

– Votación preliminar: Cada participante elegirá las ideas que considere mejores, asignándoles una puntuación predeterminada (por ejemplo, utilizando una escala de 1 a 5).

– Nueva ronda de discusiones (si necesario): En esta fase, las ideas presentadas estarán clasifica-das según la puntuación dada por cada participante. Se analizan los resultados obtenidos y se deciden las acciones correspondientes.


– Ventajas

∙ Reduce el efecto dominante de un integrante influyente.

∙ Genera una clasificación interesante de ideas.

∙ Estimula la interacción del grupo.

240


– Desventajas

∙ Consume mucho tiempo.

∙ Demanda mucho trabajo por parte del mediador.

11.2.1.10. Técnica Delphi (Delphi Technique)


11.2.1.11. Técnica crawford slip (Crawford´s slip writing method)

Muy parecida a la tormenta de ideas, este método puede ser una buena manera de estimular a las personas en las que las secciones de tormenta de ideas les puede producen una cierta inhibición.

La técnica Crawford Slip fue desarrollada por C.C. Crawford en la década de 20 en los Estados Uni-dos y es utilizada para obtener rápidamente una gran cantidad de ideas a partir de grupos numerosos.

Se reúne el equipo del proyecto y se da a cada miembro diez trozos de papel (o post-its). El Project Manager, entonces hace la pregunta: “¿Cuáles pueden ser los eventuales riesgos que podemos iden-tificar para este proyecto?” Cada participante pone sus respuestas en cada trozo de papel recibido. Si el participante consigue enumerar seis posibles riesgos, utilizará seis trozos de papel, y así sucesi-vamente. Esto deberá ser hecho en silencio, individualmente y sin discusiones. Una vez respondida la cuestión, el Project Manager recogerá los papeles y verá las respuestas. Si un determinado grupo es formado por 10 personas, el Project Manager tendrá en su mano cerca de cien respuestas que seguramente podrán formar el listado de los diez riesgos más probables de ocurrencia en el proyecto.


– Ventajas

∙ Es rápida.

∙ De fácil implementación.

∙ Genera una cantidad importante de ideas.

∙ Su formato permite la participación de grandes grupos.

∙ No permite el dominio del más influyente.

– Desventajas

∙ La interacción entre los participantes es muy limitada.



11.2.1.13. Mapa conceptual (Concept map)

El mapa conceptual ha sido desarrollado en los años 70 por el investigador estadounidense Joseph Novak, que lo define como “una técnica de organización y representación del conocimiento”. Son estructurados a partir de conceptos fundamentales y sus relaciones.

241

C11

Se trata sobre todo de una representación gráfica de un conjunto de conceptos construidos de tal forma que las relaciones entre ellos sean evidentes. Se desarrolla de la siguiente manera:

– Se identifican los conceptos clave del contenido que se quiere ordenar en el mapa en una lista.

– Se pone el concepto principal en la parte superior del mapa para ir enlazándolo con otros concep-tos según su nivel de generalización. Estos conceptos deben escribirse con letras mayúsculas.

– Se conectan los conceptos con una palabra enlace, la cual debe ir con letras minúsculas en me-dio de dos líneas que indiquen la dirección de la proposición.

– Se permiten incluir ejemplos en la parte inferior del mapa, debajo de los conceptos correspondientes;

Aunque su origen está ligado a la enseñanza, su aplicación en la visualización de información lo con-vierte como una herramienta útil para transmitir de forma clara mensajes complejos o difíciles de en-tender y, por ello, contribuye notablemente a la identificación de riesgos.

Figura 145: Mapa conceptual de un accidente aéreo

Si miramos la figura 145 de abajo hacia arriba, se podrá identificar, de entrada, cuáles son los riesgos que conllevan, en la peor de las hipótesis, a un accidente aéreo. Los mapas conceptuales son, por lo tanto, una forma muy sencilla y grafica de identificación de riesgos.

Consideraciones importantes a la hora de confeccionar un mapa conceptual:

– Deben ser sencillos y mostrar claramente las relaciones entre sus conceptos.

– Van siempre de lo general al específico. Las ideas más generales ocupan la parte superior de la estructura, mientras las más específicas la parte inferior.

– Deben ser vistosos. Cuanto más visual se confeccione el mapa, más cantidad de información será posible de entender y de procesar.

ACCIDENTEAEREO

FALLO

TECNICOHUMANO

PROBLEMASELECTRONICOS

PROBLEMASMECANICOS

NEGLIGENCIA

IMPRUDENCIA

IMPERICIA

NATURAL

se produce através de un

que tiene origen

causado por

LLUVIAVIENTO

RAYOScausado porcausado por

242


– Los conceptos, que nunca se repiten, van dentro de recuadros y las palabra enlace se ubican en flechas o líneas de relación.

– Las palabras enlace deben utilizar verbos, proposiciones o conjunciones.

– Si la idea principal tiene que ser dividida en dos o más conceptos iguales, estos deberán ir en la misma línea o altura.

11.2.1.14. Diagrama de afinidades (Affinity diagram)

El diagrama de afinidad o método KJ ha sido desarrollado por Jiro Kawakita en los años 60 y es una técnica utilizada para ayudar a reunir una gran cantidad de información y organizarla en función de sus afinidades o relaciones naturales, a través de un proceso creativo que produce consenso por medio de la clasificación que hace un equipo. Es muy útil cuando:

– El problema es complejo o difícil de entender.

– El problema parece estar desorganizado.

– El problema requiere de la participación y soporte de todo el equipo/grupo.

– Se quiere determinar los temas claves de un gran número de ideas y problemas.

Su desarrollo se realiza da la siguiente forma:

PASO 1: Se reúne un grupo de seis a diez personas para que expresen su opinión acerca de una determinada situación y establezcan acuerdos en torno de las causas del problema y sus posibles soluciones. Se utilizará un mediador para organizar la reunión y definir la dinámica de trabajo y las reglas.

Se distribuyen tarjetas en blanco entre todos los asistentes. El mediador solicita a los participantes que anoten en las tarjetas las posibles causas del problema analizado. Normalmente, las tarjetas deberán cumplir los siguientes criterios:

– Los problemas o hechos anotados deben ser concretos.

– No deben anotarse causas, consecuencias, ni juicios.

– Los problemas o hechos deben ser precisos y de fácil comprensión.

– Registrar el nombre de quien escribe la tarjeta.

Figura 146: Paso 1 del Diagrama de afinidades

243

C11

PASO 2: Todas las tarjetas utilizadas son recogidas por el mediador. El grupo conocerá los resultados y realizará una primera organización acorde con la similiridad de la información de cada tarjeta


PASO 3: Las tarjetas deberán leerse y revisarse con el fin de comprobar si la agrupación realizada es la correcta y definitiva. Se asignan entonces un nombre a cada grupo de tarjetas por medio de una discusión en grupo. El nombre del grupo deberá transmitir el significado de las tarjetas agrupadas en pocas palabras. Si alguna tarjeta individual no se encaja en ningún grupo, se podrá crear un grupo aparte con un nombre genérico, por ejemplo: “Otros”.


PASO 4: El Diagrama de afinidades está completo y deberá tener un aspecto similar al representado en la figura a continuación. El grupo deberá discutir la relación de los grupos y sus elementos corres-pondientes con el problema.


244


11.2.1.15. Estructura de desglose de riesgos – EDR (Risk breakdown structure – RBS)

Es una representación jerárquica de los eventos inciertos, los cuales son identificados y ordenados por categoría de riesgo y subcategoría, reconociendo las distintas áreas y causas de probables ries-gos. La estructura de desglose del riesgo se adaptará a cada proyecto específico y proporcionará una estructura que garantiza un proceso completo de identificación sistemática de los riesgos con un nivel de detalle uniforme y ayuda a la calidad y efectividad de la identificación de riesgos.

Figura 150: Ejemplo de EDR

11.2.1.16. Lecciones aprendidas (Lessons learned)

Las organizaciones que están constantemente involucradas en proyectos producen una cantidad importante de información que puede servir como base de consulta en proyectos futuros similares.

Estas informaciones, conocidas en Project Management como “lecciones aprendidas”, son una com-pilación de los aciertos y las equivocaciones del proyecto, como son las estimaciones realizadas, las técnicas utilizadas y la opinión de los participantes directos del proyecto. Estas lecciones aprendidas son enseñanzas que, tras la conclusión de un proyecto, deberán ser cuidadosamente catalogadas, analizadas, almacenadas y distribuidas a los participantes del proyecto cuando sea necesario. De estas informaciones se aprovecharán las estimaciones e informaciones aportadas y se intentará no caer en los mismos errores. Las lecciones aprendidas pueden, de forma muy relevante, contribuir en la mejora continua de las prácticas de la organización. Muchas organizaciones cuentan con profesio-nales exclusivamente dedicados a la organización y el almacenamiento de este tipo de información para consulta del Project Manager o de algún integrante del equipo.

PROYECTO

EXTERNO DE LAORGANIZACIÓNTÉCNICO DIRECCIÓN DE

PROYECTOS

Requisitos

Tecnologia

Complejidad

Fiabilidad

Calidad

Provedores

Normativa

Mercado

Cliente

Recursos

Financiación

Priorización

Estimación

Planificación

Control

Comunicación

245

C11

11.3. Análisis cualitativo de riesgos (proceso que corresponde a la fase de planificación del proyecto)

Mediante este proceso, se pretende buscar la priorización de los posibles riesgos que se pueden producir y que ya han sido anteriormente identificados como probables. Se les debe asignar una pro-babilidad de ocurrencia y el impacto que podrían tener sobre el proyecto. Los riesgos son entonces clasificados en tres niveles: “alto”, “moderado” y “bajo”, a través del auxilio de técnicas sofisticadas y la opinión de expertos.

Figura 151: Ciclo de dirección de riesgos: análisis


11.3.1.1. Probabilidad de riesgos y valoración de impactos (Risk probability and impact assessment)

La probabilidad y las consecuencias de los riesgos en un proyecto en el ámbito del Project Manage-ment pueden ser descritas en términos cualitativos como: “alto”, “moderado” y “bajo”. Algunos autores incluyen además los términos “muy alto” y “muy bajo”.

Acorde con el PMBOK®, un riesgo tiene una “probabilidad”, que se puede definir como “la posibilidad en “%” de que un riesgo pueda ocurrir”. Además, la eventual ocurrencia de un riesgo, conllevará a una “consecuencia” o “impacto”, que es el efecto causado en proyecto. Es importante resaltar, que estas dos dimensiones se aplican a sucesos específicos de riesgo, no al proyecto en conjunto. Realizando un correcto análisis de riesgos conociendo las probabilidades y sus consecuencias, permitirá clasificar los riesgos de una forma que se pueda dedicar una atención proporcional.

La probabilidad y el impacto son, por lo tanto, dos conceptos que no pueden ser ignorados. La probabilidad de que una incidencia puntual ocurra puede ser mínima o casi nula, pero si ocurre, sus consecuencias podrían ser catastróficas. Un vuelo comercial es un buen ejemplo. La posibilidad de que se caiga un avión es muy pequeña, pero cuando ocurre, las consecuencias normalmente son trágicas, puesto que las posibilidades de haber supervivientes son prácticamente nulas.

Matriz de evaluación de probabilidad e impacto del riesgo

Se construye una matriz donde se clasifican los riesgos, según ilustra la figura 152. El nivel de cada riesgo será clasificado en “alto”, “moderado” o “bajo”. Se puede ampliar la matriz añadiéndole dos clasificaciones más: “muy bajo” y “muy alto”. Un evento que conlleve la ocurrencia de un riesgo con alta probabilidad y alto impacto, naturalmente será un calificado como de nivel alto (o muy alto, depen-diendo de la escala que se utilice).

246


Cada evento deberá ser evaluado individualmente. Si surge un determinado evento que tiene una probabilidad muy baja de ocurrir, pero que si acaso ocurriese, su impacto sería catastrófico (por ejem-plo, los atentados en las torres gemelas en Nueva York), se podría considerar como un evento de alto riesgo y debería ser incluido en el plan de dirección de riesgos.

Evento Probabilidad Impacto Nivel de riesgo

A Alta Alto Alto

B Media Alto Alto

C Baja Alto Medio

D Alta Medio Medio

E Media Medio Medio

F Media Medio Medio

G Alta Bajo Bajo

H Media Bajo Bajo

I Baja Bajo Bajo

Figura 152: Tabla de probabilidad x impacto

Con está herramienta, es posible determinar de forma sencilla, la acción más adecuada en una deter-minada relación “probabilidad x impacto”. Existen matrices, como la que ilustra la figura 153, que utiliza nueve combinación de acciones.

ImpactoProbabilidad

Bajo Medio Alto

Bajo Ignorar Ignorar ¡Cuidado!

Medio Ignorar ¡Cuidado! Responder

Alto ¡Cuidado! Responder Responder

Figura 153: Tabla de acciones de respuesta

Es posible, además, añadir más detalle a la evaluación cualitativa de riesgos, incrementando infor-mación a la probabilidad de ocurrencia de un determinado evento, como ilustra la figura 154 que se presenta a continuación.

ProbabilidadImpacto

Bajo Medio Alto

1 Muy improbable Riesgo bajo Riesgo bajo Riesgo bajo

2 Improbable Riesgo bajo Riesgo bajo Riesgo medio

3 Puede o no ocurrir Riesgo bajo Riesgo medio Riesgo medio / alto

4 Probable Riesgo bajo Riesgo medio / alto Riesgo alto

5 Muy probable Riesgo bajo Riesgo medio / alto Riesgo alto


247

C11

En vez de utilizar una escala estándar, como la presentada en el ejemplo, se puede elaborar escalas à medida, que serán aplicada para cada evento, separadamente. Con esta escala se pueden determi-nar acciones concretas, como por ejemplo, establecer que eventos de escala uno o dos pueden ser ignorados, mientras los eventos de escala 4 o 5 deberán ser gestionados con más detenimiento. El nivel tres representa un riesgo que deberá pasar por una evaluación especial, acorde con cada caso.

Se puede también, estimar la probabilidad de ocurrencia de un suceso, a través del uso de fórmulas. En el ejemplo a continuación, fue solicitada la opinión de diez expertos sobre la posibilidad de ocurren-cia de un determinado suceso. Para cada posibilidad se le ha asignado un valor: alto (3), medio (2) y bajo (1). Seis expertos afirmaron que este evento es de alta probabilidad de ocurrencia, dos expertos concluyeron que el evento es de media probabilidad de ocurrencia y los otros dos que era de baja ocurrencia. Con estos resultados, se ha desarrollado la siguiente formula:

(6x3) + (2x2) + (2 x 1) = (18 + 4 + 2) / 10 = 2.4

Esta fórmula sugiere que el evento una probabilidad media/alta de ocurrencia.

11.3.1.2. Evaluación de la calidad de los datos sobre riesgos (Risk data quality assessment)

El análisis cualitativo de riesgos requiere información precisa y no tendenciosa para que sea útil a la gestión del proyecto. La clasificación de la precisión de la información es una técnica para evaluar el grado con el cual la información acerca de los riesgos es útil para la gestión de los mismos. Ello implica examinar:

– El grado de conocimiento del riesgo.

– La información disponible acerca del riesgo.

– La calidad de la información.

– Confiabilidad e integridad de la información.

11.3.1.3. Categorización de riesgos (Risk categorization)


11.3.1.4. Método de los escenarios (Scenary methods)

El concepto “escenario” fue introducido por primera vez en los estudios del futuro por Herman Kahn, cuyos análisis de las probables consecuencias de una guerra, contribuirían al desarrollo de la estrate-gia nuclear de los Estados Unidos.

Un escenario es la descripción de una situación en el futuro, determinado por una trayectoria de su-cesos. Un escenario se construye estableciendo posibles circunstancias previas que pueden llegar a ocurrir y eventualmente provocar dicho escenario efectivamente se constituya.

*Nota del autor: Cualquiera que sea la técnica utilizada para valorar los riesgos de un proyecto, es muy importante seguir las siguientes recomendaciones:

– Para asegurar una clasificación adecuada sobre la posibilidad de ocurrencia de un suceso, se asume que la probabilidad baja corresponde de 0% a 33%; media, de 33% a 66%, y alta de 66% a 100%.

– Es importante tener en cuenta la opinión del mayor número de personas posibles. Sin olvidarnos de la vieja regla que dice que “cantidad es menos importante que calidad”. Cuanto más evaluaciones mejor, pero que procedan de personas con experiencia en proyectos similares.

– Los resultados de cada estimación deben ser recogidos de forma separada. No permita que los expertos consultados tengan la oportunidad de discutir sus evaluaciones en un primer momento. Esto puede influenciar en el resultado final. Una vez recogidas todas las estimaciones y conocidos sus resultados, se podrá promover una reunión conjunta para discutir y llegar a una clasificación única de riesgo.

248


Es importante tener en cuenta que el futuro es una circunstancia incierta que dependerá sobre todo de la toma de una determinada decisión. Existen varios futuros posibles, pero el camino que conduce a uno u otro es forzosamente único. El método de los escenarios tiende a construir una representación de un posible futuro, así como los caminos y/o circunstancias que conducirán a su consecución.

Para poder establecer un escenario, hay que cumplir algunas pautas:

– Es importante determinar exhaustivamente todos los elementos que forman parte del escenario para que el resultado final sea fiable.

– Las circunstancias que conducirán a un determinado escenario deben tener una determinada probabilidad de ocurrencia.

– Básicamente se distinguen dos grandes tipos de escenarios:

– Exploratorios: parten de tendencias pasadas y presentes y conducen a futuros verosímiles.

– De anticipación o normativos: construidos a partir de imágenes alternativas del futuro, pueden ser deseables o rechazables. Se conciben de un modo retrospectivo.

El desarrollo de esta herramienta se realiza en dos fases:

Fase 1: Construcción de la base.

Esta fase consiste básicamente en establecer un conjunto de representaciones del estado actual del sistema constituido por la organización y su entorno. La base es la expresión de un sistema de ele-mentos dinámicos ligados unos a los otros, sistema a su vez, ligado a su entorno exterior. A partir de dicha representación, se llevará a cabo un estudio prospectivo, que contará de cuatro puntos:

– Elección del horizonte temporal y espacial: El horizonte espacial hace referencia normalmente a la zona donde competimos. El horizonte temporal para la construcción de una base no debe ser un periodo de tiempo ni muy largo ni muy corto. Normalmente se establece un periodo corres-pondiente al ciclo de vida del proyecto.

– Elección de las variables esenciales: Se realiza la confección de un listado de las variables clave que son las que van a influir en el escenario futuro. Para poder desarrollar un escenario com-pleto, es imprescindible que se incluyan variables que abarquen el entorno económico, político, tecnológico, legal…

– Asignación de probabilidades: en este punto se realiza la asignación de dos tipos de probabi-lidades: la de ocurrencia (que consiste en señalar la posibilidad que variable que consideramos llegue a materializarse en el escenario futuro) y la de importancia.

– Análisis de inconsistencias y eliminación de variables: Las variables y sus probabilidades de-ben estar relacionadas entre sí, pero antes hay que asegurarse que no hay inconsistencias entre ellas. Además, también se eliminan algunas variables, que aunque son consistentes, su escasa probabilidad de ocurrencia así lo aconseja.

Figura 155: Construcción de la base

Horizonte temporaly especial

Elección devariables

Asignación deprobabilidades

Inconsistencias yeliminación de

variables

VARIABLESRELEVANTES

249

C11

Fase 2: Confección de los escenarios.

En esta fase se confeccionarán los escenarios utilizando la base de las variables relevantes con sus probabilidades correspondientes, definidas en la fase anterior. Este proceso se realiza en 4 partes:

– Relación de variables: Hay que relacionar cada variable con las demás. Existen varias técnicas dife-rentes para hacerlo, la más utilizada es el método de los impactos cruzados (véase siguiente sección).

– Construcción de escenarios: Una vez que se haya realizado correctamente las relaciones entre las variables, se genera un resumen de éstas y se opta por tres escenarios posibles. Para obtener el escenario más probable (que será en nuestro diagrama el escenario nº 2 o “E2”); se resumen las ideas más importantes de las relaciones de las variables y se plasman en un escenario posi-ble. Los otros dos escenarios (“E1” y “E3”) se construyen a partir del escenario “E2” intensificando las variables más importantes hacia arriba o hacia abajo. Es decir; “E1” = “E2”, intensificando las relaciones hacia arriba y “E3” = “E2”, intensificando las relaciones hacia abajo.

– Implicaciones: Se describe las eventuales consecuencias resultantes de la ocurrencia de un determinado escenario, normalmente el más probable (“E2”), pero también se describen las impli-caciones que se darían en los escenarios “E1” y/o “E3”.

– Recomendaciones: Se describen las acciones que deben tomarse en el proyecto, en el caso que se dieran uno de los escenarios analizados.

Figura 156: Diagrama completo de escenarios

Es importante tener en cuenta de que los escenarios están sujetos a proporcionar resultados poco realistas. Todo dependerá de la elección de las variables y del correcto establecimiento de sus pro-babilidades. Los escenarios siempre se basan en hipótesis, más o menos establecidas, que pueden ser cuestionadas a lo largo de todo el proceso de elaboración del escenario. Cuando este ya ha sido elaborado, debe ser contrastado con la realidad y con las posibilidades «reales» de ocurrencia. Si tal escenario no puede tener lugar, entonces es preciso proceder al cambio de las hipótesis de partida, lo que se suele hacerse en base a criterios personales, lo cual puede desembocar en el diseño de un escenario más deseado y quizás la objetividad del proceso sea entonces cuestionable.

11.3.1.5. Método de los impactos cruzados (Cross–impact analysis)

En el método de los escenarios es frecuente encontrarnos con una importante variedad de hechos cuya probabilidad de que se produzcan esté condicionada por la ocurrencia previa de otros eventos. El método de los impactos cruzados ayuda a determinar la naturaleza y el alcance de las repercusio-nes entre los distintos acontecimientos que pueden sucederse en el entorno. Sencillamente, se basa en la probabilidad de que ocurra algo si ha ocurrido otra cosa. Lo aclaramos mejor a continuación.

El método de los impactos cruzados (cross-impact analysis) ha sido desarrollado por Theodore Gor-don y Olaf Helmer en 1966, y se originó en una pregunta simple: “¿Los pronósticos pueden basarse en las percepciones acerca del modo en que interactuarán los eventos futuros?”.

Relación entrelas variables Escenários Implicaciones Recomendaciones

Escenários

Escenários

Escenários

Implicaciones Recomendaciones



250


Un cambio en la tecnología, la aprobación de una nueva ley, diferencias culturales o eventos naturales pueden afectar al entorno alrededor de tres maneras distintas:

– Pueden cambiar la probabilidad de ocurrencia de acontecimientos interconectados.

– Pueden cambiar el momento en que ocurrirán los acontecimientos interconectados.

– Pueden afectar al modo de impacto de los acontecimientos interconectados.

Pongamos un ejemplo*

Supongamos que se estuviera realizando un estudio del futuro de la industria química. En el transcurso del estudio se genera una lista de eventos futuros importantes. Una parte de esa lista podría incluir los siguientes eventos:

– El uso de plásticos en los vehículos de transporte y en la construcción aumenta seis veces desde 1992.

– La mayor intervención gubernamental en el proceso de innovación se origina en las demandas de protección al consumidor y control de la contaminación.

– La teoría química progresa hasta el punto de que la mayor parte de la investigación química se realiza mediante cálculos por computadora más que mediante la experimentación real.

– La industria química se expande a la producción textil y a la fabricación de ropa mediante el de-sarrollo de una tela sintética no tejida.

– Las empresas químicas obtienen un menor retorno o realizan mayores inversiones en la investi-gación convencional.

La primera etapa en la utilización de estos eventos en un análisis de impacto cruzado es estimar las probabilidades iniciales de los eventos. Los especialistas, reconociendo que todos estos eventos son posibles e interactúan, pueden ofrecer las siguientes probabilidades:

EventoProbabilidad de que

ocurra para el año 2000

1 El uso de plásticos aumenta seis veces 0,15

2 Mayor intervención gubernamental en la innovación 0,20

3 La investigación química se realiza por computadora 0,25

4 La industria química se expande a los textiles 0,10

5 Menor retorno respecto de la investigación convencional 0,20

Figura 157: Probabilidad de eventos

El próximo paso es estimar las probabilidades condicionales. En este paso, se diseña una matriz simi-lar al Cuadro 4. Cada celda de la matriz representa la respuesta a la pregunta: “Si ocurre el evento x, ¿cuál es la nueva probabilidad del evento y?” Por ejemplo, la primera celda completa de la primera fila de la matriz contiene la nueva probabilidad del evento 2 dada la ocurrencia del evento 1. Así, la pre-gunta respondida aquí es, “Si el uso de plásticos en el transporte y la construcción aumenta seis veces (evento 1), ¿cuál es la posibilidad de una mayor intervención gubernamental en el proceso de innova-ción originado en la demanda de protección al consumidor y control de la contaminación (evento 2)?”.

*Ejemplo extraído de la sección Nº 10 de la publicación Futures Research Methodology, Versión 1.0, de Jerome C. Glenn, Editor, publicada por el Millennium Project del American Council for the United Nations University, Washington, USA, 1999. Traducción al español: Cuerpo de Traductores de la Biblioteca del Congreso de la Nación – Argentina.

251

C11

Dado que el aumento en el uso de los plásticos probablemente aumente la demanda de protección al consumidor y de control de la contaminación, la ocurrencia del evento 2 será más probable que en el cálculo inicial (0,20) si ocurre el evento 1. De este modo, podemos considerar que la nueva proba-bilidad del evento 2 será de 0,30, si ocurre el evento 1.

Si este evento ocurreProbabilidad

inicial para 19851 2 3 4 5

– El uso de plásticos aumenta seis veces 0,15 0,30 0,25 0,10 0,15

– Más intervención gubernamental en la innovación

0,20 0,10 0,35 0,07 0,40

– Investigación química por computadora 0,25 0,15 0,20 0,15 0,05

– La industria química se expande a los textiles

0,10 0,15 0,25 0,25 0,15

– Menor retorno respecto de la investigación convencional

0,20 0,15 0,15 0,50 0,20

Figura 158: Ejemplo de matriz de probabilidad condicional

Dado que las influencias mutuas de los eventos estaban incluidas en los cálculos de la probabilidad inicial, ahora esta opinión debe analizarse para probar su coherencia con las probabilidades iniciales. Utilizando la ecuación 5 y las probabilidades de los eventos 1 y 2, podemos observar que los límites a la probabilidad condicional del evento 2, dado el evento 1, son 0,0 y 1,00. De este modo, no existen problemas respecto de la opinión de 0,30 para la probabilidad del evento 2, dado el evento 1. De manera similar, se completa toda la matriz. La próxima tarea será especificar la política o las evalua-ciones de sensibilidad a fin de correrlas con la matriz. En este caso, podríamos desear conocer el efecto sobre los demás eventos si ocurre el evento 3 (uso de computadoras para la mayor parte de las investigaciones químicas). De este modo, se realizaría una evaluación asignando la probabilidad de 1,0 al evento 3 y corriendo nuevamente la matriz. Se realizaría una nueva evaluación para analizar la sensibilidad de los eventos respecto del evento 2 (mayor intervención gubernamental en el proceso de innovación). Estas evaluaciones se indican a continuación:

EventoProbabilidad

inicialPrueba de la probabilidad

Probabilidad final Cambio

1 0,15 0,15 0,14 -0,01

2 2 0,20 0,20 0,00

3 0,25 1,00 1,00 0,00

4 0,10 0,10 0,12 0,02

5 0,20 0,20 0,13 -0,07

Figura 159: Evaluación de ocurrencia del evento 3

252


EventoProbabilidad

inicialPrueba de la probabilidad

Probabilidad final Cambio

1 0,15 0,15 0,13 -0,02

2 0,20 1 1 0,00

3 0,25 0,25 0,30 0,05

4 0,10 0,10 0,09 0,01

5 0,20 0,20 0,29 0,09

Figura 160: Evaluación de sensibilidad del evento 2

De este modo, si el evento 2 ocurriera, la consecuencia más importante sería un aumento de la proba-bilidad del evento 6, del 20% al 29%. En efecto, en este ejemplo observamos un pequeño escenario.

11.3.1.6. Evaluación de la urgencia de los riesgos (Risk urgent assessment)

No todos los riesgos exigen el mismo tratamiento, algunos tendrán prioridades sobre otros, con lo cual es importante conocer cuáles son los riesgos que exigen respuestas a corto plazo y una dedicación urgente. Cuando nos encontramos con una lista importante de riesgos es imprescindible disponer de indicadores de prioridad que indicarán el tiempo de respuesta adecuado a los riesgos. La evaluación de la urgencia de respuesta a un riesgo puede estar asociada con la calificación del riesgo, la cual se determina a partir de la matriz de probabilidad e impacto (véase también sección 11.3.1.1) para obtener una calificación final de la severidad y el tiempo de respuesta.



11.4. Análisis cuantitativo de riesgos (proceso que corresponde a la fase de planificación del proyecto)

El objetivo de la cuantificación de los riesgos es establecer una forma de organizar los riesgos en orden de prioridad. Esto es importante porque, en muchos proyectos, no habrá tiempo o recursos financie-ros disponibles para afrontar todos los riesgos identificados.

Los valores cuantitativos pueden ser aplicados a los riesgos utilizando un análisis entre probabilidad e impacto. Normalmente, se utilizan los siguientes valores para determinar las probabilidades:

– Riesgo cero: No existe la posibilidad de que este riesgo pueda ocurrir.

– Riesgo bajo: La probabilidad de ocurrencia puede ser entre el 1 y el 40%.

– Riesgo medio: La probabilidad de ocurrencia puede ser entre en 41 y el 70%.

– Riesgo alto: La probabilidad de ocurrencia puede ser entre el 71 y el 99%.

253

C11

Este análisis cuantitativo se realiza a continuación del análisis cualitativo de riesgos y utilizando las es-calas obtenidas en la visión cualitativa. Básicamente, dentro de las funciones o aportaciones que reali-za el análisis cuantitativo está el análisis de las consecuencias que tienen esos riesgos y la asignación de un valor numérico para que ayude a la toma de decisiones de una forma más correcta y efectiva, aminorando de alguna forma la incertidumbre e intentando dar una visión más realista de la evolución del proyecto. Se usan, por lo tanto, para:

– Dar un valor numérico a los resultados del proyecto y sus probabilidades.

– Establecer las mejores decisiones cuando aparezca alguna contingencia.

– Valorar que probabilidades existen de lograr ciertos objetivos del proyecto.

– Establecer qué riesgos son los que necesitan una mayor atención.

Figura 161: Ciclo de dirección de riesgos: análisis

El estudio de impacto x probabilidad se realiza a través de la matriz que presentamos a continuación. El cruce de sus variables determinará las acciones preventivas adecuadas.

Impacto

Alto Medio Bajo

Alta Alto Alto Bajo

Media Alto Medio Bajo

Baja Medio Medio Bajo

Probabilidad



11.4.1.1. Técnicas de recopilación y representación de datos (Data gathering and representation techniques)

– Entrevistas: Véase también sección 5.1.1.1.

– Distribuciones de probabilidad: Acorde con el PMBOK®, las distribuciones continuas de probabilidad, utilizadas ampliamente en el modelado y la simulación (véase también sección 11.4.1.2), representan la incertidumbre de valores tales como las duraciones de las actividades del cronograma y los costes de los componentes del proyecto. Las distribuciones diferenciadas pueden emplearse para representar eventos inciertos, como el resultado de una prueba o un posible escenario en un árbol de decisiones.

254


11.4.1.2. Análisis cuantitativo de riesgos y de modelado (Quantitative risk Analysis and modeling)

Puede ser realizado a través de las siguientes técnicas:

– Análisis del valor monetario esperado: Acorde con el PMBOK®, el análisis del valor monetario esperado (expected monetary value) es un concepto estadístico que calcula el resultado prome-dio cuando el futuro incluye escenarios que pueden ocurrir o no (es decir, análisis bajo incertidum-bre). El valor monetario esperado de las oportunidades se expresará, por lo general, con valores positivos, mientras que el de los riesgos será negativo. El valor monetario esperado requiere una suposición de neutralidad del riesgo, que no se trate de una aversión al riesgo ni de una atracción por éste. El valor monetario esperado para un proyecto se calcula multiplicando el valor de cada posible resultado por su probabilidad de ocurrencia, y sumando luego los resultados.

– Modelado y simulación: Acorde con el PMBOK®, una simulación de proyecto utiliza un modelo que traduce las incertidumbres detalladas especificadas del proyecto en su impacto potencial sobre los objetivos del mismo. Las simulaciones iterativas se realizan habitualmente utilizando la técnica Monte Carlo. En una simulación, el modelo del proyecto se calcula muchas veces (mediante iteración) utilizando valores de entrada (por ejemplo, estimaciones de costes o dura-ciones de las actividades) seleccionados al azar para cada iteración a partir de las distribuciones de probabilidad para estas variables. A partir de las iteraciones, se calcula una distribución de probabilidad (por ejemplo, el coste total o la fecha de conclusión). Para un análisis de riesgos de costes, una simulación emplea estimaciones de costes. Para un análisis de los riesgos relativos al cronograma, se emplean el diagrama de red del cronograma y las estimaciones de la duración.





11.4.1.5. Análisis del árbol de decisiones (Decision tree analysis)

Esta herramienta permite que se desglose una condición en varias acciones, determinando las pro-babilidades de que ocurra y sus resultados, ayudando al Project Manager a elegir la decisión más adecuada para avanzar en alguna fase determinada de un proyecto.

El árbol de decisiones se dibuja sobre un plano horizontal, con la raíz del árbol al lado izquierdo del pa-pel y las ramas hacia la derecha. Esto permite describir las condiciones de acciones sobre las ramas.

Un árbol de decisiones empieza con la decisión que tienes tomar. Esta decisión es representada por un cuadrado (nodo de decisión). Conforme avance el árbol, otros nodos podrán aparecer.

Figura 163: Nodo de decisión

Desde este nodo salen las ramas que representan las opciones que tenemos para elegir. Si una de las opciones es un evento incierto, se dibujará un círculo. Si el la opción resulta en otra decisión, en-tonces se dibujará otro cuadrado. Si acaso se ha encontrado la solución, se dejará la rama en blanco.

Figura 164: Primeras ramas del árbol de decisiones

1

A

1

2

255

C11

De los círculos salen las ramas que representan los posibles resultados provenientes de eventos incier-tos sobre los que no se tiene control. En cada línea se describen los resultados que se pueden obtener.

Figura 165: Primeras ramas del árbol de decisiones

Los círculos de eventos inciertos, los cuadrados de decisiones y las ramas correspondientes seguirán desarrollándose hasta que se llegue a la decisión más adecuada.

Figura 166: Escenarios

La secuencia temporal de un árbol de decisiones se desarrolla de izquierda a derecha. Las ramas que llegan a un nodo desde la izquierda ya ocurrieron. Las ramas que salen hacia la derecha todavía no.

Siempre que se dibuje un árbol de decisiones es importante distinguir entre las condiciones y las acciones. Para este propósito, según he explicado anteriormente, el uso de un nodo cuadrado indica una decisión y un nodo redondo representa una condición, tal y como se representa en la figura 166. Una forma sencilla de interpretar un árbol de decisiones es tener en cuenta el círculo significa “si”, mientras que el cuadrado significa “entonces”.

Dado que quien toma las decisiones controla las ramas que salen de cada nodo de decisión, se elige la rama que resulte en el mayor valor esperado. Se van tachando todas las ramas que no sean se-leccionadas y se prosigue el análisis hacia la derecha del árbol, hasta seleccionar la primera decisión.

A

1

resultado 1

resultado 2

resultado 3

resultado 1

resultado 2

resultado 3

B

A

B

C

escenario A

escenario B

escenario C

escenario D

escenario E

escenario F

escenario G

escenario H

escenario I

escenario J

escenario K

D

256


Evaluando el árbol de decisiones

Terminada la confección del árbol, llega el momento de evaluar financieramente su decisión. Para ello, se asigna un valor orientativo para cada resultado posible. De esta forma, será posible llegar al coste de una determinada decisión. Esta evaluación empieza estimando una probabilidad para cada resul-tado proveniente de un evento posible (los círculos). Una vez que se estime todos los valores posibles, el árbol tendrá este aspecto:

Figura 167: Evolución del árbol de decisiones

Realizando los cálculos

Una vez designadas las probabilidades y los valores financieros de cada resultado, llega el momento de empezar a calcular el valor definitivo que facilitará la toma de una decisión. Para llegar al resultado financiero de una decisión, se multiplica el valor de un evento incierto (los círculos) por su probabilidad:

Opción A

0,5 (probabilidad del escenario A) x 20.000 (valor) = 10.000

0,3 (probabilidad del escenario B) x 18.000 (valor) = 5.400

0,2 (probabilidad del escenario C) x 12.000 (valor) = 2.400

Total: 17.800

A

B

C

20.000

0,30,5

0,2

0,2

0,8

0,30,1

0,6

18.000

12.000

8.000

12.000

7.500

20.000

8.600

escenario A

escenario B

escenario C

escenario D

escenario E

escenario F

escenario G

escenario H

desarrolo con personal contratado

desarrollo con personal propio

vend

er so

ftwar

e pro

pio

revender un software de mercado software nacional

0,30,4

0,3

3.000

10.000

4.000

escenario I

escenario J

escenario K

D

software importado

257

C11

Opción B

0,2 (probabilidad del escenario D) x 20.000 (valor) = 4.000

0,8 (probabilidad del escenario E) x 8.600 (valor) = 6.880

Total: 10.680

Opción C

0,1 (probabilidad del escenario F) x 8.000 (valor) = 800

0,3 (probabilidad del escenario G) x 12.000 (valor) = 3.600

0,6 (probabilidad del escenario H) x 7.500 (valor) = 4.500

Total: 8.900

Opción D

0,4 (probabilidad del escenario I) x 3.000 (valor) = 1.200

0,3 (probabilidad del escenario J) x 10.000 (valor) = 3.000

0,3 (probabilidad del escenario K) x 4.000 (valor) = 1.200

Total: 5.400

Figura 168: Resultados del árbol de decisiones

A

B

C

20.000

0,30,5

0,2

0,2

0,8

0,30,1

0,6

18.000

12.000

8.000

12.000

7.500

20.000

8.600

escenario A

escenario B

escenario C

escenario D

escenario E

escenario F

escenario G

escenario H



vend

er so

ftwar

e pro

pio

revender un software de mercado

8.900

0,1 x 8.000 = 8000,3 x 12.000 = 3.6000.6 x 7.500 = 4.500

10.880

0,2 x 20.000 = 4.0000.8 x 8.600 = 6.880

17.800

0,5 x 20.000 = 10.0000,3 x 18.000 = 5.4000.2 x 12.000 = 2.400

software nacional

0,30,4

0,3

3.000

10.000

4.000

escenario I

escenario J

escenario K 5.400

0,4 x 3.000 = 1.2000,3 x 10.000 = 3.0000.3 x 5.000 = 1.200

D

software importado

258


Cuando se está evaluando una decisión se escribe el coste estimado en la línea de decisión. Se res-ta el coste estimado de los valores de cada resultado encontrado anteriormente. Esta operación resul-tará en la ganancia obtenida en cada decisión. Los costes estimados serán siempre los costes futu-ros, no se consideran los costes pasados. Después de calcular la ganancia de cada decisión, se elegirá la opción que tiene mejor ganancia.

Figura 169: Resultados del árbol de decisiones

En la figura 169 la ganancia calculada para vender un software propio a través de desarrollo con per-sonal propio es de 17.800 euros. Se ha estimado un coste orientativo de 9.000 euros lo que resultaría en una ganancia liquida (descontando los costes) de 8.800 euros. Analizando las otras opciones, se concluye que en el caso ilustrado en este ejemplo, la mejor decisión en términos financieros es vender un software propio, desarrollado con el personal en plantilla.

Por otro lado, si elegimos revender un software de mercado y decidimos hacerlo con un software importado, tendríamos casi la mitad del coste, pero la ganancia sería bastante menor.

*Nota del autor: El árbol de decisiones es un método eficaz de decisión porque:

– Nos permite analizar íntegramente las posibles opciones obtenidas de cada decisión.

– Nos posibilita estimar probabilidades y valores retornos financieros.

– Nos ayuda a tomar decisiones basadas en números con gran margen de acierto.



vend

er so

ftwar

e pro

pio

revender un software de mercado 8.900

10.880

17.800

software nacional

5.400

software importado

coste: 9.000

coste: 6.500

coste: 7.000

coste: 4.900

17.800 - 9.000 = 8.800

10.880 - 6.500 = 4.380

8.900 - 7.000 = 1.900

5.400 - 4.900 = 500

8.800

1.900

259

C11

11.4.1.6. Simulación de Montecarlo (Montecarlo method)

La simulación de Montecarlo es un método no determinístico o estadístico numérico usado para aproximar expresiones matemáticas complejas y costosas de evaluar con exactitud. Tiene este nom-bre en referencia al Casino de Montecarlo, por ser la “capital europea del juego de azar” al ser la ruleta un sencillo generador de números aleatorios.

Ha sido desarrollado por Stanislaw Ulam y John Von Neumann. Mientras se recuperaba de una enfer-medad, Ulam jugaba al solitario y se le ocurrió que resultaba mucho más sencillo tener una idea del resultado general del solitario haciendo pruebas múltiples con las cartas y contando las proporciones de los resultados que computar todas las posibilidades de combinación formalmente. La idea con-sistía en probar con experimentos mentales las miles de posibilidades, y en cada etapa, determinar por casualidad, por un número aleatorio distribuido según las probabilidades, qué sucedería y totalizar todas las posibilidades y tener una idea de la conducta del proceso físico.

Tras una etapa inicial de investigación, John von Neumann y Stanislaw Ulam refinaron esta ruleta rusa y los métodos “de división” de tareas. Sin embargo, el desarrollo sistemático de estas ideas tuvo que esperar al trabajo Herman Kahn en 1948.

En el ámbito del Project Management, esta técnica es aplicada en cualquier proceso que presente alguno grado de incertidumbre o donde hayan sido identificados determinados riesgos.

Por ejemplo, para ejecutar un determinado proyecto, es necesario identificar las actividades necesa-rias para su puesta en marcha, su secuencia lógica y su duración. Con estas informaciones se desa-rrolla un cronograma con todas las fechas de inicio y fin estimadas. Estas estimaciones normalmente no alcanzan el 100% de exactitud, debido a un cierto grado de incertidumbre, muy común en los proyectos. La técnica de Montecarlo crea una simulación que describe cómo un determinado proceso generará determinados resultados. Esta simulación no devuelve una respuesta única, sino una gama de respuestas posibles y la probabilidad de cómo cada una de estas respuestas se producirá.

11.5. Plan de respuesta al riesgo (proceso que corresponde a la fase de planificación del proyecto)

Una vez identificados y priorizados los riesgos, la planificación de respuesta al riesgo desarrolla op-ciones y determina acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto.

La planificación respuesta al riesgo es el proceso por el que podemos desplegar alternativas y selec-cionar acciones para disminuir la incertidumbre y el riesgo. Tienen que ser adecuadas a la importancia del riesgo, aplicadas en el momento adecuado, ser realistas, acordadas por todas las partes implica-das y con un coste efectivo en relación al riesgo.

Figura 170: Ciclo de dirección de riesgos: planificación

260


Todos los eventos de riesgo identificados afectarán al proyecto de alguna manera si llegan a concre-tizarse. En las secciones anteriores, hemos conocido las herramientas para identificar los riesgos, se han evaluado dichos riesgos y determinado su probabilidad de ocurrencia e impacto.

Además, se han priorizado los riesgos según su importancia. Ahora es el momento de decidir cómo afrontarlos, de preparar un plan de respuesta a estos riesgos.

Las organizaciones y las personas tienen distintos comportamientos a la hora de afrontar un determi-nado riesgo. Existen por ejemplo, algunos patrocinadores que no se arriesgan en soluciones nuevas que fueron poco probadas, estos son conocidos como “conservadores”. Sin embargo, hay patroci-nadores que apuestan en nuevas ideas, por creer que al afrontar un determinado riesgo, y superarlo, estarán sacando partido de una oportunidad antes que otros. Son los considerados “agresivos”, aquellos que afrontan el riesgo a todo coste.

De la misma forma, hay Project Managers que toleran el riesgo más que otros. Mientras algunos son muy conservadores e intentan reducir el riesgo del proyecto aplazando fechas o ampliando su perso-nal técnico (a veces, generando más costes), otros son más agresivos, aceptan mejor los riesgos y, muchas veces, logran resultados espectaculares (asumiendo eventuales consecuencias).

Eso dependerá del carácter de cada individuo. En el caso de asumir un riesgo en un proyecto, gene-ralmente existen tres tipos de actitudes:

Figura 171: Tolerancia al riesgo

Todo dependerá del tipo de riesgo que se afronta, la probabilidad que pueda ocurrir y, principalmente, su impacto (negativo o positivo) en el proyecto. La dirección de riesgos cuantifica la probabilidad y el impacto de cada riesgo, ayudando el Project Manager a direccionar mejor sus estrategias.

261

C11


11.5.1.1. Estrategias para riesgos negativos o amenazas (Strategies for negative risks or threats)

Una vez que se realice un correcto análisis de los riesgos identificados, el siguiente paso es esta-blecer la estrategia para cada uno de ellos. Dependiendo del entorno y de la sensibilidad al riesgo, algunas organizaciones elegirán entre una u otra estrategia. Todo dependerá del tipo de riesgo, de la sensibilidad que la organización, de su capacidad financiera, alcance geográfico, recursos, entre otros factores. A continuación, y en las siguientes secciones, conoceremos las principales estrategias de respuesta a riesgos practicadas en el ámbito del Project Management.

Evitar

Evitar un riesgo, en pocas palabras, significa “no aceptarlo”. Al evitar un riesgo, se elimina el motivo que provoca el problema. Eso puede conllevar a cambiar completamente las acciones determina-das en el plan original. Un claro ejemplo de evitar un riesgo es el caso de los autobuses espaciales. Cuando las condiciones meteorológicas no lo permiten, normalmente su lanzamiento es abortado. Eso conlleva en retrasos en las misiones espaciales programadas, pero en cambio, podrá preservar la vida de los astronautas.

Transferir

Otra forma de reducir la exposición a un riesgo, es transferir el riesgo a terceros. Un caso clásico de transferencia de riesgos es la subcontratación de empresas para realizar un determinado trabajo. Esta estrategia no elimina el riesgo, pero transfiere la responsabilidad a otros. En estos casos, normalmente se establece un contrato con compensaciones financieras a la empresa que está asumiendo el riesgo por nosotros. La contratación de un seguro, es un ejemplo de transferencia de riesgo.

Prevenir

La prevención supone realizar una acción previa con el objetivo de reducir la probabilidad de ocurren-cia de una determinada incidencia. Para ello, es importante intentar identificar la causa de esta inciden-cia potencial y realizar las acciones correspondientes. Un ejemplo claro es la prevención de riesgos laborales, donde los trabajadores de obra utilizan elementos de seguridad con el fin de prevenir que ocurran accidentes.

Mitigar

Es una de las estrategias de respuesta a riesgos más utilizadas y que tiene como objetivo reducir los efectos negativos de una incidencia. Una planificación bien estructurada, la contratación de más per-sonal, la ampliación de la oferta de proveedores, la dedicación de más tiempo de pruebas, son formas de disminuir la probabilidad de ocurrencia de eventos de riesgo. La mitigación de riesgo conlleva a reducir su posibilidad de ocurrencia a niveles aceptables y de fácil administración. Mitigar un riesgo puede ser por ejemplo, poseer un amplio abanico de inversiones financieras. Personas que invierten sus ahorros en inmuebles, diferentes fondos de plazo fijo, acciones..., corren menos riesgo de sufrir con cualquier impacto negativo en la economía del país.

262


Aceptar

Aceptar un riesgo es simplemente, no hacer nada. Seguir los planes originales, asumir las consecuen-cias o tratar con ellas cuando ocurran. Es sin duda una estrategia agresiva. Sin embargo, el riesgo, muchas veces es una oportunidad. De la misma manera que aceptar un riesgo puede generar proble-mas, aceptarlos también podrá traer resultados importantes. De todas formas, normalmente se acepta un riesgo cuando su impacto es bajo. Si no es así no tiene sentido aceptarlo, como por ejemplo, si existe la posibilidad de poner en riesgo vidas humanas para llevar a cabo una determinada actividad.

Aceptar un riesgo no significa que no se actuará cuando un suceso ocurra. Pero se actuará solamen-te cuando dicho ocurra. En esta estrategia se encajan normalmente eventos de bajo impacto cuyos costes de corrección son más bajos que los costes de prevención.

Existen dos formas de aceptación del riesgo: aceptación activa y pasiva:

En la aceptación pasiva, el equipo del proyecto no realiza ninguna acción para afrontar el riesgo. Sim-plemente espera que este ocurra y a continuación desarrolla acciones para corregir sus efectos. Es una forma de gestionar pequeños e insignificantes eventos de riesgo cuyo coste de investigación son mayores que sus correcciones a posteriori. Por ejemplo, una empresa de refrescos decide realizar un concierto promocional en una región de playa en el verano, cuando las temperaturas son muy agradables y el riesgo de lluvia es mínimo. Aunque exista una posibilidad de lluvia, la empresa decide realizar el evento, sabiendo que para promocionar su producto, no hay otra estación más adecuada que el verano.

Cuando el Project Manager adopta una postura de aceptación activa, se desarrolla un plan de acción que es llevado a cabo cuando ocurra un suceso. Es una estrategia muy importante ya que podrá traer resultados más eficaces, una vez que es mejor buscar una solución planificada para ponerla en prác-tica cuando sea necesario, que buscar una solución correctora en el calor del momento, que muchas veces podrá ser la solución equivocada. Utilizando el ejemplo anterior, si en el día del concierto pro-gramado por la empresa de refrescos, cae una tormenta sobre la ciudad, la empresa tendrá reservada una inmensa carpa para poder acoger al público.

El desarrollo del plan de acción resultará en un plan de contingencia (descrito en la sección 11.5.1.3)

Acuerdos contractuales relacionados con los riesgos

Los acuerdos para transferencia de riesgos, tales como acuerdos para seguros, servicios y otros temas según corresponda, se establecen en el marco de las estrategias descritas anteriormente. Esto puede suceder como resultado de mitigar o transferir parte o toda la amenaza, o de mejorar o compartir parte o toda la oportunidad. El tipo de contrato elegido proporciona también un mecanismo para compartir los riesgos.

11.5.1.2. Estrategias para riesgos positivos u oportunidades (Strategies for positive risks or opportunities)

De las cuatro estrategias presentadas a continuación, tres son utilizadas sobre todo para el tratamiento de riesgos con impactos potencialmente positivos sobre el proyecto. La cuarta y última estrategia (acep-tar), se puede utilizar tanto para los riesgos negativos o positivos (tal y como explicado la sección anterior).

Explotar

Esta estrategia busca la eliminación de la incertidumbre asociada con un riesgo positivo, asegurando que la potencial oportunidad realmente llegue a concretizarse. Un ejemplo de explotación incluye la asignación de un equipo técnico muy experimentado que pueda ser capaz de reducir el tiempo de ejecución de una determinada tarea, ofreciendo un coste inferior a lo inicialmente planificado.

263

C11

Compartir

Compartir implica asignar todo o parte de la propiedad de la oportunidad a un tercero que reúna las capacidades necesarias para capturar esta oportunidad en beneficio del proyecto, como por ejemplo las uniones temporales de empresas que pueden establecerse con el objetivo de tomar ventaja de una determinada oportunidad, de modo que todos los involucrados se beneficien a partir de su implicación.

Mejorar

Esta estrategia es aplicada con el objetivo de aumentar y/o potencializar los eventuales impactos y/o beneficios de una oportunidad. La aplicación de fuerzas impulsoras adecuadas puede incrementar su probabilidad de ocurrencia. Por ejemplo, se puede mejorar el tiempo de ejecución de una determinada actividad, añadiéndole los recursos necesarios.

Aceptar

Aceptar una oportunidad consiste en tener la voluntad de tomar ventaja de ella si se presenta, pero sin buscarla de manera activa.

11.5.1.3. Plan de contingencia (Contingency plan)

Un plan de contingencia determina acciones específicas para atacar directamente factores de riesgo lla-mados “conocidos desconocidos” (knowns unknows). Son factores que sabemos que existen, pero no estamos seguros si ocurrirán. Por ejemplo, sabemos que los datos informáticos producidos durante el proyecto pueden ser afectados por un virus o un problema en el servidor. Es un riesgo que conocemos, pero no sabemos si realmente podrá ocurrir. El plan de contingencia determinará la puesta en marcha de copias de seguridad, para evitar cualquier pérdida de datos producida por una incidencia informática.

El plan de contingencia es un documento que debe estar listo en la fase de planificación del proyecto, mucho antes del proyecto entrar en la fase de ejecución. Este plan ayudará a planificar y coordinar las acciones adecuada de respuesta en tiempo.

11.5.1.4. Gestión de reservas (Reserve management)

Las reservas son como un “colchón” de recursos, que el proyecto dispone para hacer frente a un evento imposible de prever, o totalmente desconocido (unknowns unknowns). Las reservas podrán ser financieras, de tiempo, de recursos humanos o de maquinaria.

11.5.1.5. Gestión del riesgo residual (Residual risk Management)

Todas las estrategias definidas en las secciones anteriores son imprescindibles para una planificación adecuada de respuesta a los riesgos. No obstante, ningún control puede ofrecer una seguridad abso-luta, y por lo tanto, siempre quedará un algún grado de riesgo que en Project Management se conoce como “riesgo residual”. El concepto de riesgo residual es definido por el estándar para la seguridad de la información ISO/IEC 27001, en el apartado 3, término 3.9, como “el riesgo remanente que existe después de que se hayan tomado las medidas de seguridad”. En otras palabras, cualquier riesgo que permanezca, que no consiga ser eliminado, tras haber implantado un plan de respuesta de un riesgo se llama “residual”, y debería ser identificado y analizado como cualquier otro riesgo.

Un ejemplo de riesgo residual: En la edad media, las ciudades eran cercadas por murallas altas para evitar el asalto del ejército enemigo. Sin embargo, los administradores de estas ciudades deberían asumir el riesgo residual de que el enemigo pudiera contar con potentes armas de asedio, como las lanza piedras (o fundíbulos) que eran capaces no solo de destruir gruesas murallas como lanzar pro-yectiles sobre muros muy altos.

264


Es importante que la organización tenga en cuenta la probable existencia de un riesgo residual, por lo tanto, la primera acción de la organización es aceptar la posibilidad de existencia de un riesgo residual que necesitará de una respuesta adecuada si llega a producirse.

Figura 172: Gestión de Riesgo residual

La gestión de un riesgo residual es relativamente sencilla. Se deberá reconocer el riesgo residual como un nuevo riesgo a ser tratado y aplicarle las estrategias de respuestas que mejor le pueda hacer frente, eliminando sus consecuencias o mitigándolas lo máximo posible.

11.5.1.6. El plan B (Fallback plan)

Aunque se trata de una situación extremadamente rara, siempre cabe la posibilidad de que ocurra al-gún evento improbable cuyas acciones preventivas y correctivas, los planes de reserva y contingencia no sean suficientes para detener sus consecuencias. En casos como este, se suele realizar una ac-ción llamada fallback plan, que simplemente significa “retroceder”. Es una acción similar a la estrategia de “evitación” (véase también 11.5.1.1). Sin embargo, la estrategia de evitación implica en librarse de una determinada acción o circunstancia. El fallback plan, por otro lado prevé detener todo el plan. Esto suele ocurrir por dos motivos: 1. El proyecto no ha contado con una buena planificación. 2. Ha ocurri-do algún suceso que no ha sido previamente identificado o considerado. En la mayoría de los casos en que se utiliza el recurso del fallback plan, el proyecto no vuelve a reanudarse y es abandonado.

Durante la Segunda Guerra Mundial, el mando militar alemán desarrolló un plan para invadir la Gran Bretaña. Este plan fue bautizado de “Operación León Marino” (Unternehmen Seelöwe en alemán). La invasión no llegó a ejecutarse, si bien sus preparativos fueron muy intensos y la amenaza de invasión se mantuvo durante bastante tiempo Los planes de invasión de Rusia y el inicio de la misma hacen que Alemania decida abandonar definitivamente la operación.



11.6. Supervisión y control de riesgos (proceso que corresponde a la fase de control del proyecto)

La supervisión y control de riesgos es una importante labor de gestión que debe ser realizada conti-nuamente para detectar probables riesgos nuevos (sobre todo residuales – véase también sección 11.5.1.5) y/o la modificación de los riesgos previamente detectados. Durante la ejecución de este proceso se podrá apreciar que algunos riesgos perderán importancia, mientras otros se volverán más importantes. Por otro lado, algunos riesgos dejarán de existir y otros nuevos aparecerán.

RIESGOIDENTIFICADO

OPCIONES DERESPUESTA

REDUCIR

EVITAR

TRANSFERIR

ACEPTAR

¿RIESGORESIDUAL?

SÍ

FIN

NO

265

C11

Acorde con el PMBOK®, una supervisión y control eficaz de los riesgos, conlleva en poner en marcha las siguientes gestiones:

– Implementar estrategias de respuesta a los riesgos identificados;.

– Rastrear dichos riesgos.

– Identificar y monitorizar los riesgos residuales.

– Evaluar la efectividad del proceso contra los riesgos a través del proyecto.

Otras finalidades del proceso monitorizar y controlar los riesgos es determinar si:

– Los supuestos del proyecto siguen siendo válidos.

– Los análisis muestran que un riesgo evaluado ha cambiado o puede descartarse.

– Se respetan las políticas y los procedimientos de dirección de riesgos.

– Las reservas para contingencias deben modificarse para alinearlas con la evaluación actual de los riesgos.

Figura 173: Ciclo de dirección de riesgos: supervisión y control

El proceso de supervisión y control de riesgos puede, además, implicar en la selección de estrategias alternativas, la puesta en marcha de un plan de contingencia (véase también sección 11.5.1.3), la implantación de acciones correctivas o en un escenario más drástico, una importante modificación en el plan de proyecto.

Los responsables por las estrategias de respuesta al riesgo deberán mantener el Project Manager constantemente informado acerca de su evolución y eficacia, sobre cualquier efecto anticipado o so-bre cualquier corrección necesaria para gestionar adecuadamente el riesgo.


11.6.1.1. Revaluación de los riesgos (Risk reassessment)

Un continuo proceso de monitorización, control y seguimiento de los riesgos nos puede proporcionar una identificación de nuevos riesgos, sobre todo los residuales (véase también sección 11.5.1.5), una revaluación de los riesgos existentes y el cierre de los riesgos obsoletos y/o eliminados.

Estas monitorizaciones deben ser programadas por el equipo de proyecto y pueden coincidir con las auditorías de riesgo (véase también la siguiente sección).

266


11.6.1.2. Auditorías de riesgos (Risk audits)

Las auditorías de riesgos son realizadas con el objetivo de examinar y documentar eficiencia de las es-trategias de respuesta adoptadas (véase también sección 11.5.1) y si estas están teniendo el efecto deseado. El Project Manager es el responsable de asegurar que las auditorías de riesgos se realicen con una frecuencia apropiada, según está definido en el plan de dirección de riesgos. Las auditorías de riesgos pueden incluirse durante reuniones de rutina de revisión del proyecto, o bien, pueden ce-lebrarse reuniones de auditoría específicas para este fin.

11.6.1.3. Análisis de variación (Variance and trend analysis)


11.6.1.4. Medición del desempeño técnico (Technical performance measurement)

La medición del desempeño técnico compara el grado de cumplimiento de los objetivos técnicos durante la ejecución del proyecto. Requiere la definición de determinadas medidas cuantificables que puedan ser utilizadas para comprar los resultados reales con los previstos. Las mediciones de des-empeño técnico pueden incluir:

– Pesos.

– Tiempos de transacción.

– Numero de piezas entregadas.

– Capacidad de almacenamiento

– Velocidad de procesamiento

– Otros.

Una desviación, como ofrecer una mayor o menor funcionalidad con respecto a la planificada, puede ayudar a predecir el grado de éxito que se logrará en cumplir con el alcance del proyecto y también puede mostrar el grado de riesgo técnico que enfrenta el proyecto.



11.6.1.6. Reuniones sobre el estado del proyecto (Status meeting)


11.6.1.7. Análisis de hipótesis o supuestos (Assumptions analysis)


C12Dirección de compras

268


12.1. Plan de compras y contratos (proceso que corresponde a la fase de planificación del proyecto)12.1.1. Técnicas y herramientas

12.2. Conducción de compras (proceso que corresponde a la fase de ejecución del proyecto)12.2.1. Ciclo de compras

12.3. Administración del contrato (proceso que corresponde a la fase de control del proyecto)12.3.1. Técnicas y herramientas

12.4. Cierre del contrato (proceso que corresponde a la fase de cierre del proyecto)12.4.1. Técnicas y herramientas

269

Algunas cosas en las que NO puedes pensar acerca de la dirección de compras

“Tenemos una relación profesional con este proveedor desde hace muchos años. Hacer un con-trato puede generar un ambiente de desconfianza”

Todos los proyectos, casi sin excepción, traen alguna clase de riesgo que debe ser asumida por to-dos los implicados en su puesta en marcha. El grado de confianza entre empresas o profesionales no puede ser un escollo para delimitar responsabilidades y formalizarlas en un documento. El contrato, por lo tanto, se convierte en el pilar básico de la relación entre una empresa y sus proveedores, de modo que las partes no han de escatimar esfuerzos para elaborar un documento que va a ser la única “ley” entre ellas. Es cierto que además del contrato, vienen por detrás toda una serie de normas de diverso rango y contenido, como pueden ser por ejemplo: Derecho de sociedades, LOPD, Propiedad Intelectual, Defensa de la Competencia, Consumidores y Usuarios, normas tributarias...); pero siempre será el contrato la fuente esencial de derechos y obligaciones entre las partes y el marco regulador del día a día de su relación comercial.

“No podemos ser flexibles. Hay que confeccionar un contrato que no proporcione ninguna mar-gen de maniobra al proveedor. Somos nosotros el cliente, con lo cual, las cláusulas las ponemos nosotros, sin discusión previa”

Bajo este comentario, nos encontramos en una situación donde el contratante incluye en el contrato algunas cláusulas que colocan al proveedor en una situación de inferioridad no justificada. Si bien es cierto que es el contratante que establece las “reglas del juego”, esta condición natural de “parte fuerte” no debería servir de argumento para imponer al proveedor obligaciones abusivas. El proveedor es una empresa como cualquier otra que, al formar parte de un proyecto, también asume riesgos, de manera que la imposición de restricciones excesivas podría provocar una serie de problemas, que sin duda, perjudicarían el buen avance de un proyecto. Un proveedor, es más que nada, un colaborador.

“¿No te parece exagerado hacerles un contrato de confidencialidad?”

La información generada por un proyecto (información relativa a los productos, servicios, clientes, proveedores, personal, método de trabajo, organización, estrategias empresariales, información eco-nómica y financiera...) se considera como uno de los principales activos de negocio de cualquier em-presa, y como tal, debe ser protegida adecuadamente con medios técnicos y legales, de forma que se evite, en la medida de lo posible, que cualquier persona física o jurídica pueda acceder, obtener, tratar, y/o difundir la información ilícitamente, causando perjuicios a cualquier empresa o profesional implicados en el proyecto.

270


Introducción

La dirección de compras trata de la obtención de recursos a partir de fuentes externas a la organiza-ción. Estos recursos pueden incluir entre otras cosas: mano de obra, equipos, maquinaria, softwares, servicios o una combinación de estos. La adquisición de un producto o servicio a partir de una em-presa externa conlleva a la confección, gestión y mantenimiento de contratos, que deberán asegurar la entrega de los productos o servicios dentro del plazo, coste y especificaciones contratadas.

Hoy día, las organizaciones, en búsqueda de principalmente lograr una reducción de costes, adop-tan la estrategia de contratar servicios externos que puedan cumplir con sus necesidades, en lugar de desarrollarlos internamente. El proveedor contratado, tiene la responsabilidad de garantizar que el producto y/o servicio entregado cumplirá con todas las exigencias establecidas por el cliente, o por un contrato de servicios, cuando corresponda.

Este capítulo no tratará de profundizar los aspectos legales acerca de los contratos de un proyecto, partiendo del principio que el Project Manager no posee el perfil de un abogado. Sin embargo, lograr un buen contrato exige mucha negociación, y negociar es una de las habilidades de un Project Ma-nager. Además, es muy importante que se conozcan los conceptos básicos y los detalles que son objeto de un tratamiento jurídico especifico del Project Management.

Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de la integración de un proyecto incluye procesos y actividades necesarias para los procesos de compra o adquisición de los productos, ser-vicios o resultados que es necesario obtener fuera del equipo del proyecto. Son ellos:

– Plan de compras y contratos.

– Conducción de compras.

– Administración del contrato.

– Cierre del contrato.

12.1. Plan de compras y contratos (proceso que corresponde a la fase de planificación del proyecto)

En todo proyecto se hace necesario determinar cuáles serán los componentes suministrados por un proveedor externo y cuáles serán los desarrollados por los recursos internos de la organización. Pla-nificar las adquisiciones es el proceso que consiste en documentar las decisiones de compra para el proyecto, especificando su gestión e identificando potenciales proveedores.

Este proceso también incluye la identificación de necesidades y cómo ellas podrán satisfacer ade-cuadamente los requisitos del proyecto, mediante la adquisición de productos y servicios fuera de la organización del proyecto. Además, este proceso también implicará la decisión de obtener apoyo externo, o si fuera el caso, qué adquirir de qué manera, en qué cantidad y cuando hacerlo.

Todas las decisiones acerca de contratar servicio externo o comprar material de proveedores, traen una serie de riesgos que deberán ser identificados, evaluados y tratados según la probabilidad e im-pacto de cada uno en el proyecto.


12.1.1.1. Base histórica de proyectos (Historical records)


271

C12

12.1.1.2. Análisis “comprar o hacer” (Make or buy analysis)

Cuando una organización decide comprar un producto o contratar un servicio de una empresa ex-terna, está tomando la decisión de no producir dichos productos o servicios a través de sus propios medios. En algunos casos, resulta una decisión difícil, sobre todo porque son muchas las variables que pueden determinar la mejor decisión. Normalmente, el principal criterio utilizado en la decisión de comprar o hacer es el financiero. No obstante, el análisis financiero no es suficiente para determi-nar qué es lo más viable, ya que, en algunos casos la empresa que ofrece el mejor coste, muchas veces no ofrece el mejor servicio. La organización, tiene que analizar otras variables importantes, como por ejemplo:

– Coste: Es solamente uno de los factores a considerar. La organización debe tener en cuenta los costes directos (el precio de la oferta entregada por el proveedor) y los indirectos (las horas de los que coordinarán y controlarán el trabajo desarrollado por el proveedor dentro de la organización y las horas dedicadas a la administración del contrato).

– Capacidad de recursos y materiales: ¿Cómo está la capacidad de producción de los recursos internos? Si no están al 100%, ¿Compensa agregarles otro trabajo? ¿La prioridad de este trabajo en la organización permite ocupar el 100% del tiempo de los recursos internos?

– Incremento de la plantilla: Si la decisión de la empresa implica la contratación de más recursos, ¿está la empresa preparada para hacerlo? ¿Los costes derivados de la contratación de personal compensan los beneficios obtenidos por el proyecto?

– Propiedad intelectual: La contratación de un proveedor puede significar en muchos casos darle acceso a informaciones internas de la organización, muchas veces confidenciales que pueden constituir en una ventaja competitiva frente a otras empresas. En muchas organizaciones, no reve-lar su conocimiento a terceros externos es un factor mucho más relevante que asumir los costes y los plazos de desarrollar un producto internamente.

La cuestión “hacer versus comprar” es una de las decisiones más difíciles y, a la vez, más impor-tantes en el proyecto, la figura 174 nos presenta las razones que nos pueden llevar a tomar una u otra decisión:

Figura 174: Hacer versus comprar

A favor de hacer

A favor de comprar

Inestabilidad del suministro.

Calidad deficiente del suministro.

Mantener el proceso en secreto.

Tener instalaciones sin uso.

Falta de capital.

Traspaso del riesgo al proveedor.

Falta de experiencia.

Selección más amplia.

272


Una de las razones que más relevantes que llevan a las empresas a tomar la decisión de comprar es su falta de experiencia en producir el producto y/o el servicio deseado. Intentar desarrollarlo interna-mente podrá provocar una perdida importante de tiempo y un incremento desnecesario de costes. Además, es muy probable que la empresa no logre alcanzar el mismo nivel de calidad de los produc-tos ofertados por empresas externas con más experiencia. La organización debe por lo tanto, enfo-carse en lo que mejor hace y dejar lo demás a empresas externas especializadas.

Por otro lado, el hacer implica poseer la propiedad intelectual y los derechos de propiedad del pro-ducto, lo que, indudablemente, constituye una importante ventaja competitiva frente a la competencia.

12.1.1.3. Análisis del árbol de decisiones (Decision tree analysis)




12.2. Conducción de compras (proceso que corresponde a la fase de ejecución del proyecto)

Este proceso consiste en desarrollar todo el ciclo de compras: Preparar las solicitudes, obtener res-puestas de los vendedores, seleccionar un vendedor y adjudicar un contrato. Se deberá aplicar unos criterios de selección definidos previamente a fin de seleccionar los proveedores adecuados para el objeto que se va a desarrollar.

12.2.1. Ciclo de compras

12.2.1.1. Preparación y solicitud de propuestas

Es el proceso que consiste en preparar la documentación necesaria para el proceso de solicitud de propuestas.

La contratación de los proveedores de los proyectos se realiza normalmente a través del departamen-to de compras de la empresa, a pedido del Project Manager. En algunos casos, la contratación es hecha directamente por el propio Project Manager, sin intermediarios.

El proceso de selección de los proveedores consiste básicamente en solicitar propuestas a los po-tenciales proveedores y analizarlas. Hay casos en que la empresa contratante prefiere trabajar con un determinado proveedor, sobre todo por los buenos servicios prestados en proyectos anteriores. De hecho, muchas empresas tienen una cartera de proveedores fijos que son convocados siempre que hay la necesidad de contratar sus servicios. No obstante, no es común, ni siquiera recomendable, so-licitar un presupuesto a una única empresa. Normalmente, se solicitan por lo menos tres presupuestos de diferentes proveedores para de esta forma, poder realizar una valoración más amplia y acceder a la mejor oferta.

273

C12

Figura 175: Ciclo del proceso de compras

12.2.1.2. Preselección de los proveedores

La preselección de proveedores es una fase muy importante en el proceso de contratación, teniendo en cuenta, de que la empresa ganadora, saldrá de este listado, y por ello, es importante realizar una preselección utilizando unos criterios que nos puedan asegurar una elección correcta.

La forma más correcta de hacerlo, es manteniendo un registro de las empresas con las que ha trabaja-do en proyectos anteriores y que son preferidas a las demás, por criterios objetivos, como por ejemplo:

– Capacidad financiera.

– Estructura.

– Disponibilidad de recursos.

– Evidencias de calidad.

– Comportamiento y experiencia en proyectos anteriores.

Se pueden incluso añadir otros criterios para refinar mejor los resultados. Estos criterios son libres y deberán ser utilizados solo los más apropiados en cada organización o en cada proyecto, dependien-do de su naturaleza.

12.2.1.3. Tipos de respuesta

Se puede responder a una petición, utilizando un documento especifico de respuesta. Los provee-dores interesados en ofrecer sus servicios a un determinado proyecto podrán responder utilizando el documento apropiado, que pueden ser:

– CIR – Contractor initial response: Es la respuesta inicial del contratista que dará lugar a las ne-gociaciones posteriores.

– Propuesta económica: Es la respuesta a la solicitud de cotización.

– Propuesta económica y de ejecución: Es la respuesta a la solicitud de propuesta.

– Respuesta punto por punto: Es la respuesta detallada a todos los puntos recogidos en las es-pecificaciones del cliente.

Documentos deAdquisiciones

SOW

ProveedorPotencial

ProveedorPotencial

ProveedorPotencial

SOLICTUD DEPROPUESTA



Evaluación yselección depropuestas

ProveedorElegido

Documentos deAdquisiciones

274


12.2.1.4. Licitaciones o convocatorias

Existen organizaciones que hacen una especie de licitación, en que el proveedor será elegido en función de puntuaciones establecidas por la empresa contratante, como el ejemplo a continuación:

La empresa Alfa PC necesita implantar en sus oficinas un sistema de telefonía más moderno. Como no disponían de referencias de ningún proveedor especifico, decidieron hacer una convocatoria que será estructurada bajo el siguiente reglamento:

– Solicitud y Recepción de Propuestas: La empresa Alfa PC solicitará a los proveedores interesa-dos una propuesta de implantación de un nuevo sistema de telefonía. Recibidas las propuestas, la empresa Alfa PC, asignará un equipo que se encargará de comprobar el cumplimiento de los requisitos exigidos y procederá a remitir a la Junta de Valoración únicamente las propuestas que cumplan exactamente con los requisitos establecidos. (Esta Junta de valoración puede ser com-puesta por el Project Manager, un representante del departamento de compras y departamento financiero, el líder técnico o cualquier integrante del equipo que la empresa considere importante).

– Valoración de Propuestas: En esta fase, la junta de valoración realizará un detallado análisis de las propuestas recibidas y decidirá cual es la propuesta que mejor atiende a la solicitud del servi-cio, a través de una puntuación numérica (que normalmente es de 1 a 5 puntos). La valoración de las propuestas se realiza teniendo solo en cuenta la propuesta técnico–económica aportada y la documentación técnica solicitada. Para que la valoración sea la más neutral posible y no favorezca una determinada empresa, las propuestas no contendrán identificación ni referencia alguna a la empresa, a los efectos de realizar una valoración ciega.

– Elección de la empresa adjudicada: La empresa que obtenga la mayor puntuación será la ele-gida para que manifieste por escrito su aceptación de la propuesta provisional de adjudicación y para que presente la documentación acreditativa.

– Una vez comprobada por la Junta de Valoración la conformidad de la documentación presentada, se procederá a la formalización de la relación contractual mediante la firma de un contrato entre Alpha PC y la empresa adjudicataria. A los restantes participantes se les comunicará su no adju-dicación formalmente por escrito.

12.2.1.5. Criterios de valoración

Según lo explicado anteriormente, cuando se solicita una propuesta para la adjudicación y contrata-ción de una empresa para la ejecución de un determinado servicio, se establece una puntuación que definirá el eventual ganador de la licitación. Los criterios de valoración normalmente son los siguientes:

– Cumplimiento con los requisitos establecidos: Las propuestas enviadas deberán explicar de forma detallada, como se ejecutará el servicio solicitado, especificando, cuando necesario, el tipo de componentes, equipos o procedimientos que serán utilizados.

– Experiencia acreditada en el servicio contratado: Las empresas participantes han de acreditar esta experiencia facilitando un listado de empresas a las que le han realizado este servicio. Se valorará el número de empresas aportadas con un máximo de puntos.

– Certificaciones de calidad general de la empresa: Se valorará que las empresas presentadas posean certificados generales de calidad (ISO 9000, ISO27001, ISO14000, etc.). La acreditación de estar en posesión y vigencia de alguna de las certificaciones garantiza la obtención de la máxi-ma puntuación. El no poseer alguno de estos certificados implicará la no obtención de puntuación en este criterio.

– Propuesta económica ajustada al cumplimiento de los pliegos de prescripciones técnicas: Se otorgará la máxima puntuación a las ofertas que ofrezcan las mejores condiciones económicas.

275

C12

La tabla que viene a continuación ilustra un ejemplo de valoración y puntuación de las empresas participantes:

Requisitos P* Proveedor 1 Proveedor 2 Proveedor 3

Capacidad financiera 10 4 3 3

Infraestructura 5 3 2 2

Disponibilidad de recursos 10 3 2 5

Evidencias de calidad 20 4 3 5

Experiencia 10 3 3 2

Resultado 195 150 210

P* = ponderación (Escala de valores de 1 a 5)

Figura 176: Tabla de criterios de valoración

Normalmente, el proceso de decisión de adjudicación de un contrato puede ser complementado con otras evaluaciones, como por ejemplo, auditorías de procesos de calidad y/o comprobación de los medios físicos y humanos para cumplir con los requisitos del proyecto.

12.2.1.6. Adjudicación del contrato

Una vez tomada la decisión de adjudicación del contrato (punto anterior), se comunica formalmente a la empresa adjudicataria y se convoca una reunión para la confección del contrato de prestación de servicios.

12.2.1.7. Confección del contrato

Un contrato es un acuerdo legal que declara las partes implicadas, su objeto y las cláusulas que especificarán los derechos y deberes de cada involucrado. Un Project Manager suele prestar más atención en el alcance del proyecto descrito en el contrato, sus plazos y costes asociados. No obs-tante, es importante que se observe también los aspectos legales, sobre todo en lo que se refiere a la propiedad de los servicios y productos desarrollados.

Un contrato debe contener como mínimo cinco elementos:

– Oferta: El contrato debe contemplar una oferta en que la empresa contratante conoce el precio y las características del servicio ofertado.

– Consideración: El contratante y el contratado consideran justo el intercambio. La contratante recibe los servicios y la otra el importe acordado.

– Capacidad: Las partes involucradas debe ser capaces de contratar. La empresa contratada es capaz de proveer el servicio contratado y la empresa contratante tiene la capacidad de pagar por el servicio realizado.

– Aceptación: La empresa contratante debe aceptar el precio y las condiciones ofrecidas en el contrato.

– Legalidad: Ambas partes involucradas deben recoger y pagar los tributos correspondientes.

276


Los contratos pueden asumir muchas formas distintas, sin embargo en el ámbito del Project Mana-gement los contratos más comunes son los siguientes:

– Contrato de precio fijo (Fixed–price): Este contrato puede tener las siguientes variaciones:

∙ Precio fijo o suma global (Fixed–price or lump–sum – FP)

∙ Precio fijo más honorarios con incentivos (Fixed price with incentives – FPI)

∙ Precio fijo con ajuste económico (Fixed price with economic price adjustment – FPEA)

∙ Precio fijo redeterminable (Fixed price redeterminable – FPR)

– Contrato de precio variable (Cost–reimbursable): Este contrato puede tener las siguientes variaciones:

∙ Coste más cuota fija (Cost plus fixed fee – CPFF)

∙ Coste más incentivo (Cost plus incentive fee – CPIF)

∙ Coste más cuota premio (Cost plus award fee – CPAF)

∙ Coste más porcentaje del coste (Cost plus percentage of cost – CPPC)

– Contrato a tiempo y material (Time & material contract): Es un tipo de contrato que no tiene un final claramente definido, porque el valor total del contrato no se define en el momento de su adjudicación.

– Garantías: Aunque la organización cuente con un proceso rígido de selección de proveedores y con un departamento jurídico capaz de confeccionar contratos muy completos, aún existe el riesgo de que el proveedor no entregue el servicio contratado según lo especificado, sea por al-gún problema ajeno, por incapacidad o por mala fe. Para mitigar este riesgo, todo contrato debe contener una cláusula de garantía.

12.3. Administración del contrato (proceso que corresponde a la fase de control del proyecto)

El proceso de administración del contrato comprende el periodo establecido desde la firma del este hasta su extinción. En este proceso, el Project Manager buscará asegurar que las partes cumplan lo estipulado en el contrato. Este proceso podrá incluir:

– Supervisar la correcta y adecuada ejecución del plan de proyecto.

– Asegurar el cumplimiento de los cronogramas.

– Evaluar el desempeño de la empresa contratada.

– Aceptar y pagar de facturas.

– Asegurar y controlar de la calidad.

– Poner en marcha acciones preventivas y correctoras.

– Supervisar las condiciones financieras del contrato.

– Aplicar las penalizaciones acordadas.

– Controlar los cambios del proyecto.

277

C12

Durante prácticamente todo el tiempo de administración del contrato, el Project Manager tendrá un enfoque más concentrado en la gestión de cambios del proyecto, puesto que, en cualquier contrato, los cambios son inevitables. Conforme el proyecto avance, podrán ocurrir incidencias o surgir presio-nes que forzarán alguna de las partes involucradas a cambiar algún aspecto que figure en el contrato, que puede ser de orden técnica, administrativa y/o jurídica. Independientemente del motivo, un cam-bio en una condición o cláusula contractual normalmente provocará también un cambio en el coste o plazo del proyecto, o incluso en el alcance del proyecto. Son circunstancias muy difíciles de prever y prevenir. No obstante, es posible administrar los cambios de forma en que se minimicen los impactos producidos por ellos, ejecutando las siguientes acciones:

– Verificar detenidamente las cláusulas contractuales que sufrirán cambios.

– Analizar detalladamente que aspectos del proyecto serán directamente afectados.

– Determinar las consecuencias de los cambios en los resultados del proyecto, sobre todo en sus plazos, costes, disponibilidad de recursos.


12.3.1.1. Sistema de control de cambios del contrato (Contract change control system)


12.3.1.2. Revisiones e informes de desempeño (Procurement performance reviews and reports)

Los informes de desempeño proporcionan a la dirección información sobre la efectividad del vendedor en el logro de los objetivos contractuales. Para monitorizar el desarrollo, tanto a nivel interno como externo, de los requisitos e indicadores del proyecto una buena metodología es el uso de indicadores claves de rendimiento (key performance indicators – KPI). Los KPI proporcionan un cálculo muy cer-tero del estado del proyecto. Los indicadores claves de rendimiento son una métrica de alto nivel de la efectividad y/o eficiencia que se usan como guía y control progresivo del rendimiento.

12.3.1.3. Inspecciones y auditorías (Inspection and audits)

Cuando una organización elige contratar una empresa externa para desarrollar un producto y/o ser-vicio, tendrá que tener en cuenta que no todo el proceso estará totalmente bajo su control. Para compensar esta debilidad, se realizan inspecciones y auditorías durante la ejecución del proyecto para comprobar, así, si el proveedor cumple con los requisitos establecidos. Para evitar conflictos entre la empresa contratante y la contratada, es fundamental que las inspecciones y auditorías estén contempladas en el contrato, previendo posibles consecuencias en la detección de eventuales in-cumplimientos o, incluso, fraudes.

Esta supervisión se realiza a lo largo de todo el proyecto y proporciona al equipo de dirección del proyecto una idea sobre el estado del proyecto e identifica cualquier área que necesite más atención.

El proceso completo de auditoría se encuentra ampliamente detallado en la sección 8.2.

278


12.3.1.4. Sistemas de pago (Payment systems)

Un sistema de pago contempla la puesta en marcha de un procedimiento controlado, que, entre otras cosas, deberá incluir la adopción de determinados criterios de aceptación para autorizar el pago al proveedor. Es decir, los pagos son procesados después de que una persona autorizada certifique que el trabajo es satisfactorio. Todos los pagos deben ser efectuados y documentados en estricto cumplimiento de los términos del contrato.

La administración del contrato también tiene un componente de gestión financiera que involucra el segui-miento de los pagos. Esto asegura que los plazos de pago definidos dentro del contrato se cumplan y que la compensación del proveedor se corresponda con sus avances, según lo establecido en el contrato.

Los pagos son algo muy relacionado con la aceptación del proyecto o alguna de sus fases. Es un factor crítico para ambas partes, es por ello que debe hacerse un buen seguimiento de las facturas, el proceso de pago y los resultados. Nadie debe eludir sus responsabilidades en este aspecto.

12.3.1.5. Administración de reclamaciones (Claims administration)

Aparte de las solicitudes de cambio aprobadas, también existen los cambios impugnados y los construc-tivos. Los cambios impugnados (reclamaciones, conflictos, apelaciones) son aquellos cambios solicita-dos respecto de los cuales el adquiridor y el proveedor no consiguen acordar la compensación corres-pondiente debido a los mismos. Las reclamaciones se documentan, se procesan, se supervisan y se gestionan a lo largo del ciclo de vida del contrato, en general, de acuerdo con los términos del contrato

Si las partes no resuelven por sí mismas una reclamación, puede ser necesario gestionarla de acuerdo con los procedimientos de resolución alternativa de conflictos establecidos en el contrato.

El acuerdo de todas las reclamaciones y conflictos mediante la negociación es el método más adecuado.

12.3.1.6. Sistema de gestión de registros (Record management system – RMS)

El RMS es un sistema de gestión de registros que es utilizado por el Project Manager para la gestión y correcta documentación y registro de los contratos del proyecto. Incluye un conjunto específico de procesos, funciones de control relacionadas y herramientas de automatización que deberán consoli-darse y combinarse en un todo, como parte del sistema de información del proyecto.

12.4. Cierre del contrato (proceso que corresponde a la fase de cierre del proyecto)

El cierre del contrato es una gestión administrativa que contempla verificar si todo el trabajo realizado y todos los productos entregados han sido aceptados formalmente. Incluye, además, la actualización de todos los registros para reflejar los resultados consolidados y el archivo con toda la documentación para su uso en el futuro.

El proceso de cierre contiene tareas tales como las presentadas a continuación:

– Cierre administrativo: Describe detalladamente todas las actividades, interacciones, roles y res-ponsabilidades relacionadas con el equipo del proyecto y todos los interesados en la ejecución de esta gestión.

– Verificación del alcance: Esta gestión pretende obtener la aceptación formal por parte de los intere-sados del alcance realizado y los entregables correspondientes. Esta gestión incluye, además, la revi-sión de los entregables para asegurarse de que cada uno de ellos ha sido completado correctamente.

279

C12

– Obligaciones posteriores: Antes de finalizar el contrato, es aconsejable revisarlo, para señalar aquellas áreas en las que alguna de las partes debe mantener unas responsabilidades posterio-res, como, por ejemplo:

∙ Licencias.

∙ Propiedad intelectual.

∙ Mantenimiento.

∙ Garantía.

∙ Actualizaciones.

∙ Nuevas versiones.

Una vez completados los trabajos previstos, empiezan las gestiones formales de cierre del contrato. En esta fase, se realiza la verificación final del producto o servicio desarrollado. Para asegurar que el contrato ha sido correctamente cumplido, es necesario realizar un chequeo general que contem-plará lo siguiente:

– Documentación: Esta documentación incluye informes, actas, manuales o cualquier otro registro que las partes involucradas consideren importante.

– Estado financiero: Es fundamental comprobar si el contrato tiene alguna deuda o pagos pen-dientes de realizar o cobrar.

– Verificaciones: El cliente realizará una especie de auditoría, y en caso necesario, en conjunto con un auditor independiente capacitado para certificar que el producto o servicio atiende a los requisitos establecidos contractualmente.

– Archivo: Toda la documentación generada en el proyecto deberá ser reunida, organizada y archi-vada para eventuales consultas.

– Aceptación formal: La empresa proveedora debe desarrollar un documento de aceptación formal para que el cliente lo firme y, con ello, formalice la aceptación de todos los servicios o productos entregados. Los requisitos de aceptación del cliente, normalmente son establecidos en el contrato.

En algunos tipos de servicios la documentación es, normalmente, la última entrega realizada por el proveedor (suele ocurrir frecuentemente cuando se trata de desarrollo de software). La aceptación final formalizada y los pagos correspondientes estarán normalmente vinculados a esta entrega.


12.4.1.1. Auditorías de la adquisición (Procurement audits)

Una auditoría de la adquisición es una revisión que realiza al proceso de adquisición, incluyendo su planificación y administración. Su objetivo es identificar éxitos o fracasos que merecen ser reconoci-dos para la preparación y gestión de contratos futuros.

280


12.4.1.2. Acuerdos negociados (Negotiated settlements)

En toda relación de adquisición, el acuerdo definitivo y equitativo de todos los asuntos, reclamaciones y controversias pendientes a través de la negociación es un objetivo fundamental. En los casos en que no es factible llegar a un acuerdo mediante la negociación directa, puede examinarse el empleo de algún método alternativo para la resolución de conflictos, incluyendo la mediación o el arbitraje. Cuando todo recurso falla, iniciar un litigio en los tribunales es la opción menos deseable.

12.4.1.3. Sistema de gestión de registros (Records management system)


Esta obra ha sido basada en la cuarta versión del PMBOK®. A Guide to the Project Management Body of Knowledge – PMBOK Guide) – Fourth Edition. Published by: Project Management Institute (www.pmi.org)

“PMI”, el logotipo de PMI, “PMP”, el logotipo de “PMP”, “PMBOK”, “PgMP”. “Project Management Journal”, “PM Network”, y el logotipo de PMI Today son marcas registradas de Project Management Institute Inc.

Agradecimiento especial a la versión traducida por Mónica Talledo Jiménez.

A continuación, se enumeran las principales fuentes bibliográficas utilizadas en la elaboración de este libro. Esta bibliografía incluye libros, algunos artículos en revistas y boletines especia-lizados, e Internet.

ALCUBILLA, Enrique Arnaldo. Enciclopedia Jurídica La Ley. Editorial La Ley. Grupo Wolters Kluwer, 2009.

ANBARI, F. Earned Value Project Management. Project Management Journal. 2003.

ARBOLEDA, G. Proyectos: formulación, evaluación y control. 5º edición, AC editores, Cali, Co-lombia. 2003.

AUSUBEL, D. P. The Psychology of Meaningful Verbal Learning. New York: Grune and Stratton, 1963.

AUSUBEL, D. P., NOVAK, J. D. and HANESIAN, H. Educational Psychology: A Cognitive View, 2nd ed. New York: Holt, Rinehart and Winston, 1978.

BALES, R. F. The equilibrium problem in small groups’. Knopf,ntro 1965.

BHUSAN, Navneet; KANWAL Rai. Strategic Decision Making: Applying the Analytic Hierarchy Process.Springer–Verlag, 2004.

BONABEAU, Eric. Don´t Trust your Gut, Harvard Business Review Vol. 81, nº 5, pags. 116–123. Harvard Business Publishing, 2003.

BONNER, H. Psychology of personality, Ronal, 1961.

BRIGHAM, Eugene F. Fundamentals of Financials Management. The Dryden Press, 1980.

BRIGHAM, Eugene F; GAPENSKI, Louis C. Financial Management. Editorial The Dryden Press, 1994.

Bibliografía

282


BRODERSEN, Kai. Las Siete Maravillas del mundo antiguo. Alianza Editorial, 2010.

BRONSON, R.; NAADIMUTHU, G. Operations Research. McGraw Hill Companies – Schaum’s Outline Series. 2nd edition, New York, USA. 1997.

BUDGE, E. A. Wallis. El libro egipcio de los muertos. Málaga, Editorial Sirio, 2007.

CHARVAT, Jason. Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Project. John Wiley & Sons, 2003.

CHARVAT, Jason. Project Management Nation: Tools, Techniques and Goals for the New and Prac-ticing IT Project Manager. John Wiley & Sons, 2002.

COOPER, Robert G. Portfolio Management for New Products. Perseus Books, 1998.

CROWSTON, W. and THOMPSON, G. Decision CPM: A Method for Simultaneous Planning, Scheduling, and Control of Projects. 1965.

DEUTSH, M. The resolution of conflict. New Haven Connesticut Yale University Press, 1973.

DINSMORE, Paul C. AMA The Handbook of Project Management. Amacon Books, 1993.

ERIKSSON, L; JOHANSSON, E; KETTANEH–WORD, N; WILKTRÖM, C y WOLD, S. Design of Experi-ments. Principles and Applications. Umetrics AB–Sweden, 2000.

FABRYCKY, Wolter J and BLANCHARD, Benjamin S. Systems Engineering and Analysis. Prentice Hall; 4 edition, 2005.

FABRYCKY, Wolter J. Analisis del Coste del Ciclo de Vida de los Sitemas. Isdefe, 1997.

FLEMING, Q.; KOPPELMAN, J. Earned Value Project Management. 2nd edition, Newtown. 2000.

FOLLIET, Joseph. El hombre social. Ensayo de Antropología social.

FONTENLA, E; Sallin–Kornberg E. Scenario Building with the ExplorMultitrade Model, in Commerce International et ModèlesMultinationaux. Económica, Paris, 1981.

FRAME, J. Davidson. Managing projects in organizations: how to make the best use of time, tech-niques, and people. Jossey–Bass Inc, 1995.

GERARDIN, Luciene. Previsión de la toma de decisiones por medio del análisis de los sistemas: análisis sistemático para prever futuros alternativos. ThompsonCSF. Francia, 1974.

GIDO Jack; CLEMENTS, James P. Administración Exitosa de Proyectos. Internacional Thomson Editores, 1999.

GISELA, M.A. The Sculpture and Sculptors of the Greeks. New Haven, Yale University Press. 1950.

GODET, M. Manuel de prospective stratégique. Dunod, Paris, 1984.

GOLDRATT. Eliyahut M. Critical Chain. North River Press; Illustrated edition, 1997.

GOLENKO, D. On the Distribution of Activity Time in PERT. The Journal of the Operational Research Society, 1988.

GORDON, Theodore STOVER, John. Análisis del impacto cruzado. Manual de investigación de fu-turos. Jib Fowles, Greenwood Press. 1978.

283

Bibliografía

GORDON T.H. Initial experiments with the Cross–Impact Matrix Method of Forecasting. Futures, 1968.

GORDON T.H. Integration of Forecasting Methods and the Fronteers of FuturesResearch. UN Mi-llenium project, NY. 1994.

GREER, Michael. The Project Manager´s Partner. A Step–by–Step Guide to Project Management, 2nd Edition. AMACOM Books, 2001.

HALL, Earl; JOHNSON, Juliane. Integrated Project Management. Prentice Hall, 2003.

HASTINGS, W. K. Montecarlo Sampling Methods Using Markov Chains and Their Applications, Biometrika, 1970).

HEERKENS, Gary R. Project Management. McGraw–Hill, 2002.

HERBET Simon. The New Science of Management Decision. Harper and Row, New York, 1960.

HIGUCHI, Toshio; TSUTOMU, Kato. Improvement activities in the work place. Quality Control, 1984.

HROMKOVIC, J. Algorithms for hard problems: introduction to combinatorial optimization, randomiza-tion, approximation, and heuristics. Springer–Verlag, London – Berlin – Heidelberg – New York, 2001.

HURTADO, Toskano; BRUNO Gérard. El Proceso de Analisis Jerarquico (AHP) como herramienta para la toma de decisiones en la selección de proveedores : aplicación en la selección del provee-dor para la Empresa. Gráfica Comercial MyE S.R.L, 2005.

JALOTE, Pankaj. Software Project Management in Practice. Addison Wesley, 2002.

JESTON John; NELIS Johan. Business Process Management: Practical Guidelines to Successful Implementations – 3rd Edition. Butterworth–Heinemann, 2006.

JOHNSON, G.; SCHOLES, K. Dirección Estratégica – 7ª edición. Pearson, Prentice Hall. Madrid, 2006.

JOHNSON, Robert y KUBY, Patricia. Estadística elemental, lo esencial. Tercera Edición, Thomson. 2005

KERZNER, Harold. Project Management: A Systems Approach to Planning, Scheduling and Con-trolling, Sixth Edition. John Wiley, 1997.

KERZNER, Harold. Strategic Planning for Project Management Using a Project Management Matu-rity Model. John Wiley & Sons, 2001.

KOTLER, Philip. Administração de marketing: analise, planejamento, implementação e controle. Ed. Sao Paulo: Atlas, 1994.

LEVINE, Harvey A. Practical Project Management. Tips, Tactics and Tools. John Wiley & Sons, 2002.

LEWIS, James P. Fundamentals of Project Management. AMACON Books, 1995.

MARTIN Paula; TATE Karen. Getting Started in Project Management. John Wiley & Sons, 2001.

MAXIMIANO, Antonio Cesar Amaru. Adminitração de Projetos. Como transformar idéias em resulta-dos. 1ª Edição, Editora Atlas, 1997.

MCCARTHY, Jim. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.

MCCONNELL, Steve, After the Gold Rush: Creating a True Profession of Software Engineering. Microsoft Press, 1999.

284


MEREDITH Jack R.; MANTEL JR, Samuel J. Project Management, a Managerial Approach – 3rd Edition. Wiley, 1995.

METROPOLIS, A. ROSENBLUTH, M, TELLER, E. Equation of State Calculations by Fast Computing Machines, Journal of Chemical Physics, 1953.

MICHAELSON, G. Sun Tzu. The Art of War for Managers. Adams Media, 2001.

MIRANDA, Juan José Miranda. El Desafío de la Gerencia de Proyectos. Lemoine Editores, 2006.

MULCAHY, Rita. PMP Exam Prep: Accelerated Learnirng To Pass PMI´s PMP Exam – On Your First Try! 3rd Edition. Rmc Pubns Inc, 2005.

NAYATANI, Yoshinobu. A Lecture on the New Seven Tools of QC. Japanese Standards Association, 1987.

NEWELL, Michael W. Preparing for the Project Management Professional (PMP) Certification Exam – 2nd Edition. AMACON Books, 2002.

NEWELL, Michael W; GRASHINA, Marina N. The Project Management Question and Answer Book. AMACON Books, 2004.

NOVAK, J.D. y GOWIN, D.B. Aprendiendo a Aprender. Ediciones Martínez Roca, S.A., Barcelona, 1988.

ODA, Noriyuki. Case Studies of Improvement Activities which Apply the Seven New Tools of QC to Defective Processes. Quality Control, 1985.

OULD, Martyn. Managing Software Quality and Business Risk. New York: Wiley, 1999.

PAPALIA, Diane E, OLDS, Sally Wendkos y FELDMAN, Ruth Duskin. Psicología del desarrollo. McGraw–Hill, 2001

PHILLIPS, Joseph. PMP Project Management Professional Study Guide. McGraw–Hill, 2004.

PHILLIPS, Dwayne. The Software Project Manager’s Handbook, IEE Computer Society, 2000.

PRITCHARD, Carl L. Risk Management. ESI International, 1997.

Project Management Institute. Project Management Institute Practice Standard for Work Break-down Structures, Project Management Institute; 2001.

Project Management Institute. PMI. Practice Standard for Earned Value Management. 2005.

PURBA, Sanjiv. How to Manage a Successful Software Project: Methodologies, Techniques, Tools. New York: John Wiley, 1995.

QUENTIN, W; KOPPELMAN, J. What’s Your Project’s Real Price Tag?. Harvard Business Review. 2003SCHOBEL, Heinz. The Ancient Olympic Games. Princeton, D. Van Nostrand Company, 1965.

RAKOS, John J. Software Project Management for Small to Medium Sized Projects. Englewood Cliffs, NJ: Prentice Hall, 1990.

RICHMAN, Larry. Project Management Step–by–Step. Amacon Books, 2002.

RODRIGUEZ, Indiana. Guía sobre metodología y técnica de la investigación. Colon La Paix. 1992.

ROSS, Stephen A. Princípios de administração finaceira. Editoras Atlas – São Paulo, 2000.

ROYCE, Walker, Software Project Management: A Unified Framework. Addison–Wesley, 1998.

285

Bibliografía

SAATY, Thomas L. Fundamentals of Decision Making and Priority Theory. Pittsburgh, Pennsylvania: RWS Publications, 2001.

SABINO, Carlos. El proceso de la investigación científica. El Cid Editor. 1978

SCHWEITZER, Marcell; TROSSMANN, Ernst; LAWSON, Gerald . Break Even Point analysises: Basic Model, Variant, Extensions. John Wiley & Sons Inc, 1991.

SIERRA, Bravo. Técnicas de investigación social. 8ª Edición. Editorial Paraninfo. 1996.

SNACK, Nigel; CHAMBERS, Stuart; HARLAND, Christine. Operation Management. Pitman Publishing London, 1995.

SOBRINHO, José Dutra Vieira. Matemática Financeira – 7ª Edição. Editora Atlas, 2000.

SOUDER, Williem E. Project Selection and Economic Appraisal. Van Nostrand Reinhold, 1984.

STELLMAN, Andrew; GREENE Jennifer. Head First PMP®. O´Reilly Media INC, 2009.

THAYER, Richard. Software Engineering Project Management. IEEE Computer Society, 2000.

THOMAS, A.J. Project Manager Desk Reference – Guide to the Project Management Body of Knowledge – Eight Edition. The Hampton Group INC, 1999.

THOMSETT, Michael C. The Little Black Book of Project Management. AMACOM Books, 1990

THOR, Carl G. Using Nominal Group Technique to Establish a White Collar Productivity Measure-ment System. American Productivity Center, 1986.

TILICH, P. The courage to be, Yale, University, 1952

TRICK, Michael A. Analytic Hierarchy Process. Class Notes. Carnegie Mellon University Tepper School of Business, 1996

TUCKMAN, Bruce W. Developmental sequence in small groups. Psychological Bulletin, 63, 384–399, 1965.

TUCKMAN, Bruce W. Conducting Educational Research, Wadsworth. Fifth edition 1999.

TUCKMAN, Bruce W. Evaluating Instructional Programs. Allyn & Bacon, 1979.

TUCKMAN, Bruce W. Forming, storming, norming and performing in groups, the encyclopaedia of informal education. 2005

VALERIANO, Dalton L. Gerenciamiento Estratégico y Administracao por Projetos – 1ª Edicao. Markron Books, 2001.

VARGAS, Ricardo. Microsoft Project 2002 Profesional Server. Braspost Livros e Multimedia. 2002

VEN, A. Van de; POOLE, M.S. Handbook of Organizational Change and Innovation, Oxford University Press, 2004.

VEN, A. Van de; POLLEY, D; GARUD, R and VEKATARAMAN, S. The Innovation Journey.Oxford Uni-versity Press, 1999.

VEN, A. Vande; POOLE, M.S; DOOLEY K and HOLMES M. Organizational Change and Innovation Processes: Theory and Methods for Research Oxford University Press, 2000.

VEN, A. Vande and FERRY, D. Measuring and Assessing Organizations, Wiley Interscience, 1980.

286


VEN, A. Van de; DELBECQ, A and GUSTAFSON, D. Group Techniques for Program Planning: A Guide to Nominal Group and Delphi Processes. Scott Forsman, 1975

VERZUH, Eric. The Fast Forward MBA in Project Management, Second Edition. John Wiley & Sons, 2005.

VERZUH, Eric. The Portable MBA in Project Management. John Wiley & Sons, 2005.

WARD, J. LeRoy. Project Managemen Terms. A Working Glosssary. ESI International, 1997.

WEISS, Joseph J; WYSOCKI, Robert K. 5–Phase Project Management. Addison Wesley, 1992.

WESTERFIELD, Randolph W.; JORDAN, Bradford D. Essential of Corporate Finance. McGraw Hill Companies Inc,; 1999.

WIESER, Friedrich von. Theorie der gesellschaftlichen Wirtschaft. JCB Mohr, 1924.

WILKS, Samuel S. Mathematical Statistics, John Wiley, 1962

WOOD, Jane. Joint Application Development. New York, NY: John Wiley & Sons, Inc, 1995.

WYSOCKI, Robert K.; MCGARY, Rudd. Effective Project Management, Third Edition. John Wiley & Sons, 2003

YOURDON, Edward. , Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible Projects. Prentice Hall, 1997.

manual (4)

Documents