Claves de Gestion de Proyectos-1

CREDITOS 1-14 26/5/11 10:27 Página 3
CLAVES DE LA
GESTIÓN DE PROYECTOS
Gestión eficiente de
proyectos y de trabajo en equipo
CARLOS GROLIMUND
CREDITOS 1-14 26/5/11 10:27 Página 4
CLAVES DE LA GESTIÓN DE PROYECTOS

Gestión eficiente de proyectos y de trabajo en equipo
Autor: Carlos Grolimund
Edita:
© FUNDACIÓN CONFEMETAL
Príncipe de Vergara, 74 – 28006 Madrid
Tel.: 91 782 36 30. Fax: 91 563 17 41
editorial@fundacionconfemetal.es
www.fundacionconfemetal.com
ISBN: 978-84-92735-80-8
Depósito Legal: M-23721-2011
Maquetación e Impresión:
GRÁFICAS MARCAR, S.A.
Ulises, 95 - 28043 Madrid
Impreso en España – Printed in Spain
QUEDA PROHIBIDA TODA REPRODUCCIÓN TOTAL O PARCIAL DE LA OBRA POR CUALQUIER MEDIO
O PROCEDIMIENTO SIN AUTORIZACIÓN PREVIA.
CREDITOS 1-14 26/5/11 10:27 Página 7
ÍNDICE
INTRODUCCIÓN .................................................................... 11
CAPÍTULO 1
VISIÓN GENERAL DE LOS PROYECTOS Y SU GESTIÓN ............ 15
1.1. El mundo de los proyectos .................................... 17

1.2. Ejemplos de grandes fracasos en los proyectos ..... 21
1.3. Pero, ¿por qué fallan los proyectos? ...................... 24
1.4. Palabras clave ...................................................... 26
CAPÍTULO 2
EL COEP DE LA EMPRESA ..................................................... 27
2.1. Cultura de empresa .............................................. 29

2.2. Organización ........................................................ 31
2.3. Entorno ................................................................ 32
2.4. Personas ............................................................. 33
CAPÍTULO 3
TENDENCIAS EN LA GESTIÓN DE PROYECTOS ....................... 37
3.1. PMI (Project Management Institute) ....................... 41

3.2. Teoría de restricciones (TOC) y cadena crítica
(CCPM) ................................................................ 44
3.3. Six Sigma ............................................................ 44
3.4. Lean Project Management (LPM) ........................... 44
CREDITOS 1-14 26/5/11 10:27 Página 5
Mi cariño y agradecimiento a María Claudia Londoño

y Maribel Calzadilla por su ayuda.
A José Luis Esteban y José Andrés por sus ideas y discusiones.
A mis "pequeños" Alejandro, Javier y María.

CREDITOS 1-14 26/5/11 10:27 Página 8
CAPÍTULO 4
CAMBIO DE PARADIGMA ...................................................... 45
4.1. Reflexión sobre la teoría de las restricciones ......... 47

4.2. TOC y los proyectos .............................................. 59
4.2.1. Viejos vicios en los proyectos .................... 62

4.2.2. Los cinco pasos de TOC en los proyectos ... 70
4.3. Gestión de la cadena crítica (CCPM) ...................... 74
4.3.1. Sistemática de la cadena crítica ................. 74
4.4. Gestión de los buffers .......................................... 82

4.5. Tamaño del buffer del proyecto ............................. 85
4.6. Buffer de recursos críticos .................................... 86
CAPÍTULO 5
EL DILEMA DEL ALCANCE DEL PROYECTO Y EL
PENSAMIENTO LEAN ............................................................. 87
5.1. Problemas con el alcance del proyecto ................... 89

5.2. Ejemplo en proyectos de tecnologías de la infor-
mación .............................................................. 90
5.3. El concepto de Lean y su expansión ...................... 92
5.4. Conseguir proyectos Lean (LPM) ............................ 98
5.5. Combinar LPM con CCPM ...................................... 109
CAPÍTULO 6
LOS RECURSOS HUMANOS Y LA RESISTENCIA AL CAMBIO .... 111
6.1. Resistencia al cambio ........................................... 113

CREDITOS 1-14 26/5/11 10:27 Página 9
6.2. Tipología de los profesionales que se resisten

al cambio ............................................................. 118
6.3. Formación de los responsables de proyectos ......... 122
CAPÍTULO 7
UN HORIZONTE MÁS FIABLE ................................................. 125
7.1. Liderar un proyecto ............................................... 127

7.2. Distribuir responsabilidades .................................. 128
7.3. Incrementar la productividad ................................. 128
BIBLIOGRAFÍA ...................................................................... 129

CREDITOS 1-14 26/5/11 10:27 Página 11
INTRODUCCIÓN
CREDITOS 1-14 26/5/11 10:27 Página 13
Introducción
Este libro no pretende ser otro más de Gestión de Proyectos basado

en la guía PMBOCK del Project Management Institute. Con el libro se pre-
tende mostrar a los lectores métodos y técnicas adicionales que minimi-
cen los problemas clásicos que se dan en los proyectos en plazos, cos-
tes y desviaciones en el alcance de los mismos.
Es muy común utilizar modelos matemáticos en la planificación de los

proyectos (Pert, Precedencias…) sin tener en cuenta que dichos mode-
los no contemplan factores de comportamiento de los equipos de pro-
yecto, organizaciones, clientes, así como, factores como estrategia, com-
petitividad y productividad.
Otro punto importante es el desmesurado alcance de los proyectos

con prestaciones y funcionalidades por los que los clientes no pagarían.
Es cierto que, ante esta situación, los retrasos y los incrementos de cos-
tes provocan la reducción del alcance con los lógicos problemas que ello
conlleva.
El objetivo del autor consiste en proporcionar, al amable lector, un

marco y unos métodos para conseguir que sus proyectos sean más efi-
caces y más eficientes, que entreguen bienes y servicios con mayor cali-
dad desde la perspectiva del cliente, así como, cumplir y reducir los pla-
zos en las entregas.
En el libro se introducen filosofías y métodos de gestión que nacieron

en el sector industrial, en principio en la producción, y que una vez con-
trastados, extendieron sus fundamentos a otras áreas de la empresa,
entre ellas a la gestión de proyectos. Se hace especial hincapié en el
método de cadena crítica por el gran peso específico que tiene en los pro-
yectos para conseguir una mayor productividad en los mismos sin olvidar
el pensamiento Lean como marco para eliminar los despilfarros que, con
frecuencia, incurrimos en los proyectos.
No se pretende tratar de forma extensa estos temas, pero sí exponer

los conceptos fundamentales que los sustentan.
13
CREDITOS 1-14 26/5/11 10:27 Página 14
Claves de la Gestión de Proyectos
El lector, para seguir el contenido del libro, debe tener conocimientos

básicos de técnicas de planificación y control que son básicos para
entender los métodos que se exponen en las siguientes páginas. Les
aseguro que con estos métodos mejorarán sus proyectos.
Larry Leach lo resume con la frase completar proyectos en la mitad

de tiempo, todo el tiempo y con más calidad. Quizá Leach exagere un
poco pero intentarlo producirá buenos resultados.
Es hora de pasar a la acción de la forma más sencilla y amena posi-

ble y confío en que disfruten con la lectura de este libro.
14
CAP 01 25/5/11 15:40 Página 15
CAPÍTULO 1
VISIÓN GENERAL DE LOS

PROYECTOS Y SU GESTIÓN
CAP 01 25/5/11 15:40 Página 17
Visión General de los Proyectos y su Gestión
1.1. EL MUNDO DE LOS PROYECTOS
“Un proyecto es un problema con un plan de solución”
Esta frase de J.M. Juran1 nos da una idea de cómo hemos contem-
plado siempre el mundo de los proyectos. A priori los contemplamos
como un problema al que hay que dar solución a través de criterios de
gestión.
El propio concepto de proyecto siempre ha sido controvertido. El pri-

mer proyecto del que hay revelación es la creación del mundo (Génesis):
• Objetivo: crear el mundo de la nada (o del caos)
• Plazo: seis días (mal definidos, al principio aún no había día y

noche)
• Recursos: ilimitados
Después dejó la gestión a sus clientes, Adán y Eva, y…
Como podemos ver, no sólo la unidad de tiempo empleada es confu-

sa, también lo es el punto de partida para cumplir el objetivo. Por otra
parte, los clientes no vieron cumplidas sus expectativas con los resulta-
dos del proyecto.
1
Nacido el 24 de diciembre de 1904 en la ciudad de Braila, Rumania. Fue el precursor de la calidad
en Japón. Se le considera el padre de la calidad. Para Juran la calidad puede tener varios significa-
dos, dos de los cuales son muy importantes para la empresa, ya que estos sirven para planificar la
calidad y la estrategia empresarial. Por calidad Juran entiende como la ausencia de deficiencias que
pueden presentarse como: retraso en la entregas, fallos durante los servicios, facturas incorrectas,
cancelación de contratos de ventas, etc. Calidad es adecuarse al uso.
17
CAP 01 25/5/11 15:40 Página 18
Posteriormente la historia nos proporciona ejemplos de proyectos de

construcción en las civilizaciones egipcia, maya y romana. Pero estos pro-
yectos no tuvieron problemas de recursos, ni los plazos agobios de tiempo.
En la actualidad, los proyectos sí presentan problemas de todo tipo,

especialmente en:
• La meta y el alcance del proyecto.
• Los plazos de entrega de los resultados del proyecto.
• La gestión de los recursos. Hablamos de gestión de recursos,

pues asumimos que estos no son infinitos.
Aunque los recursos, especialmente los humanos, no supongan un

problema a priori, sí es problemático el comportamiento de los mismos
y más cuando los observamos como grupo. Consideremos un equipo de
proyecto y su líder, según sea su cohesión y comportamiento podría
hacerse una tipología de los proyectos.
Ed Yourdon2 estableció una tipología en base al gráfico siguiente:
2 Edward Nash Yourdon (1944) es ingeniero de software, consultor, autor, conferenciante y el pionero
en metodologías de ingeniería de software. Se le conoce como uno de los líderes en el desarrollo de

las técnicas de análisis estructurado. Es coautor del método Yourdon/Wthitehead (Metodología de
análisis y diseño orientado a objetos) y de la Metodología Coad/Yourdon también orientada a objetos.
18
CAP 01 25/5/11 15:40 Página 19
Sobre el eje de ordenadas llevamos el porcentaje de felicidad del equi-

po del proyecto. Este porcentaje no es una ocurrencia alocada, puesto
que el bienestar y la razonable satisfacción en el desarrollo del proyecto
por parte del equipo es importante.
Sobre el eje de abscisas llevamos el porcentaje de probabilidad de

cumplir con los objetivos del proyecto.
La combinación de los dos porcentajes proporciona unos tipos de pro-

yectos basados principalmente en el comportamiento del equipo.
19
CAP 01 25/5/11 15:40 Página 20
• Tipo Misión Imposible: El nombre no debe llevarnos a engaño, en

realidad deriva de la película del mismo nombre. El líder del pro-
yecto es una réplica de Tom Cruise capaz de superar todas las difi-
cultades y agresiones que pueda sufrir el proyecto.
El equipo está formado por buenos especialistas en distintas

áreas de trabajo y con capacidad de comportamiento multidisci-
plinar en el caso de que se requiera suplir a un colega. Son auto-
suficientes en la gestión de sus tareas y cuestiones internas al
proyecto, dejando al líder solucionar los problemas que provienen
del exterior al mismo.
Estos equipos, incluido el líder, emplean métodos a todos los nive-

les, normativas y una perfecta organización (la semejanza de
estos equipos está más cercana a la serie de televisión que a la
película), consiguiendo unos resultados satisfactorios.
A diferencia de los héroes de Hollywood, estos profesionales no

se mueven por altruismo, sino que buscan reconocimiento, dine-
ro, ascensos y otras prebendas.
Una característica importante en este tipo de proyectos es la del

convencimiento del líder y del equipo del éxito del proyecto.
• Tipo Cuerpo de Marines: A diferencia del caso anterior, aquí el

único que cree en el éxito del proyecto es su líder, cuyo compor-
tamiento se asemeja al de un rudo sargento de marines con sus
reclutas. Este sargento no delega absolutamente nada en su equi-
po y ejercita funciones de control exhaustivas a todas horas. Si
alguien del equipo se derrumba es tratado públicamente como un
recluta inútil y si un miembro del equipo abandona, el sargento
considera que es una suerte y se busca un reemplazo.
Es obvio que el porcentaje de felicidad baja dramáticamente e, inclu-

so, también baja en cierta medida la probabilidad de cumplimiento,
20
CAP 01 25/5/11 15:40 Página 21
así como posiblemente, quizás, la calidad de los resultados del pro-

yecto.
Otra consideración a tener en cuenta es que este tipo de proyec-

tos hacen perder a las empresas valiosos profesionales y la for-
mación de equipos cohesionados de cara a otros proyectos.
• Tipo Suicidas: Se explican por sí solos. Alcance del proyecto desa-

forado, requisitos inestables o mal definidos, plazos imposibles
de cumplir, profesionales poco cualificados, etc. Ni el líder ni el
equipo tienen ninguna esperanza de éxito y dedican sus oraciones
a pedir la rápida cancelación del proyecto.
• Tipo Kamikazes: Es similar al anterior, nadie cree en el éxito del

proyecto pero hay algo que, con un último grito, les hace inmolar-
se por el mismo.
Este tipo de proyectos suele darse en empresas de corte familiar

o en aquellas donde los empleados son de toda la vida y, por
tanto, prima un sentimiento de fidelidad muy agudizado.
Otra variante de este tipo se da en proyectos donde el equipo

debe emplear una tecnología nueva. Todo el mundo sabe que el
proyecto está abocado al fracaso pero, al menos, los miembros
del equipo aprenderán nuevas cosas que les puedan servir en un
futuro.
1.2. EJEMPLOS DE GRANDES FRACASOS EN LOS

PROYECTOS
Cuando hablamos de fracasos en los proyectos es necesario precisar

en qué fallaron. Es muy útil emplear las cuatro dimensiones de los pro-
yectos o restricciones: tiempo, costos, alcance y calidad.
21
CAP 01 25/5/11 15:40 Página 22
s
po
Co
em
st
Ti
os
Calidad
Alcance
La historia nos muestra un gran número de fracasos en los proyectos

con importantes repercusiones a todos los niveles. Veamos unos cuan-
tos ejemplos.
✔ Ejemplo 1: La Opera House en Sydney, que pasó de un presu-

puesto inicial de 7 millones de dólares a un coste final de 107
millones.
Violó la restricción de costos
22
CAP 01 25/5/11 15:40 Página 23
✔ Ejemplo 2: Tacoma Narrows Suspension Bridge (“Galloping

Gertie”) el tercer puente más largo del mundo (tras el Golden Gate
y el George Washington), que se hundió en 1940 cuatro meses y
siete días después de su apertura.
Violó la restricción de la calidad
✔ Ejemplo 3: El túnel bajo el Canal de la Mancha, con una estima-

ción de coste de 7,5 billones de dólares y plazo de entrega en
1992, se terminó en 1994 con un coste de 17,5 billones.
Violó las restricciones de costos y tiempos
✔ Ejemplo 4: Desarrollo del F-22 Raptor. Se estima que el coste ya

ha superado el presupuesto en varios billones de dólares.
Violó las restricciones de costos y tiempo
23
CAP 01 25/5/11 15:40 Página 24
Los ejemplos presentados muestran graves fallos de planificación

excepto el ejemplo 2 que muestra un fracaso tecnológico y en la calidad,
pero existen otros fracasos de índole comercial como, por ejemplo, el
Concorde y el proyecto Apple Newton para lanzar al mercado una PDA. En
el caso del Concorde no se consideró que sus elevadas tarifas pudieran
retraer a sus posibles clientes. En el caso Apple Newton, el equipo de sis-
temas hizo una PDA para personas de sistemas.
El Concorde falló en las restricciones de calidad y costos.
Apple, con su PDA, falló en la restricción del alcance.
En estos últimos casos, el denominador común es la incapacidad de

dar valor al cliente y este tipo de fallo en los proyectos suele ser muy
común al día de hoy y tiene graves consecuencias.
Todos estos problemas, que se han comentado, suponen un freno

para el principal objetivo de una empresa que es el de ganar dinero de
forma continua y este objetivo solo lo puede conseguir con el éxito de sus
proyectos.
1.3. PERO, ¿POR QUÉ FALLAN LOS PROYECTOS?
En la literatura sobre gestión de proyectos hay decenas de porcenta-

jes que permiten observar el índice de fracasos en la realización de pro-
yectos.
Según The Standish Report3 los resultados más significativos de su

estudio fueron:
3Sobre la base de los resultados de la dirección de proyectos en compañías de informática se reali-

zó el estudio “The Chaos Report” (Standish Group) que observa de todos los proyectos estudiados,
qué cantidad fueron finalizados exitosamente y cuántos no llegaron a cumplir con algunos o todos los
objetivos.
24
CAP 01 25/5/11 15:40 Página 25
— 31% de los proyectos se cancelan antes de su finalización.
— 52,7% de los proyectos superan el 189% del coste presupuesta-

do original.
— 16,2% de los proyectos se entregan en plazo y en coste.
— Las organizaciones grandes sólo obtienen un 42% de las caracte-

rísticas y funciones que deseaban en el producto final.
Aunque los diferentes estudios difieren un poco en sus porcentajes,

el correspondiente a los proyectos que acaban con éxito es dramática-
mente bajo.
Los mismos estudios tipificaron los factores críticos de éxito, así

como los factores que contribuían al fracaso de los proyectos. Se resal-
tan a continuación los principales:
• Ausencia de requisitos del cliente.
• Especificaciones incompletas y cambiantes.
• Expectativas poco realistas con objetivos poco claros.
• Problemas en el alcance del proyecto.
• Falta de compromiso por parte de la Dirección.
• Plazos no realistas (por no decir demenciales).
Por supuesto, existen más factores pero los arriba indicados son los
de mayor peso en los proyectos y son, también, generadores de otros
muchos.
25
CAP 01 25/5/11 15:40 Página 26
1.4. PALABRAS CLAVE
Es pronto para hablar de gestión de proyectos pero podemos elaborar

una lista de palabras clave aparecidas en este capítulo y que tendrán un
gran peso a lo largo del libro:
— Cliente
— Alcance del proyecto
— Plazos
— Costes
— Equipo del proyecto
— Líder del proyecto
26
CAP 02 25/5/11 15:42 Página 27
CAPÍTULO 2
EL COEP DE LA EMPRESA
CAP 02 25/5/11 15:42 Página 29
El COEP de la Empresa
COEP es un acrónimo de Cultura de empresa, Organización, Entorno

y Personas. Estos cuatro apartados tienen un impacto considerable en
los proyectos y su administración.
2.1. CULTURA DE EMPRESA
Sectores e industrias tienen comportamientos sensiblemente distin-

tos. El sector industrial siempre ha sido pionero en la aplicación, cuan-
do no en la creación, de nuevos métodos y procedimientos en la admi-
nistración de los proyectos, además la experiencia adquirida en la ges-
tión de sus sistemas de cadenas de producción fue transferida, con
notable éxito a la gestión de proyectos. La industria de las Tecnologías
de la Información y el sector de las TIC, en cambio, tienen serios pro-
blemas en aplicar los métodos y normas necesarios para afrontar sus
proyectos ya que consideran que sus proyectos son especiales y dis-
tintos y los estándares e innovaciones en la gestión de los proyectos no
sirven a sus propósitos.
Dentro de una misma industria hay empresas con comportamientos

distintos debidos a razones como tamaño, antigüedad, posición en el
mercado, competencia, etc.
Respecto a la cultura de empresa, el líder de proyectos debe ser cui-

dadoso en dos aspectos:
• No alterar el ritmo de la empresa. Esto no quiere decir que no

intente introducir en los sistemas de gestión de proyectos nuevos
métodos y mejoras, pero deberá hacerlo convenciendo a las
Direcciones afectadas. Es peligroso alterar la dinámica de la
empresa sin el convencimiento del cuadro directivo.
• Evitar los laboratorios. Algunas veces, las empresas cuando tienen

en perspectiva un considerable número de proyectos, cambian sus
29
CAP 02 25/5/11 15:42 Página 30
sistemas de gestión de proyectos a formas imperativas y encorse-

tadas. Estas situaciones se dan con frecuencia en las estimacio-
nes de tareas basadas en simulaciones con ambiente clean room.
Un ejemplo sencillo sería el desarrollo informático de una tran-

sacción de teleproceso. Antes de acometer el proyecto del desa-
rrollo de transacciones de teleproceso, un grupo se encarga de
desarrollar una transacción tipo para estimar una duración media
de las tareas que componen dicha transacción. A partir de los
resultados obtenidos por este grupo se establece un estándar
para aplicar al proyecto y en ese momento se producen dolosos
errores:
1. La simulación se hizo sin ninguna consideración de factores

exógenos que pudieran afectar a la estimación. Trasladada la
estimación al mundo real del proyecto no funciona en la mayor
parte de las ocasiones.
2. La estimación de una transacción tipo puede tener desviacio-

nes importantes respecto a transacciones complejas. En una
entidad financiera, una transferencia de fondos es más senci-
lla que una transacción de medios de pago que pueden ser,
pago con tarjeta de crédito, con cheques gasolina, etc., y que
son muy distintos entre sí (en el fondo son varias transaccio-
nes, tantas como tipos de pagos se contemplan, en una con
pocas partes de funcionalidades comunes).
3. Es posible que, además, el grupo piloto fuerce la estimación

para agradar a la dirección.
En este caso, el líder del proyecto deberá ser especialmente cauto,

convenciendo a la Dirección de las desviaciones que se pueden producir
en el proyecto proponiendo formas alternativas de estimación.
30
CAP 02 25/5/11 15:42 Página 31
2.2. ORGANIZACIÓN
Tom Peters1 publicó en Liberation Management que:
— La gestión por mandos intermedios se ha agotado. La gestión por

proyectos es la nueva frontera de la productividad global de la
empresa.
— Dirigir proyectos en una institución es dirigir el cambio.
Los proyectos pueden producirse bajo organizaciones funcionales,

matriciales o por proyectos y, en muchas ocasiones, pueden darse fun-
cionamientos complejos. Por otro lado, cuando los proyectos sufren retra-
sos y otros problemas, la tendencia de buscar culpables tiene dos ver-
tientes:
• Culpar a agentes externos (clientes, proveedores…).
• Culpar a agentes internos (gerentes, mandos intermedios…).
Este último punto es consecuencia, por lo general, del elevado núme-

ro de departamentos de una empresa que pueden intervenir en un pro-
yecto y que hace fácil tener un culpable a mano.
1 La revista Fortune llamó a Tom Peters el Ur-guru (gurú de los gurús) de la dirección y lo comparó
con Ralph Waldo Emerson, Henry David Thoreau, Walt Whitman y H.L. Mencken. The Economist lo
etiquetó como Uber-guru. Y sus innovadores puntos de vista hicieron que Business Week lo descri-
biera como “el mejor amigo y la peor pesadilla de los negocios”.
31
CAP 02 25/5/11 15:42 Página 32
2.3. ENTORNO
Debemos considerar dos tipos de entorno:
— Entorno interno a la empresa: Los proyectos se ven afectados por

la tecnología existente, normativas poco ágiles, aplicaciones infor-
máticas legadas y una larga lista de rémoras que obligan al líder
del proyecto a ser pesimista en sus estimaciones de plazos en la
entrega de los productos y/o servicios resultantes del proyecto.
— Entorno externo a la empresa: Si el entorno anterior es delicado,

éste puede ser crítico. La tendencia a considerar el entorno exter-
no, que afecta a los proyectos de una empresa, sólo en función
de las relaciones con clientes y proveedores está claramente
incompleto. La competencia, es decir, las empresas competido-
ras, la globalización y los nuevos mercados exigen que los pro-
yectos se realicen en menos tiempo y con costes más óptimos.
Si consideramos una empresa de fabricación de teléfonos móviles es

fácil deducir que tiene una dura competencia por lo que, para no perder
cuota de mercado, lanza constantemente nuevos teléfonos o modelos
tecnológicamente más avanzados y con más prestaciones. La paradoja
se da en que tiene que lanzar un nuevo modelo antes de que se cumpla
el ciclo de ventas del anterior.
El problema reside en que el tiempo óptimo en lanzar un nuevo mode-

lo al mercado, que permita seguir con la cuota de mercado deseada,
puede ser inferior al tiempo del proyecto de diseño, fabricación y pruebas
de dicho modelo. Todo esto provoca que el retorno de la inversión (ROI)
de un modelo se acorte antes de que el nuevo modelo lo mate.
32
CAP 02 25/5/11 15:42 Página 33
Lanzamiento Crecimiento Madurez Declinación
Volumen
de
ventas
Retiro
Tiempo
La situación, en el caso de los teléfonos móviles, llevaría a la curva a

transformarse, prácticamente, en un triángulo.
La solución a estos problemas solo parece tener una opción, RECOR-

TAR LOS TIEMPOS Y COSTES EN LA REALIZACIÓN DE LOS PROYECTOS.
2.4. PERSONAS
Cultura de empresa, Organización y Entorno tienen una fuerte influen-

cia en los proyectos, pero no debemos olvidar que son ejecutados por
Personas cuyo comportamiento es decisivo para el buen fin de los mis-
mos, pero no solo el equipo del proyecto debe contemplarse en este
apartado.
Son muchos los interesados en un proyecto (se utiliza con frecuencia

el término inglés Stakeholders). En la guía PMBOK se encuentra la
siguiente definición:
33
CAP 02 25/5/11 15:42 Página 34
Son individuos y organizaciones

que están activamente involucrados en el proyecto
o cuyos intereses pueden ser afectados positiva o negativamente
como resultado de la ejecución o conclusión del proyecto.
Con esta definición puede elaborarse la siguiente lista:
• Equipo del proyecto (incluyendo al líder)

• Clientes (incluyendo posibles usuarios finales)
• Proveedores (de todo tipo incluyendo servicios)
• Dirección Corporativa
• Consultores/Asesores internos y externos
• Jefes de miembros del equipo (incluyendo al jefe del líder de pro-
yecto)
• Auditores
• Departamentos de apoyo (financiero, marketing…)
El líder tiene relación con muchas personas con intereses dispares y

que aportan un grado de dificultad a su trabajo.
La aplicación de nuevos métodos para la mejora en la gestión de los

proyectos tiene a su vez, un problema adicional respecto a las personas.
El problema es la resistencia al cambio. La resistencia al cambio en
métodos, normas y procedimientos provoca en las personas una trans-
formación cercana a pasar a ser miembros de un maquis virulento.
34
CAP 02 25/5/11 15:42 Página 35
Este tema será tratado con profundidad en el capítulo 6.
En cuanto al equipo del proyecto como entidad existen razones por la

que fallan con frecuencia. Estas razones son:
— Recursos inadecuados: Los equipos no son efectivos cuando son

muy pocos miembros, o cuando estos tienen inadecuada forma-
ción, pobre soporte, o inapropiadas habilidades.
— Problemas de liderazgo: El equipo se resiente cuando el líder del

proyecto no ejerce su autoridad correctamente, ni motiva, ni se
comunica, o pretende ser un referente sólo en aspectos técnicos
y no de gestión. Otro error bastante común es de no defender a
los miembros del equipo incluso utilizándoles como culpables
ante situaciones comprometidas para el líder del proyecto.
— Objetivos imposibles: Ante planificaciones nada realistas u objeti-

vos salvajemente optimistas, los equipos incurren en un compor-
tamiento irracional para afrontar el éxito del proyecto o, caen en
una profunda depresión y actúan y trabajan para cubrirse las
espaldas ante el más que posible desastre.
— Problemas de moral o ánimo: Cuando los miembros del equipo se

ven afectados por evaluaciones, promociones, cuestiones salaria-
les, o seguridad en el trabajo, ellos no pueden concentrarse en el
trabajo.
35
CAP 02 25/5/11 15:42 Página 36
36
CAP 03 25/5/11 15:43 Página 37
CAPÍTULO 3
TENDENCIAS EN LA
GESTIÓN DE PROYECTOS
CAP 03 25/5/11 15:43 Página 39
Tendencias en la Gestión de Proyectos
En las últimas décadas, se han producido interesantes movimientos

en la teoría de la gestión de proyectos. Unos nacieron como ordena-
miento de los procesos propios de los proyectos y el enunciado de los
conocimientos necesarios para abordarlos y otros fueron consecuencia
de la transferencia de métodos de sistemas de producción
al mundo de los proyectos.
La palabra teoría siempre produce rechazo en el mundo de los pro-

yectos que es primordialmente práctico y ello conlleva a no ser tenidos
en cuenta nuevos métodos de gestión.
Puede ser necesario recordar a los que rechazan las nuevas teorías la
frase de Leonardo da Vinci, los que se enamoran de la práctica sin la
teoría son como los pilotos sin timón ni brújula, que nunca podrán saber
adónde van.
A continuación se presenta un esquema con las principales caracte-

rísticas de cada una de las tendencias en la gestión de proyectos.
PMI
• Guía PMBOK:
— Buenas prácticas
39
CAP 03 25/5/11 15:43 Página 40
— Elaboración progresiva
— Cinco grupos de procesos
— Nueve áreas de conocimiento
— Enfoque de proceso
• Guías prácticas (por ejemplo):
— WBS o DDT (diagrama de descomposición del trabajo)

— Planificación basada en el camino crítico
— Valor ganado
SIX SIGMA
• Reduce la variación
• Se focaliza en el cliente
• Proceso de mejora en:
— Definición
— Medidas
— Análisis
— Mejoras
— Control
— Profundo conocimiento
TEORÍA DE RESTRICCIONES/CAMINO CRÍTICO
• Simplicidad inherente
• Restricción:
— Estudio en cinco pasos
• Cadena crítica:
40
CAP 03 25/5/11 15:43 Página 41
— Focalizada en el problema
— Buffers (amortiguadores)
— Pipeline
LEAN
• Reduce desperdicios
• Cinco principios:
— Valor
— Flujo de valor
— Flujo sin obstáculos
— Pull
— Perfección
Estas características se detallarán a continuación y en capítulos

siguientes.
3.1. PMI (PROJECT MANAGEMENT INSTITUTE)
El Project Management Institute ha desarrollado, a través de su guía

PMBOK, unos estándares internacionales para garantizar el éxito en la
entrega de los proyectos. Estos estándares ofrecen una ventaja funda-
mental en la comunicación entre miembros del equipo de proyecto al
emplear un lenguaje común y un vocabulario controlado. Imaginemos
un proyecto donde par te del mismo se realiza en España y otra par te
en China o la India, el idioma que se emplea en las comunicaciones
probablemente sea el inglés, pero si no existieran los estándares del
PMI, no tendríamos un vocabulario controlado que eliminara confusio-
nes y errores.
El PMI propone las siguientes áreas de conocimiento:
41
CAP 03 25/5/11 15:43 Página 42
Y distingue cinco grupos de procesos:
42
CAP 03 25/5/11 15:43 Página 43
El instituto ofrece además los siguientes servicios:
• Mejoras de la guía PMBOK (en el momento de escribir este libro

está en la 4ª Edición).
• Desarrollo de guías especializadas como suplemento.
• Desarrollo de guías prácticas para la aplicación de determinadas

técnicas como, por ejemplo, la del valor ganado.
• Formación, publicaciones y colaboraciones internacionales.
43
CAP 03 25/5/11 15:43 Página 44
3.2. TEORÍA DE RESTRICCIONES (TOC) Y CADENA

CRÍTICA (CCPM)
La Teoría de Restricciones y la Cadena Crítica son métodos de gestión

desarrollados por el Doctor Eliyahu Goldratt a principios de los noventa.
Tiene el inmenso atractivo de proporcionar soluciones simples a proble-
mas complejos. Hace especial hincapié en procedimientos que incre-
menten la productividad de los sistemas de gestión en general y, en ges-
tión de proyectos en particular.
Se desarrollarán estos métodos en el capítulo 4.
3.3. SIX SIGMA
Esta metodología ha tenido poca repercusión en la gestión de los pro-

yectos al estar más orientada a los procesos, así como a la calidad y eli-
minación de defectos.
Fue la primera metodología que se orientó hacia el cliente y, por tanto,

fue precursora de otras en este sentido.
Su fuerte base estadística no la hace atractiva para los responsables

de proyectos pero eso no quita que en el mundo de la producción y ges-
tión de procesos siga teniendo un fuerte predicamento.
3.4. LEAN PROJECT MANAGEMENT (LPM)
El pensamiento Lean representa una nueva forma de gestión que nace

en la empresa Toyota y que ha representado una revolución mundial. Es
difícil poder afirmar que pueda ser una metodología, pero establece un
marco extraordinario para logar sistemas de gestión más eficientes.
En el capítulo 5 se extenderá este tema.
44
CAP 04 25/5/11 15:51 Página 45
CAPÍTULO 4
CAMBIO DE PARADIGMA
CAP 04 25/5/11 15:51 Página 47
Cambio de Paradigma
4.1. REFLEXIÓN SOBRE LA TEORÍA DE LAS

RESTRICCIONES
La Teoría de las Restricciones (TOC) fue enunciada por Goldratt1 par-

tiendo de la base de los conceptos de Calidad Total y del JIT (Just In Time
o Justo a Tiempo), es decir, emitiendo una nueva teoría sin menosprecio
de las otras dos. El nuevo sistema complementa los anteriores solucio-
nando problemas que estos no abarcaban.
Nuevamente, esta teoría nace en el sector industrial y se ilustró

tomando como ejemplo los sistemas de producción. En este libro se uti-
lizará este mismo ejemplo por su facilidad de entendimiento y por su
poder visual.
Una de las premisas de Goldratt consiste en la aceptación de que

cualquier sistema tiene, al menos, una restricción o limitación que impi-
de que tenga un rendimiento del 100%. Si esto no se cumpliera, la
empresa sería una máquina de hacer dinero todo el tiempo.
Supongamos una cadena integrada por varios eslabones. Dicha cade-

na siempre se romperá por el eslabón más débil y sólo puede haber un
eslabón más débil. Esto es aplicable para cualquier sistema, que traba-
jará al ritmo que le marque su eslabón más débil, es decir, su restricción.
1
Eliyahu M. Goldratt. Nacido en Israel en el año de 1948, licenciado en Física por la Universidad de
Tel Aviv, realizó su master y doctorado en la Universidad de Bar-Ilan, creador de la Teoría de
Restricciones (TOC - Theory of constraints).
47
CAP 04 25/5/11 15:51 Página 48
Puede argumentarse que los sistemas tienen más de una restricción

pero solo una es la que delimita el rendimiento del sistema. Cuando se
solucione ese problema en concreto, estaremos en disposición de loca-
lizar otra posible limitación.
En la teoría de las restricciones se dice que el peso de un eslabón

supone el coste de dicho eslabón, más peso corresponde a más
coste, y que la resistencia de la cadena está representada por los vín-
culos entre eslabones. Esta última definición representa el flujo de un
sistema de producción. Hay que tener en cuenta que los vínculos no
tienen peso.
En términos empresariales, mejorar el peso (hacer un eslabón más

ligero) implica reducir los costes. Si se sustituye la palabra eslabón por
departamento, estaríamos hablando de la reducción de costes del
mismo. Esto parece un objetivo normal, establecer mejoras locales pero,
no podemos estar seguros de que la cadena está adecuadamente ges-
tionada.
Las mejoras locales implican una gestión centrada en el mundo de los

costes, y ¿quién no quiere reducir los costes, especialmente en tiempos
difíciles?, pero reducir los costes no mejora el rendimiento, es decir, no
mejora el rendimiento de la cadena.
Muchas empresas se mueven en el mundo de los costes tratando de

obtener la producción a costes inferiores pero, en un momento determi-
nado, surge el síndrome de fin de mes donde el interés está en despa-
char pedidos para poder facturar a los clientes, entonces si hay que incre-
mentar los costes se hace para cumplir con el objetivo. En este caso nos
centramos en el mundo del valor que es el motor de cualquier empresa
para mantener clientes y negocio.
Ilustremos esta forma de gestión con un ejemplo y supongamos una

cadena de producción como la que sigue a continuación. Cada rectángulo
representa un departamento o un recurso que trabajan en una secuencia
48
CAP 04 25/5/11 15:51 Página 49
Cambio de Paradigma
predeterminada para obtener productos para los clientes. Cada rectángu-

lo ejercita una función en la cadena.
La cadena de producción está perfectamente equilibrada con capaci-

dad de 3 unidades de producto a la hora. Es razonable pensar que el flujo
del sistema es de 3 unidades cada hora. Este resultado sería lo que
podríamos satisfacer de la demanda.
Esta situación sería una consecuencia de un mundo perfecto pero la

realidad nos pone en nuestro sitio constantemente. Tenemos que tener
en cuenta dos circunstancias importantes:
• Las dependencias en la secuencia. El recurso o departamento B

no puede procesar un producto hasta que éste no lo ha sido por
A. Esta regla se aplica hasta D.
• La estadística nos demuestra que ningún recurso tiene una fiabi-

lidad del 100%. Tres unidades a la hora es una media, lo que
implica que podemos tener una desviación tipo mayor o menor.
Esto nos lleva a pensar que la cadena de producción no estará
siempre equilibrada.
Por otro lado, las dependencias entre los rectángulos siempre sufren
la siguiente regla: la desviaciones negativas siempre se transmiten y las
positivas sólo ocasionalmente por no decir nunca.
Si en la secuencia, y por cualquier situación, el rectángulo B sólo pro-

duce 2 unidades, el final del flujo será de dos unidades, es decir, sufrirá
la transmisión de la desviación negativa.
49
CAP 04 25/5/11 15:51 Página 50
¿Qué sucede si planteamos una desviación positiva? Si A produce 4

unidades y B hace lo mismo, seguiremos dependiendo de que C y D ten-
gan también la misma desviación positiva, es decir, no podemos garanti-
zar nada hasta el final del flujo.
En cualquier caso garantizar un sistema equilibrado es extraordinaria-

mente difícil. Lo más probable es que nos encontremos con situaciones
de este tipo.
Si un recurso produce por debajo de sus posibilidades será considera-

do ineficiente en su rendimiento. Conviene recordar que ésta sería la filo-
sofía del mundo de los costes que busca las mayores eficiencias locales.
Podríamos desacoplar las dependencias entre los recursos A y B y

entre B y C creando unos stocks o inventarios intermedios pero surgen
tres problemas:
• Empezamos a tener unos inventarios que crecen sin parar.
• Aunque la eficiencia local de C sea buena no suministra lo sufi-

ciente para D.
• Se crean conflictos entre los responsables de los recursos. Desde

luego, el responsable de D no está nada contento, los clientes
tampoco y el flujo del sistema es una incógnita.
Es claro que tenemos un conflicto que se crea por la confrontación de

dos formas distintas de gestión. Goldratt representa este conflicto de
forma gráfica.
50
CAP 04 25/5/11 15:51 Página 51
Cambio de Paradigma
Podemos traducir el término throughput, en este caso, como la

velocidad a la que el sistema genera dinero a través de las ventas.
También podríamos tomar la acepción de proteger el flujo en el gráfico
anterior.
¿Cómo podemos resolver un conflicto donde ambas formas de gestión

parecen tener razón?
Goldratt asegura que sólo si tengo un desequilibrio en la capacidad de

producción se podrá gestionar el flujo.
En el sistema anterior, el recurso con menor capacidad es el C (sólo

puede producir 2 unidades a la hora) lo cual induce a pensar que el siste-
ma también produce como máximo 2 unidades. El resto de recursos deben
proteger el flujo y que esto se realice con el menor inventario en curso.
TOC define cinco pasos para la gestión de un sistema:
51
CAP 04 25/5/11 15:51 Página 52
• Identificar la restricción o limitación.
• Explotar la restricción.
• Subordinar todas las demás políticas a la decisión anterior.
• Elevar la restricción.
• Volver al primer paso si se ha conseguido romper la restricción.
Veamos los cinco pasos aplicados al ejemplo anterior:
• En nuestro caso la restricción es el recurso C por ser el de menor

capacidad. Hemos IDENTIFICADO la restricción.
• Supongamos que C se ve afectado por desviaciones negativas, en

ese caso la productividad del recurso no se ve afectada, sino la
eficiencia de todo el sistema.
EXPLOTAR la restricción significa sacar el máximo partido posible

de ella y, por tanto, establecer unas políticas que nos permitan
obtener todo el valor del sistema sin recurrir a inversiones que, en
principio, pudieran no ser necesarias.
• Hemos dicho que entre los recursos existen unos vínculos (depen-
dencias) que deben subordinar las políticas a la decisión anterior.
Si C sólo puede producir 2 unidades a la hora, no tiene sentido
que el recurso B produzca más de 2 unidades a la hora, pero, a
su vez, si B tiene una desviación negativa, ello podría dar lugar a
una parada del sistema. Es conveniente proteger a C (la restric-
ción) de estas eventualidades con un inventario de materiales,
colocado delante de la restricción para no parar el proceso. Si B
tiene un problema, C puede tirar del inventario y no parar el flujo.
Esto es lo que se llama SUBORDINAR.
52
CAP 04 25/5/11 15:51 Página 53
Cambio de Paradigma
• Puede ser necesario aumentar la producción, normalmente por

exigencia de la demanda del mercado. Sólo en ese caso, ELEVA-
MOS la capacidad de la restricción.
• Si hemos conseguido resolver la restricción, VOLVER AL PRIMER

PASO es lo aconsejable. Esto significa localizar una nueva restric-
ción y, además evita que la inercia se convierta en la restricción
y, si reflexionamos sobre todo esto, veremos que iniciamos un
proceso de mejora continua.
De momento, a través del inventario colocado delante de C, hemos

garantizado que la restricción no pare su producción, pero, ¿cómo evita-
mos la dispersión de A y B? Estos dos recursos pueden ser más veloces
y producir un exceso de unidades que no puede procesar C.
Goldratt ilustra este caso cambiando la cadena de producción por un

pelotón de soldados que marchan en formación en sentido contrario al
flujo de materiales en la cadena anterior.
Nuestro simpático pelotón sale del campamento en perfecta forma-

ción. Al cabo de un tiempo, el soldado C, que es el más lento y, por tanto,
es la restricción, comienza a producir una dispersión en el pelotón.
53
CAP 04 25/5/11 15:51 Página 54
Una solución para evitar la dispersión consistiría en atar con una cuer-
da a todos los soldados. Si esto lo lleváramos al mundo de la cadena de
producción equivaldría a tener inventarios entre cada dos soldados y des-
cartamos esta solución anteriormente. Pero, ¿qué sucede si atamos al
primer soldado con el soldado que representa la restricción, es decir, con
el soldado más lento?
En este caso, el primer soldado tendrá que caminar con la velocidad

del más lento y el resto de soldados se agolparán, unos detrás del pri-
mero y otros detrás del más lento. El pelotón se distribuye a lo largo de
una distancia que será casi igual a la longitud de la cuerda. Si un solda-
do de las primeras líneas se detiene por la razón que sea, el soldado más
lento tiene espacio para seguir marchando.
Naturalmente, si el sargento del pelotón no está conforme con esta

solución, deberá ELEVAR la capacidad del soldado cuello de botella.
54
CAP 04 25/5/11 15:51 Página 55
Cambio de Paradigma
Volviendo al ejemplo de la cadena de producción podría pensarse que

hay un inventario delante del recurso C, pero si pensamos que las leyes
de Murphy pueden atacar duramente, en ocasiones podría darse la situa-
ción de agotamiento de dicho inventario.
En el mundo real, Goldratt propone un método de gestión (DBR) basa-

do en tres conceptos:
• DRUM o Tambor
• BUFFER o Amortiguador o Colchón
• ROPE o Cuerda
En el ejemplo de la cadena de producción, el Drum es la restricción,

realmente es el programa de la restricción que eleva la eficiencia de la
55
CAP 04 25/5/11 15:51 Página 56
misma a la categoría del sistema, es decir, al óptimo del sistema. El

recurso C procesa dos unidades a la hora y esas unidades son las que
se transmiten al resto de recursos posteriores y, por supuesto, al flujo
del sistema.
Rope (la cuerda) liga el programa de lanzamiento con la restricción.

Con esto tratamos de evitar que, en aras de las eficiencias locales de A
y B, estos recursos produzcan material que C no puede procesar, es
decir, la Cuerda sólo permite lanzar lo que necesita el Drum. A esta situa-
ción la denominamos Programa de Lanzamiento.
Otro problema a resolver es el de “cuándo lanzar”. Si lo hacemos

demasiado tarde pueden surgir las desviaciones negativas que afectarán
a C. Esta cuestión la resuelve el Buffer que es el tiempo que debemos
asignar a A y B para procesar lo que necesita C, es decir, el tiempo de
proceso más un margen de seguridad que permita trabajar a C pese a
posibles desviaciones.
Si lanzamos demasiado pronto, afectaremos el tiempo de respuesta,

en cuanto a plazo, e incrementaremos los inventarios en curso.
Podemos observar que programar la planta donde está la cadena de

producción requiere de poca programación. De hecho los distintos pro-
gramas sólo están donde se necesitan, restando complejidad al sistema.
Con los conceptos de cadena de montaje, JIT (Just In Time o Justo a

Tiempo) y TOC existen ciertas discrepancias según autores. Para
Goldratt, el JIT admite inventarios entre los recursos o centros de pro-
ducción y con TOC, se reducen los inventarios a aquellos, y sólo aquellos,
que están delante de la restricción. Con las tecnologías actuales JIT
puede admitir la desaparición de los inventarios, incluido el de la restric-
ción, funcionando con programas que se basan en el PULL o demanda de
los clientes y en las órdenes de lanzamiento para satisfacer la demanda,
junto con el programa de la restricción.
56
CAP 04 25/5/11 15:51 Página 57
Cambio de Paradigma
En cualquier caso, ambas teorías tratan de proteger el throughput del

sistema de forma imperativa, y ambas coinciden en que las eficiencias
locales no garantizan el flujo o la eficiencia del sistema.
Para Goldratt la cuerda, o mejor dicho, la longitud de la cuerda, es un

Buffer que define la cantidad de existencias que se permite acumular
delante de la restricción. Ello permite, en el caso de un problema de un
recurso anterior a la restricción que ésta pueda seguir funcionando al
contar con el margen de seguridad que proporciona el inventario y que,
en el fondo, también se constituye en un margen de tiempo, es decir, el
tiempo que la limitación puede seguir trabajando mientras se soluciona
la incidencia que obliga a usar, más de lo habitual, el inventario.
En los proyectos, los materiales y los inventarios de materiales, no

son relevantes, pero el tiempo, y los buffers de tiempo, sí son vitales.
Mientras en una cadena de producción el material está siempre disponi-
ble (otra cosa es que lo esté a tiempo), en los proyectos el tiempo se con-
sume y no se recupera.
Existe una frase propia del mundo de los proyectos que dice “el tiem-
po o los plazos se agotan, las excusas no”.
En el siguiente gráfico se representa un esquema de funcionamiento.
57
CAP 04 25/5/11 15:51 Página 58
En el gráfico se observa la cuerda que liga los recursos precedentes

al tambor y añadimos una segunda cuerda (Rope de despacho) que liga
la demanda al recurso tambor y que marca el tiempo necesario que debe
transcurrir, una vez finalizado el proceso del tambor, con la entrega del
producto final al cliente.
Resumen de conceptos empleados:
• El objetivo de cualquier empresa es el de aumentar las ganancias

en el corto y el largo plazo. El objetivo se alcanza aumentando el
througput (ingreso de dinero a través de las ventas) y reduciendo
los inventarios y los gastos operativos.
• La clave de TOC es que la operación de cualquier sistema com-

plejo radica en una gran cadena de recursos interdependientes
(máquinas, centros de trabajo, instalaciones) pero sólo unos
pocos de ellos, los cuellos de botella (llamados restricciones o
limitaciones) condicionan la salida de toda la producción.
• Conviene recordar que, según TOC, hay que identificar el eslabón

más débil y centrarse en él. Resuelta esta restricción con los siguien-
tes tres pasos, se buscaría otra limitación si fuera necesario.
• TOC crea soluciones simples y comprensibles para problemas

complejos.
• La forma de aplicar TOC a las empresas industriales consiste en

aplicar el método llamado Drum – Buffer – Rope (Tambor –
Inventario de Protección – Cuerda). Este método se conoce por las
siglas DBR.
• El Drum (tambor) se refiere a los cuellos de botella (restricciones o

limitaciones) que marcan el paso de toda la fábrica. El nombre de
tambor viene de que marca el ritmo de marcha de los otros recur-
sos como en un desfile. Si prefieren una analogía menos prusiana,
58
CAP 04 25/5/11 15:51 Página 59
Cambio de Paradigma
podemos decir que es el recurso que regula el paso entero del sis-
tema, como lo es el latido del corazón de una persona.
• El Buffer es un amortiguador de impactos basado en el tiempo

que protege al throughput de las interrupciones del día a día y ase-
gura que el tambor nunca se quede sin material. Los buffers que
trata TOC están basados en tiempos de proceso que hacen llegar
el material a los puntos críticos con cierta anticipación.
• Al tiempo de preparación y ejecución necesario para todas las ope-

raciones anteriores al tambor, más el buffer, se le denomina rope
(cuerda). Es más correcto denominarle longitud de la cuerda.
Es hora de volver al mundo de los proyectos, aplicando algunos de los

conceptos y métodos que se desarrollan en las plantas industriales,
especialmente TOC.
4.2. TOC Y LOS PROYECTOS
La aplicación de la Teoría de las Restricciones a los proyectos y el pos-

terior método de la Cadena Crítica nacen a principios de los años 90 y se
constituye como la mayor aportación a la Gestión de Proyectos de los últi-
mos tiempos. Nace, además, con un principio fundamental a tener muy
en cuenta:
LOS PROYECTOS NO SON EJECUTADOS POR MÁQUINAS O

ALGORÍTMOS MATEMÁTICOS.
LOS PROYECTOS SON EJECUTADOS POR PERSONAS.
Es corriente, en la planificación de un proyecto, utilizar el método del

Camino Crítico basado en modelos matemáticos y estimaciones con com-
ponentes estadísticos, pero no se tiene en cuenta el factor humano. El
comportamiento de las personas y su forma de pensar (por miedos,
59
CAP 04 25/5/11 15:51 Página 60
malas experiencias…) tienen una alta influencia en las estimaciones, pla-

nificaciones, controles y en general con todo lo que tiene que ver con la
gestión de un proyecto.
Todo lo que se expone a continuación tiene que ver con el comporta-

miento humano y con el objetivo de que los proyectos duren menos tiem-
po, reduzcan costes y satisfagan a los clientes.
Conviene recordar algunos problemas que se dan frecuentemente en

los proyectos, así como el encadenamiento de causas y efectos de resul-
tado indeseable.
Hay muchas quejas asociadas a los proyectos. Mostramos algunas de

ellas:
— Generalmente no se cumple con las fechas de entrega prometidas

originalmente.
— Hay demasiados cambios.
— Con demasiada frecuencia los recursos no están disponibles

cuando se les necesita.
— Las cosas necesarias no están disponibles a tiempo (información,

especificaciones, materiales, diseños, autorizaciones, etc.).
— Hay serias discrepancias sobre las prioridades de los proyectos.
— Se exceden los presupuestos.
— Se tienen que repetir los trabajos demasiadas veces.
En el siguiente gráfico causa-efecto se representa una situación típica

de los proyectos. Este tipo de gráficos se conocen como árboles de la
realidad.
60
CAP 04 25/5/11 15:51 Página 61
Cambio de Paradigma
Este tipo de gráficos pueden representar tanto la realidad con aspec-

tos negativos, como lo que se denominan árboles de la realidad futura
que representan la solución del anterior.
61
CAP 04 25/5/11 15:51 Página 62
4.2.1. Viejos vicios en los proyectos
La gestión de los proyectos está, en la mayor parte de las ocasiones,

plagada de vicios adquiridos, normalmente por malas experiencias, y que
distorsionan la planificación como la ejecución de los proyectos.
Naturalmente, estos vicios son atribuibles al pensamiento y comporta-
miento de las personas que participan en el proyecto.
Uno de los vicios contesta, de alguna manera, a la pregunta de ¿por

qué se estiman siempre plazos tan largos en los proyectos?, la contes-
tación es inmediata, se planifica con altos márgenes de seguridad.
Veamos a continuación que es lo que sucede.
Tomemos, para la estimación de las tareas de un proyecto, un méto-

do genérico, es decir, se aplica para cualquier tipo de proyecto sin nin-
guna influencia del tipo de industria o sector que pudiera manejar méto-
dos de estimación propios.
El método genérico que se va a utilizar se denomina Estimación por

Tres Valores. Este método toma en consideración el grado de incerti-
dumbre y de riesgo de la estimación. Este concepto se originó con el
método PERT. Este método utiliza tres estimaciones para definir un rango
aproximado de duración de una tarea. Las tres estimaciones son:
• Más probable. Es la duración de la tarea, en función de los recur-

sos que probablemente se asignarán, de su productividad, de las
expectativas realistas de disponibilidad para la tarea, de las
dependencias de otros participantes y de las interrupciones.
A esta estimación se le denomina, también, Estimación Modal y

se refiere a la duración que tareas idénticas o similares han teni-
do en otros proyectos.
• Optimista. La duración de la tarea está basada en el análisis del

mejor escenario posible para esa tarea.
62
CAP 04 25/5/11 15:51 Página 63
Cambio de Paradigma
Esto indica que la estimación solo tiene en cuenta consideracio-

nes inherentes a la tarea y, a lo sumo, al proyecto. Si el análisis
del escenario es detallado, la probabilidad de cumplimiento de la
estimación no supera el 1%.
• Pesimista. La duración de la tarea está basada en el análisis del

peor escenario posible para esa tarea.
Igual que en la anterior solo se tienen en cuenta consideraciones

inherentes a la tarea y, a lo sumo, al proyecto, es decir, no se valo-
ran posibilidades de guerras, invasiones alienígenas, catástrofes
naturales y otros actos de Dios. La probabilidad de cumplimiento
de esta estimación no supera el 1%.
Nota: La estimación más probable tiene de por sí cierta incertidumbre.
Se utiliza en PERT un promedio de las tres estimaciones para obtener

la estimación esperada de la tarea.
Estimación más probable: tM

Estimación optimista: tO
Estimación pesimista: tP
Estimación esperada: tE
La fórmula que aplica el método PERT es:
La estimación esperada (o duración esperada) resultante tiene una

probabilidad de cumplimiento de un 50%, por lo cual, seguimos con incer-
tidumbre.
63
CAP 04 25/5/11 15:51 Página 64
Nota del autor: En los últimos 30 años he impartido muchos cursos

de Gestión de Proyectos y cuando llegaba a este punto en mi exposición
se producían auténticos ataques de pánico y protestas masivas provoca-
dos por lo que se consideraba una incertidumbre inadmisible para los
asistentes a los cursos.
La curva representa la distribución beta de la probabilidad.
La forma de la curva depende de los valores de las tres duraciones

que se empleen. Si la duración esperada coincide con la más probable,
la curva tomaría forma de curva de Gauss.
64
CAP 04 25/5/11 15:51 Página 65
Cambio de Paradigma
Ejemplo:
La tarea A tiene una duración de 10 días. Como dijimos antes, la pro-

babilidad de cumplir el plazo es de un 50%. El responsable de la tarea
considera que no quiere asumir riesgos y le añade a la tarea un margen
de seguridad que aumenta la probabilidad a un 90%.
65
CAP 04 25/5/11 15:51 Página 66
Supongamos que con una duración de 15 días (hemos añadido 5 días

de margen de seguridad a la duración original) conseguimos una proba-
bilidad de un 90%.
Ésta es la razón por la cual los proyectos se estiman con plazos dema-
siado largos en el tiempo.
En el ejemplo asumimos que la estimación la realiza el responsable de

la tarea. Si sobre esta estimación la jerarquía que está por encima del res-
ponsable de la tarea, y están involucrados en el proceso de planificación,
añaden sus propios márgenes de seguridad, la estimación puede comenzar
a dispararse. A esta situación Goldratt la llama irónicamente el 10+5=20.
Si ésta es una práctica bastante habitual en los proyectos podemos

plantear una pregunta.
66
CAP 04 25/5/11 15:51 Página 67
Cambio de Paradigma
¿POR QUÉ SE RETRASAN TANTO LOS PROYECTOS SI HAY

TANTA PROTECCIÓN?
La contestación está en que los márgenes de seguridad provocan en

las personas la aparición de unas malas prácticas de consecuencias
nocivas.
Las malas prácticas son normalmente tres:
• El Síndrome del Estudiante
• El Síndrome de Parkinson
• La Multitarea
Síndrome del Estudiante: Se refiere a la costumbre de muchos estu-

diantes (todos hemos tenido esta costumbre alguna vez cuando estudiá-
bamos) a la hora de preparar un examen anunciado con suficiente tiem-
po. Este síndrome consta de tres etapas donde la primera consiste en
preparar y ordenar el material de estudio; la segunda en relajarnos, pues
disponemos de suficiente tiempo de preparación (o eso creemos) dedi-
cando el tiempo a otras cosas; y, por último, en la tercera etapa entra-
mos en un mundo de prisas para preparar el examen, sin apenas tiem-
po, y con la consiguiente dosis de desesperación y de frustración.
67
CAP 04 25/5/11 15:51 Página 68
Con los proyectos sucede algo similar:
— Primero nos aseguramos que disponemos de los medios nece-

sarios para poder ejecutar la tarea, los verificamos y los organi-
zamos.
— En segundo lugar, y debido a que disponemos de margen de segu-

ridad para la tarea, empezamos a dedicarnos a otras cosas (dedi-
carnos a otras tareas del proyecto, desarrollar otras actividades
ajenas al proyecto, etc.).
— Cuando se acerca la fecha de terminación planificada para la

tarea comenzamos a trabajar en ella desesperadamente sin cer-
teza de cumplir con el plazo.
Este síndrome es uno de los efectos nocivos que presentan los már-
genes de seguridad. Por otro lado, las prisas en la ejecución de la tarea
en la tercera etapa del síndrome además de no poder, normalmente,
cumplir el plazo, dan lugar a otros efectos indeseables como pérdida de
calidad, errores y un largo etcétera así como, un considerable aumento
del estrés.
Síndrome de Parkinson: Este síndrome se presenta cuando en la eje-

cución no se ha consumido el margen de seguridad (o solo una parte de
él), pudiéndose dar los siguientes fenómenos:
— No se informa de que la tarea ha finalizado para evitar que se

piense que se estimó con demasiado margen de seguridad y,
por tanto, la próxima vez se desconfíe del planificador de la
tarea.
— En algunas ocasiones se sigue trabajando en la tarea con adornos

innecesarios que nadie ha solicitado. Esta mala práctica es muy
popular en el mundo de la informática.
68
CAP 04 25/5/11 15:51 Página 69
Cambio de Paradigma
Multitarea: Otra mala práctica habitual se produce cuando a un recur-

so se le asignan varias tareas en simultáneo. Esta mala práctica tiene
las siguientes vertientes:
— Al recurso se le asignan tareas de un mismo proyecto que se sola-

pan en el tiempo (sobreasignación). Esta situación debería resol-
verse re-planificando el proyecto aunque implique modificaciones
que afecten a las fechas planificadas inicialmente.
Si las tareas afectadas pertenecen al camino crítico esta situa-

ción, lógicamente, es inaceptable.
Si las tareas no pertenecen al camino crítico, el recurso puede

optar por trabajar en ellas repartiendo su esfuerzo a cada una,
pero esta opción termina por retrasar la fecha de finalización de
las tareas.
— Al recurso se la asignan tareas de distintos proyectos. Este tipo

de sobreasignación es más peligrosa que la anterior pues apare-
cen conflictos de intereses y prioridades. Si el recurso quiere
satisfacer a todo el mundo, los problemas serán similares al otro
tipo de sobreasignación. La empresa deberá tener claras las prio-
ridades de los proyectos en curso y el gestor de la cartera de pro-
yectos deberá evitar la sobreasignación de los recursos críticos.
Veamos un ejemplo de multitarea. Supongamos un recurso que

tiene asignadas tres tareas, cada una con una duración de 10
días. Dicho recurso, ante la ausencia de clones, coloca las tareas
en secuencia, pero la finalización de las tareas compromete a
otras tareas siguientes a ellas en el proyecto. A su vez, el sufrido
recurso quiere contentar a todo el mundo y decide dedicar 5 días
alternativos a cada una de ellas.
69
CAP 04 25/5/11 15:51 Página 70
La tarea A tarda ahora de 20 días. Lo mismo sucede con las

tareas B y C que duplicarán sus duraciones en el calendario.
Hay que evitar estas malas prácticas especialmente la

multitarea, que es la más nociva.
Veamos ahora la aplicación de los cinco pasos de TOC a los pro-

yectos.
4.2.2. Los cinco pasos de TOC en los proyectos
El primer paso de TOC consistía en IDENTIFICAR la restricción o limi-

tación. Observemos el siguiente ejemplo de un pequeño proyecto.
70
CAP 04 25/5/11 15:51 Página 71
Cambio de Paradigma
El gráfico de Gantt nos muestra la red de actividades del proyecto. El

camino o ruta más largo de tareas dependientes con relaciones de pre-
cedencia que determinan la duración del proyecto se le denomina cami-
no crítico o ruta crítica.
En este ejemplo, el camino crítico lo componen las tareas A, D y G.
Si el camino crítico marca la duración del proyecto ello significa que

cualquier retraso en el mismo implica un retraso en la fecha de finaliza-
ción del proyecto. No se admite ningún retraso en las tareas que com-
ponen dicho camino crítico. Las otras tareas restantes dan lugar a otros
caminos que disponen de ciertas holguras que permiten, a su vez, cier-
tos retrasos en su ejecución (hasta cierto límite).
Ahora surge la siguiente pregunta:
¿HAY UNA MAYOR RESTRICCIÓN QUE LA QUE IMPONE

EL CAMINO CRÍTICO?
Desde luego que no. Es el mejor candidato a la hora de identificar la

restricción del proyecto. Todos nuestros esfuerzos deben estar concen-
trados en proteger dicho camino.
Comencemos con el segundo paso que consiste en EXPLOTAR la res-

tricción. Recordemos que en TOC hablamos de la ineficiencia de las
mejoras locales y que era más efectivo proteger el flujo del sistema.
En los proyectos sucede algo similar. Un responsable de proyecto vuel-

ca su atención y sus controles en las tareas del proyecto cuando, real-
mente, debería focalizarse en el proyecto, es decir, debemos crear una
protección para el proyecto como un todo. A esta protección la llamare-
mos buffer del proyecto.
71
CAP 04 25/5/11 15:51 Página 72
Veamos ahora el tercer paso de TOC que es SUBORDINAR.

Recordemos que en el sistema visto en TOC, aquellos recursos que no
eran la restricción debían subordinarse a ella.
En proyectos, la subordinación está en las rutas no críticas respecto

a la crítica. Estas rutas desembocan, en un momento dado, en la críti-
ca y pueden tener una incidencia negativa en la duración del proyecto,
debida a retrasos en dichas rutas por problemas en ellas. Siguiendo el
mismo criterio anterior, establecemos protecciones entre las rutas no
críticas y la ruta crítica. A estas protecciones las llamaremos buffers de
alimentación.
El cuarto paso consiste en ELEVAR la restricción. Estamos protegien-

do el proyecto con los buffers pero podemos considerar la posibilidad de
disminuir tiempos con mayor capacidad de recursos y, sobre todo, mejo-
rando los plazos de las tareas a ejecutar por subcontratistas y provee-
dores (duras batallas de negociación).
Estamos en la etapa de planificación del proyecto. No tiene mucho

sentido, en esta etapa, aplicar el quinto paso de TOC que consistía en
VOLVER AL PRIMER PASO para evitar inercias de descuido. Tendrá sen-
tido en la etapa de ejecución cuando tenga que plantearse, si es nece-
sario, una re-planificación de lo que resta del proyecto por la causa que
fuera.
El lector podría pensar que una limitación importante que justificaría

el empleo del quinto paso de TOC es la falta de recursos, pero esto no
constituye una limitación por lo siguiente:
• No existen infinitos recursos, por lo cual no podemos plantear

como limitación algo que en la etapa de planificación no está con-
cretado.
• En la etapa de ejecución lo que realmente importa es que los

recursos estén disponibles para las tareas cuando se necesitan.
72
CAP 04 25/5/11 15:51 Página 73
Cambio de Paradigma
A esto haremos referencia cuando desarrollemos el método de

cadena crítica.
• Si una empresa tiene recursos escasos para afrontar sus proyec-

tos, deberá plantearse una estrategia de adquisición de recursos,
vía contratación o vía subcontratación, antes de decidir la realiza-
ción de un proyecto. Una vez planteado el proyecto, los recursos
no se consideran una limitación.
Es lógico que la aplicación de TOC a los proyectos, más evitar las

malas prácticas en los mismos, producirán cambios en la planificación
original.
Es necesario que abordemos una sistemática para ordenar estas

ideas y, por tanto, cambiar el método tradicional CPM (Critical Path
Method), método del camino crítico por un nuevo método llamado CCPM
(Critical Chain Project Management), gestión de proyectos con cadena
crítica.
Esta forma de gestión de proyectos data de principios de los noventa

y a lo largo de casi dos décadas ha tenido una fuerte aceptación pero en
muchos países aún no se ha introducido suficientemente. Aceptar un
nuevo paradigma no es fácil, sobre todo porque hay que liberarse del
anterior.
Con este nuevo paradigma conseguimos terminar los proyectos en el

plazo establecido, incluso antes, manteniendo el alcance y los criterios
de calidad establecidos, así como gestionando el riesgo de forma ade-
cuada.
Otro punto fuer te de la cadena crítica es el de incidir, en la planifi-

cación, en la gestión de recursos, especialmente con los recursos crí-
ticos. Hay que tener en cuenta que la gestión del camino crítico no con-
templa la gestión de los recursos asignados a las tareas y lo que ello
conlleva.
73
CAP 04 25/5/11 15:51 Página 74
4.3. GESTIÓN DE LA CADENA CRÍTICA (CCPM)
4.3.1. Sistemática de la cadena crítica
A continuación se describen los pasos para la aplicación del nuevo

método de gestión para los proyectos.
1. Realizar el diagrama del proyecto con la obtención del camino

crítico.
2. Determinar holguras.
3. Programar lo más tarde posible (opcional).
4. Añadir recursos a las tareas e identificar aquellos que sean crí-

ticos.
5. Quitar los márgenes de seguridad de las tareas.
6. Resolver conflictos de recursos.
7. Identificar la cadena crítica.
8. Incorporar los buffers.
A continuación aplicamos esta sistemática a un ejemplo de un pro-

yecto desarrollado con Microsoft Project y un add-in llamado CCPM+.
74
CAP 04 25/5/11 15:51 Página 75
Cambio de Paradigma
Ejemplo
Suponemos un proyecto con las siguientes tareas y sus correspon-

dientes duraciones.
Final no es una tarea, es un hito que señala el fin de proyecto. En la

columna de la derecha están señaladas las tareas predecesoras o pre-
cedentes.
Obtenemos ahora el Gantt del proyecto y su camino crítico, así como

las holguras de las rutas no críticas.
75
CAP 04 25/5/11 15:51 Página 76
El camino crítico está formado por las tareas C, F y G.
La ruta A, D y G presenta una holgura de 6 días.
La ruta B, E y G presenta una holgura de 2 días.
El proyecto tiene una duración de 26 días.
Hemos completado los dos primeros pasos. El tercer paso, señalado

como opcional, es discutible y además puede plantear algunos proble-
mas con el software que se utilice (en nuestro caso se debería posponer
por imposición del add-in utilizado).
Quienes defienden retrasar el comienzo de algunas tareas que en la

planificación figuran en paralelo y no pertenecen al camino crítico argu-
mentan lo siguiente:
— Ciertas tareas pueden requerir hacer alguna inversión y, por tanto,

mejor retrasar su comienzo. Este argumento es lógico para un con-
table o para la persona que controle los costes y los gastos del
proyecto.
— Otro argumento es el de la pérdida de focalización, por parte del

responsable del proyecto, ante un considerable número de tareas
de arranque. Desde el inicio del proyecto, su responsable es un
firme candidato a “volverse loco”.
76
CAP 04 25/5/11 15:51 Página 77
Cambio de Paradigma
— El último argumento se basa en que puede ayudar a identificar los

conflictos de recursos en la planificación del proyecto.
El primer argumento es válido para situaciones con inversiones muy

fuertes.
El segundo argumento puede ser válido para grandes proyectos que

pueden tener un elevado número de tareas de inicio.
El tercer argumento es muy discutible, pues forzamos situaciones

que, en principio, no se daban.
En cualquier caso deberíamos jugar con las holguras y nos llevaría a

plantearnos, para retrasar el comienzo de estas tareas, cuánta holgura
utilizaríamos. Tenemos que tener en cuenta que si utilizamos toda la hol-
gura, todas las rutas terminan siendo críticas.
En el ejemplo tenemos tres tareas en paralelo en el inicio y no aplica-

remos este paso.
Abordamos ahora la asignación de recursos. Los recursos asignados

al proyecto se presentan a continuación.
77
CAP 04 25/5/11 15:51 Página 78
A continuación presentamos el diagrama de Gantt con los recursos

asignados a las tareas.
Este diagrama se presenta con la vista que ofrece el add-in CCPM+.

La aparición de la columna llamada Duración de bajo riesgo la comenta-
remos posteriormente.
Identificamos un recurso crítico o cuello de botella que es Javier.

Recuerden que no queremos, bajo ningún concepto, que Javier caiga en
la mala práctica de trabajar en multitarea, por lo tanto debemos nivelar
los recursos utilizando el MS Project. El resultado se presenta a conti-
nuación.
78
CAP 04 25/5/11 15:51 Página 79
Cambio de Paradigma
Observamos que el proyecto se prolonga un día más.
A continuación tenemos el paso de quitar los márgenes de seguridad

de las tareas. En el ejemplo asumimos que se doblaron las duraciones
de las tareas respecto a la duración media. Para ello empleamos la barra
del add-in CCPM+.
Antes de aplicar el factor de duración copiamos la columna Duración

y la pegamos en la columna Duración de Bajo Riesgo.
A continuación aplicamos el factor de duración que en el caso pro-

puesto es del 50%.
79
CAP 04 25/5/11 15:51 Página 80
El resultado se muestra a continuación.
El software ordenó las tareas del recurso que presentaba conflicto

(Javier) en un orden lógico. Si este orden no es el deseado, habría que
haber dotado a dichas tereas de prioridades para cambiar el orden.
Si posteriormente clicamos los botones de la barra de CCPM+

siguientes:
80
CAP 04 25/5/11 15:51 Página 81
Cambio de Paradigma
El resultado final es el siguiente:
Las aparentes nuevas tareas que aparecen son ficticias puesto que
representan buffers de tiempo. Hay dos buffers de alimentación para pro-
teger, en este caso, a la cadena crítica y un buffer de proyecto para pro-
teger al mismo.
La cadena crítica está formada por las tareas B, D, E y G que, como

era de esperar, no coincide con el camino crítico.
La fecha de terminación del proyecto sería a media jornada del 6 de

mayo. La ganancia en tiempo o plazos del proyecto es importante.
Es conveniente recordar que se trabajará con duraciones exigentes

para las tareas al eliminar los márgenes de seguridad de las mismas,
pero estamos protegidos por el buffer del proyecto.
81
CAP 04 25/5/11 15:51 Página 82
En la gestión de proyectos, la cadena crítica es la secuencia de

precedencias y tareas dependientes de recursos que evitan que
un proyecto, al que se le dan recursos limitados, pueda ser com-
pletado en un tiempo menor. Si los recursos de un proyecto estu-
viesen siempre disponibles en cantidades ilimitadas, entonces la
cadena crítica de un proyecto sería igual a su camino crítico.
4.4. GESTIÓN DE LOS BUFFERS
Una de las aportaciones más importantes del CCPM está en la ges-

tión de los buffers. Tenemos que pensar, en el tiempo de ejecución del
proyecto, que nuestro sistema de control estará basado en los buffers y
no en las tareas ni en los hitos. Esto facilita la labor del responsable del
proyecto, que a menudo se veía sometido a innumerables revisiones y
reuniones de control, dedicando un tiempo cada vez más escaso y con
unos resultados confusos y de proyección hacia el final del proyecto que
resultaban una incógnita.
Las reuniones de control y las revisiones, ante posibles desviaciones

que requerían acciones correctivas, se producían demasiado tarde (se
detectaba tarde la desviación) y el enunciado de las acciones usaban de
forma desmedida el impersonal y el condicional con frases como estas:
• Deberíamos hacer…
• Habría que avisar…
• Si tengo más recursos quizás…
La gestión ahora se centra en la cadena crítica y en el consumo de

los buffers. A medida que se va completando la cadena crítica vamos
vigilando el consumo del buffer del proyecto. Hay que recordar que tene-
mos los buffers de alimentación para proteger la cadena crítica y que si
alguno se consume en su totalidad seguimos teniendo la protección del
buffer del proyecto.
82
CAP 04 25/5/11 15:51 Página 83
Cambio de Paradigma
Esto no quiere decir que no se elaboren informes de progreso. Los

responsables de las tareas irán informando de sus progresos, especial-
mente de las tareas pertenecientes a la cadena crítica.
El software de CCPM+ tiene una función que consiste en un gráfico

que permite visualizar el consumo del buffer del proyecto respecto al pro-
greso de la cadena crítica. En color distinguiríamos tres zonas con los típi-
cos colores de un semáforo.
El gráfico tiene esta apariencia.
83
CAP 04 25/5/11 15:51 Página 84
La zona verde indica que la situación no requiere intervención alguna,

por eso se llama zona de observación.
La zona amarilla indica una situación que requiere acciones preventi-

vas. Hay que investigar la causa del consumo peligroso del buffer del pro-
yecto y planificar las acciones para corregir la tendencia.
La zona roja indica una situación que sobrepasa el límite tolerable y

se tendrán que tomar medidas respecto al rumbo del proyecto.
En la medida que el proyecto avanza, el gráfico presenta formas como

la que sigue:
A continuación se presenta una tabla, a modo de ejemplo, con distin-

tas situaciones.
84
CAP 04 25/5/11 15:51 Página 85
Cambio de Paradigma
4.5. TAMAÑO DEL BUFFER DEL PROYECTO
El tamaño del buffer del proyecto es flexible y conviene definirlo con

cierta prudencia. En principio, el tamaño puede definirse como la suma
de los márgenes de seguridad de las tareas del camino crítico, pero esto
sería excesivo.
Pese al postulado de Tylczak, un seguidor de Murphy, que dice que los

sucesos fortuitos tienden a suceder todos juntos, la verdad es que, la
probabilidad de ocurrencia conjunta de eventos independientes, es
menor que la suma de las probabilidades de ocurrencia de cada uno de
estos eventos.
En muchas ocasiones se tiende a darle al buffer del proyecto el 50%

de la suma de los márgenes de seguridad como tamaño, pero puede esta
solución, sin descartar que sea correcta, tener un carácter salomónico.
Lo cierto es que el responsable del proyecto deberá tener en cuenta

factores de riesgo como:
— Tamaño y tipo de proyecto.

— Si es un proyecto novedoso, por ejemplo, por el tipo de tecnología
a emplear.
— Por el grado de experiencia del equipo en el tipo de proyecto.
85
CAP 04 25/5/11 15:51 Página 86
Si el proyecto presenta alto riesgo, entonces el tamaño del buffer

podría ser 2/3 de la suma de los márgenes de seguridad. Si se consi-
dera, en principio, un proyecto de bajo riesgo, entonces podemos consi-
derar un tamaño de 1/3.
En cualquier caso, la idea es tener a nuestro proyecto protegido de las

típicas eventualidades que se puedan presentar.
4.6. BUFFER DE RECURSOS CRÍTICOS
Los buffers de recursos (capacity buffers) no son amortiguadores

como hasta ahora los hemos contemplado. El adjetivo crítico es por aque-
llos recursos que no están estrictamente asignados al proyecto, por per-
tenecer a un departamento que presta servicios a distintos proyectos. Lo
cierto es que tenemos que controlar que estos recursos estarán dispo-
nibles en el momento que sean requeridos para no provocar retrasos en
la ejecución de las tareas que deben realizar.
No es posible, aunque nos gustaría, disponer de un banquillo de

suplentes por si fuera necesario, ello sería una ruina para el proyecto y
para la empresa. En previsión de posibles problemas podemos emplear
una táctica de avisos. A una semana del comienzo de una tarea asigna-
da a un recurso crítico, recordamos a dicho recurso de la necesidad de
su concurso, lo repetimos tres días antes del comienzo de la tarea y, por
último, el día antes. De esta forma, en el peor de los casos, es muy pro-
bable que podamos detectar el conflicto a tiempo y tomar las acciones
correctoras a tiempo.
Por cierto, si en una empresa existen recursos bajo la denominación

de sabio, experto o especialista, tendrán localizados a los recursos críti-
cos.
86
CAP 05 25/5/11 15:55 Página 87
CAPÍTULO 5
EL DILEMA DEL ALCANCE DEL PROYECTO

Y EL PENSAMIENTO LEAN
CAP 05 25/5/11 15:55 Página 89
El Dilema del Alcance del Proyecto y el Pensamiento Lean
5.1. PROBLEMAS CON EL ALCANCE DEL PROYECTO
Uno de los problemas principales que surgen en los proyectos es el

del ALCANCE de los mismos. Las definiciones que proporciona el PMBOK
al respecto son las siguientes:
• Alcance: La suma de productos, servicios y resultados que se pro-

porcionaran como un proyecto.
• Alcance del producto: Los rasgos y funciones que caracterizan a

un producto, servicio o resultado.
• Alcance del proyecto: El trabajo que debe realizarse para entre-

gar un producto, servicio o resultado con las funciones y caracte-
rísticas especificadas.
89
CAP 05 25/5/11 15:55 Página 90
No es difícil imaginar que en el planteamiento del alcance de un pro-

yecto está la fuente de innumerables problemas. En el capítulo 1 se expu-
sieron ejemplos de proyectos muy ambiciosos (con un gran alcance) que
tuvieron grandes desviaciones en plazos y presupuestos.
Sin necesidad de utilizar ejemplos de enormes proyectos, el alcance

siempre se desvirtúa en proyectos de inferior magnitud. La razón de este
problema radica en la falta de precisión a la hora de definir el alcance y,
sobre todo, en establecer quién debe definirlo.
Los proyectos, a su conclusión, entregan bienes y servicios para ser

utilizados o vendidos por/a clientes o consumidores. Ellos deberían defi-
nir, de manera directa o indirecta, el alcance del producto o servicio y, por
tanto, el alcance del proyecto. A pesar de este planteamiento lógico,
seguimos obstinados en sustituir al cliente en su indiscutible papel prin-
cipal en la definición del alcance.
Tanto en producción, logística, proyectos y otras áreas empresariales,

distintas metodologías de gestión significan al cliente como el eje funda-
mental de su contenido y razón de ser. En los puntos 3 y 4 de este capí-
tulo se plantea el pensamiento lean y los proyectos lean que ahondan en
esta problemática.
En resumen, si queremos evitar serios problemas en nuestros pro-

yectos, debemos focalizarnos en los clientes y no perder esta focaliza-
ción en ningún punto del proyecto.
5.2. EJEMPLO EN PROYECTOS DE TECNOLOGÍAS DE LA

INFORMACIÓN
El sector de las Tecnologías de la Información, históricamente ha sido

uno de los más afectados por los problemas producidos por la mala defi-
nición del alcance de los proyectos.
90
CAP 05 25/5/11 15:55 Página 91
Si medimos el impacto de la mala definición del alcance por el por-

centaje de utilización del producto y/o servicio en este sector, los últimos
datos producen escalofríos. Nos referimos al porcentaje de prestaciones
del producto/servicio realmente utilizados.
7%
Siempre
13 % Nunca
Frecuentemente
Rara vez
45 %
Algunas veces Nunca Algunas veces
16 %
Frecuentemente
19 % Siempre
Rara vez
En España es muy difícil disponer de datos basados en estudios simi-

lares como el presentado y que se realizó en Estados Unidos y, si los
hubiera, no serían muy fiables dado nuestro carácter tendente a no reco-
nocer la realidad.
Se puede argumentar que los clientes o usuarios cambian constante-

mente los requisitos y las especificaciones, pero ello llevaría a aumentar
los plazos de entrega y los costes y no a la escasa utilización de las pres-
taciones del producto/servicio. Realmente lo que sucede es que en el
camino (el desarrollo del proyecto) los propios productores han añadido
adornos o prestaciones que el cliente o el usuario no había solicitado y,
por lo cual, no debería pagar y que si no se les cobra, incrementan ton-
tamente los costes del proyecto.
91
CAP 05 25/5/11 15:55 Página 92
Para empezar a evitar estos desatinos, la filosofía o pensamiento

Lean enunció una serie de principios encaminados a la idea de girar la
gestión de los sistemas empresariales en torno al cliente así como, la eli-
minación de los despilfarros o desperdicios que se producen en dicha
gestión.
El término inglés Lean no tiene una equivalencia exacta en castellano

y existen diversas traducciones dentro del marco empresarial.
• Restringido
• Reducido
• Eficiente
Personalmente prefiero la última traducción. Proyectos Lean serían

proyectos eficientes.
En los siguientes puntos se exponen conceptos fundamentales de

Lean y su aplicación a los proyectos.
5.3. EL CONCEPTO DE LEAN Y SU EXPANSIÓN
Filosofía, pensamiento o administración Lean son términos que defi-

nen una forma moderna de gestión. El pensamiento Lean nace en la
década de los noventa en las fábricas de Toyota. Este pensamiento,
traducido en organización del trabajo y en la gestión de proyectos, es
impulsado por Taiichi Ohno1 y otros miembros de Toyota Motor
Company.
1
Taiichi Ohno (1912-1990) fue el ingeniero que diseñó el sistema de producción Just In Time (JIT)
dentro del sistema de producción del fabricante de automóviles Toyota.
92
CAP 05 25/5/11 15:55 Página 93
En contraste con las teorías de Ford, también pertenecientes a la

industria de automoción, que proponía producción masiva con grandes
cadenas de montaje, Toyota se encaminaba a una producción más con-
trolada.
Evidentemente, el pensamiento Lean no es tan trivial. La comparati-

va solo ofrece una visión general y tenemos que entrar en más detalle.
Una de las grandes preocupaciones de Ohno fue la gran cantidad de

despilfarros o desperdicios (muda en japonés) que se producían en cual-
quier sistema. Se considera muda aquellas actividades humanas que
absorben recursos, pero no crean valor. El valor solo puede ser definido
por el cliente. Y solamente es significativo cuando se expresa en térmi-
nos de un producto y/o servicio que satisface las necesidades del clien-
te a un precio concreto, en un momento determinado.
93
CAP 05 25/5/11 15:55 Página 94
Ohno estableció una lista de despilfarros en el ámbito de la produc-

ción física:
• Defectos en los productos
• Sobreproducción de bienes no necesarios
• Existencias de productos esperando procesamiento o consumo

adicional
• Procesamiento innecesario
• Movimientos de personal no necesarios
• Transporte de productos innecesarios
• Esperas de los empleados a que finalice una actividad preceden-

te
Otros autores, como Womack y Jones2, han añadido un tipo de des-

pilfarro:
• Diseño de bienes y servicios que no responden a las necesidades

de los clientes.
La misma tipología de muda en la producción se aplica a la muda en

la gestión de pedidos y en el desarrollo de productos.
El pensamiento Lean se fundamenta en cinco principios:
2
Womack y Jones autores de “Lean Thinking'” , extensa y clásica obra que explica tanto los funda-
mentos como casos prácticos de lo que se ha dado en llamar 'Lean production' o, de forma más
general, 'Lean management', y que se inspira en el afamado TPS (Toyota Production System).
94
CAP 05 25/5/11 15:55 Página 95
• Definir el valor desde la perspectiva del cliente
• Identificar el flujo del valor
• Optimizar el flujo del valor
• Desarrollar un sistema Pull
• Buscar permanentemente la perfección
Anteriormente hemos definido el concepto de valor. Solo nos queda

añadir que, de ahora en adelante, valor y despilfarro o desperdicio serán
enemigos a muerte. Todos los esfuerzos del pensamiento Lean están
encaminados a eliminar el mayor número de despilfarros posibles hasta
su extinción.
Al principio no es fácil ponerse de acuerdo en que actividades gene-

ran valor y cuales son despilfarros. La distinción se hace más precisa
cuando definimos el flujo de valor.
El flujo de valor es el conjunto de todas las acciones específicas

requeridas para pasar un producto y/o servicio determinado por las tres
tareas de gestión críticas de cualquier empresa:
• Tarea de solución de problemas que se inicia en la concepción,

sigue en el diseño detallado e ingeniería, hasta su lanzamiento a
producción.
• Tarea de gestión de la información que va desde la recepción del

pedido hasta la entrega, a través de una programación detallada.
• Tarea de transformación física, con los procesos existentes desde

la materia prima hasta el producto acabado en manos del consu-
midor.
95
CAP 05 25/5/11 15:55 Página 96
Esto implica un flujo de valor completo en cuyo análisis podemos tener

una identificación fiable de los despilfarros y su tipología.
Se distinguen dos tipos de desperdicio en las actividades que no gene-

ran valor:
• Desperdicio de tipo 1, que es una actividad parcialmente sin valor

añadido, pero necesarias para completar las tareas. Solo añade
costos al proyecto.
• Desperdicio de tipo 2, que es una actividad que carece de valor

añadido. Desperdicio a eliminar.
Un ejemplo de desperdicio tipo 1 es la actividad de inspección y prue-

bas del código de una aplicación informática. Los usuarios de la aplica-
ción solo miran los resultados y prestaciones de dicha aplicación. Para
ellos las tareas de pruebas no les añaden valor, solo les añade valor que
el software corresponde con sus requisitos.
Si en el contrato de desarrollo de la aplicación se estipula la fase de

pruebas y se genera un entregable (documento de los resultados de la
prueba, juego de datos de prueba…) que se dispone para el cliente,
entonces el desperdicio de tipo 1 se transforma en valor.
Un ejemplo de desperdicio de tipo 2 lo encontramos en las ofertas

que muchas empresas realizan para presentarse a concursos convoca-
dos por la Administración Pública. La convocatoria del concurso tiene un
pliego de condiciones técnicas, entre otros pliegos, que expresan clara-
mente lo que el cliente quiere que la empresa cumplimente, pero existe
una tendencia casi enfermiza de añadir detalles o información que nadie
ha pedido, pensando que cuanto más papel, mejor será la oferta. Nadie
piensa que, el funcionario que revisa la oferta no encuentra ningún valor
añadido en ese exceso de información, incluso puede irritarle tanto papel
innecesario. Nos encontramos con un desperdicio de tipo 2 que habría
que eliminar.
96
CAP 05 25/5/11 15:55 Página 97
El tercer principio del pensamiento Lean, nos dice que, una vez iden-
tificado el flujo de valor, hay que eliminar los obstáculos que frenan el
transcurrir del flujo. Procesamientos por lotes, colas de espera, departa-
mentos funcionales, son ejemplos de obstáculos que frenan el flujo hacia
el cliente.
Un corredor de 400 metros vallas es un buen ejemplo. Tiene dos obse-

siones, ganar la carrera y no tropezar con alguna valla. Lamentablemente
en las empresas hay muchas vallas que hay que suprimir o minimizar.
El cuarto principio, sistemas Pull (atracción) son uno de los grandes

logros del pensamiento Lean y consiste en que se suprima el carácter
totémico de las previsiones de ventas a los consumidores, sustituyendo
las previsiones por la demanda real de ellos.
Las editoriales son un buen ejemplo. Lanzan un libro, con un número

de ejemplares moderado, y según la demanda de los lectores se van
imprimiendo nuevas ediciones.
Por último, el quinto principio nos incita a la búsqueda constante de

la perfección. Cuando el pensamiento Lean se extiende por toda la
empresa y los equipos de trabajo piensan y actúan de forma Lean, es nor-
mal que se encuentren nuevos desperdicios y se introduzcan mejoras por
eliminación de los mismos. Evitamos así la inercia que lleva a la degra-
dación de los logros conseguidos.
97
CAP 05 25/5/11 15:55 Página 98
Adicionalmente, Lean incorpora elementos de Six Sigma, TQM y otros

métodos como:
• Calidad perfecta a la primera: búsqueda de cero defectos, detec-

ción y solución de los problemas en su origen
• Mejora continua: reducción de costes, mejora de la calidad y

aumento de la productividad.
• Construcción y mantenimiento de una relación a largo plazo con

los proveedores llegando a acuerdos para compartir el riesgo, los
costes y la información.
Un éxito de una empresa Lean consiste en establecer un trío armoni-

zado con los clientes y los proveedores.
Para implantar Lean en una empresa, lo ideal es hacerlo en su tota-

lidad pero, en una empresa de cier to tamaño, ello puede conllevar un
esfuerzo de hasta cinco años. Muchas empresas, dependiendo de sus
características y del sector al que per tenecen, comienzan con áreas
determinadas. En el caso de este libro, aplicaremos Lean a los pro-
yectos.
5.4. CONSEGUIR PROYECTOS LEAN (LPM)
Aunque no lo crean, el mundo de los proyectos está plagado de muda.

De hecho anticipamos un desperdicio basándonos en una frase de
Benjamín Franklin.
Si el tiempo es lo más caro, la pérdida de tiempo es el mayor de los

derroches.
En el mundo de los proyectos transformamos la frase en la siguiente:
98
CAP 05 25/5/11 15:55 Página 99
El mayor desperdicio en un proyecto es el

desperdicio de tiempo
Evidentemente hay muchos más desperdicios, pero el del tiempo en

un proyecto se lleva el primer premio. Téngase en cuenta que el tiempo
que se pierde en un proyecto no se recupera, con el impacto en la ges-
tión que ello supone.
En un proyecto siempre estamos apretados de tiempo, pero en pocas

ocasiones nos hemos parado a pensar en cuántas horas laborables al
día dedicamos realmente al proyecto y, de esas, cuántas dedicamos a
actividades que producen valor al proyecto.
Suponiendo que toda su jornada laboral está asignada a un proyecto,

cumplimente la siguiente tabla:
99
CAP 05 25/5/11 15:55 Página 100
Modifique, si lo considera oportuno, y continúe rellenando la tabla

hasta el final de la jornada, se llevará una gran sorpresa.
Si establecemos qué tipo de desperdicios se sitúan en la última

columna, la situación se vuelve aún más crítica.
Dejamos por un momento al desperdicio del tiempo y nos centramos

en los cinco principios Lean para los proyectos.
Al inicio del capítulo, se comentó que el alcance debía ser definido, en

términos de producto/servicio objeto del proyecto, por el cliente. Los
requisitos y especificaciones deben ser definidos por el cliente, colabo-
rando en su diseño detallado y revisión posterior. Solo así podemos estar
seguros de tener una definición del valor bajo la óptica del cliente, fiable.
Una forma de evaluar que podemos considerar como valor consiste en

considerar cualquier cosa por la cual el cliente está dispuesto a pagar.
Cualquier actividad que no incremente el precio que pagaría el cliente
solo añade costos al proyecto.
Tenemos, a continuación, que identificar el flujo de valor. Recordemos

que se compone de todas las actividades y tareas que se precisan com-
pletar para entregar el producto y/o servicio final al cliente.
Para identificar las actividades que añaden valor de las que no aplica-
mos una corriente de valor similar a la del apartado anterior.
• Del concepto de diseño a la producción
• De la iniciación a la realización de una orden
• Del envío al pago de la factura
En los proyectos es importante que cada tarea de un proyecto debie-

ra orientarse hacia la creación de entregables. Cualquier tarea que no
100
CAP 05 25/5/11 15:55 Página 101
genere un entregable debe ser puesta bajo sospecha por no entregar

valor.
Se considera un entregable al resultado de la ejecución de una tarea.

Puede ser un elemento físico (producto intermedio o componente), un
prototipo, un documento, unos planos, etc.
Después es necesario distinguir los desperdicios de tipo 1 y 2, elimi-

nar los segundos y tratar, si es posible, de dotar a los de tipo 1 de valor
añadido.
El tercer principio, optimizar el flujo de valor, por eliminación de los

obstáculos que se cruzan en el camino entre el valor definido en el alcan-
ce del proyecto y la entrega del producto y/o servicio al cliente.
El ejemplo de un río nos sirve para ilustrar el discurrir del flujo de

valor. A medida que caen obstáculos (ramas o árboles) en el río, su fluir
se vuelve más lento y tortuoso, incluso puede provocar problemas en el
entorno.
101
CAP 05 25/5/11 15:55 Página 102
Con los proyectos se produce algo similar. Veamos cuáles son sus
ramas o árboles.
Algunos obstáculos típicos son:
• Los departamentos funcionales
• Los ciclos de aprobación
• Cambio constante de requisitos
• Interferencias de la dirección
Si hay algo que esté en las antípodas del pensamiento Lean eso es
una organización funcional. De hecho, si la empresa mantiene este tipo
de organización, es imposible implantar una gestión eficiente de pro-
yectos.
Los ciclos de aprobación no responden a controles o revisiones técni-

cas del proyecto, responden a procedimientos propios de una organiza-
ción de la era anterior a la informática. Estos procedimientos tienen
como precedente la frase de siempre lo hemos hecho así (cultura de
empresa decimonónica). Son procedimientos innecesarios que hay que
eliminar.
Los cambios constantes en los requisitos son una fuente de proble-

mas importantes. Significan un arranque del proyecto en falso, poca invo-
lucración del cliente y, a fin de cuentas, modificaciones al alcance del pro-
yecto. Cuando los cambios son muy numerosos, hablar del proyecto ori-
ginal es una falacia pues el proyecto actual no es el mismo.
Las interferencias de la dirección abarcan aspectos como modifica-

ción de la planificación, desmantelamiento del equipo del proyecto o
parte de él, negociaciones poco afortunadas con clientes y proveedores,
peticiones constantes y arbitrarias de informes, etc. Si hay algo peor que
102
CAP 05 25/5/11 15:55 Página 103
una dirección con poco interés en el proyecto es la que se preocupa en

exceso y quiere participar constantemente. En el menos malo de los
casos, es un ladrón de tiempo.
El cuarto principio, creación de sistemas Pull, lo transformamos en

los proyectos en permitir que el cliente extraiga el valor. Esto significa
que el cliente reconozca el valor y lo haga suyo.
Para que el cliente extraiga valor, es necesario que se involucre a lo

largo del proyecto a través de los entregables.
Recuerden el fracaso de la PDA que se vio como ejemplo en el primer

capítulo. El diseño de Apple fue realizado por técnicos para técnicos. Si
se hubiera realizado un prototipo que los consumidores potenciales
hubieran podido validar, el producto no hubiese sido un fracaso de tama-
ñas proporciones.
Otras empresas como Nissan utilizaron el concepto de pseudo-cliente.

La anécdota es aleccionadora. Nissan envió a cincuenta técnicos a vivir
y conducir por toda Europa durante seis meses. Con esto consiguió ajus-
tar sus vehículos a las necesidades del mercado europeo y salvar la gran
distancia que Japón tiene con los países del viejo continente y que supo-
nía una barrera en la captación de necesidades.
Cuando se sigue un proceso tradicional sin entregables, la situación

es como sigue en este ejemplo sencillo:
103
CAP 05 25/5/11 15:55 Página 104
Podemos encontrarnos con un problema:
— El diseño es incorrecto y sus errores dan lugar a un producto ina-

decuado que el cliente rechaza. En el proyecto se ha consumido
tiempo, recursos y dinero, en fabricar el producto.
Si utilizamos un proceso Lean el esquema sería el siguiente:
En este caso, la interacción del cliente en el proyecto detecta posibles

errores a tiempo y minimiza el impacto de los mismos.
El quinto principio, búsqueda permanente de la perfección, obliga a

no falsear los históricos de los proyectos que, a menudo, recogen infor-
mación intencionadamente incompleta, datos erróneos y justificaciones
teatrales. De los fallos se aprende y su reconocimiento ayuda a suprimir
malas prácticas y conseguir introducir mejoras en el futuro.
Centrémonos ahora en los principales desperdicios en los proyectos.

Ya introdujimos el del tiempo, pero este tiene diversos orígenes.
Detallamos los más significativos, si les parecen pocos no hay que preo-
cuparse, el ser humano es capaz de conseguir más.
Las tres principales causas de pérdidas de tiempo en los proyectos son:
104
CAP 05 25/5/11 15:55 Página 105
• Las reuniones
• Los marcos de trabajo con proveedores y subcontratistas
• El manejo de la información
Las reuniones tienen, a su vez, su propia tipología:
• Reuniones periódicas. Normalmente son semanales y sirven para

evaluar el grado de avance del proyecto, resolución de alguna inci-
dencia, tomar decisiones, hablar del partido de fútbol del día ante-
rior y otros temas lúdicos. Este tipo de reunión tiene su razón de
ser, pero provoca pérdidas de tiempo:
— Cuando entre reunión y reunión, la duración de las tareas del

proyecto a revisar, son de tal magnitud que no existe infor-
mación relevante que sirva para algo (la frecuencia de las reu-
niones debería ser más flexible).
— Cuando a la finalización de la reunión, los asistentes no salen
de la sala con sus deberes asignados.
— Cuando no se evita en la reunión el uso del impersonal y el
condicional (habría que hacer, alguien debería decirle, si me
dan más recursos...) y ser más concretos para facilitar la
toma de decisiones.
105
CAP 05 25/5/11 15:55 Página 106
— Reuniones aperiódicas. Son reuniones que se celebran cuan-

do se cumplen determinados hitos del proyecto. Desde el
punto de vista de la planificación no son relevantes, pero sí
desde el punto de vista de revisión técnica, de calidad y de
auditoría. Para un mayor compromiso de las partes implica-
das, la reunión es mejor considerarla como una tarea más del
proyecto con su duración correspondiente.
— Reuniones convocadas por la dirección. Son un subconjunto

de las anteriores, pero su motivación es distinta ya que se
fundamentan en los deseos de la dirección de intervenir en el
proyecto y no se ajustan a ningún criterio planificable. Reciben
el nombre de reuniones de porque sí. Son claramente un des-
perdicio.
106
CAP 05 25/5/11 15:55 Página 107
El marco de trabajo con los proveedores y los subcontratistas es con-

veniente definirlo muy bien para conseguir un proyecto eficiente. Imagine
que utilizamos el método de cadena crítica con el fin de optimizar tiem-
pos y, que un subcontratista que tenemos para realizar una parte del pro-
yecto no utiliza dicho método, entonces es muy probable que se produz-
can desfases en el proyecto.
Algo similar se produce con los proveedores respecto a sus plazos de

entrega.
Es fundamental establecer una forma de trabajo Lean con ellos, en

caso contrario no podemos hablar de proyectos Lean o eficientes. Las
pérdidas de tiempo que estas situaciones producen pueden ser muy gra-
ves.
Debemos conseguir que el marco de trabajo establecido, consiga que

las partes implicadas funcionen como un equipo perfectamente coordi-
nado remando todos en la misma dirección.
Por último, contemplamos las pérdidas de tiempo producidas por el

deficiente manejo de la información y su transporte y legibilidad.
107
CAP 05 25/5/11 15:55 Página 108
Las principales fuentes de costos de manejo de la información, y por

tanto, la producción de despilfarros son:
• Pobre elección de los medios de comunicación. Actualmente la

tecnología brinda una gran variedad de medios para una gran
variedad de situaciones.
Una videoconferencia permite realizar reuniones, evitando viajes

de las personas involucradas.
El email evita recorridos entre despachos para entregar una infor-

mación o solicitarla.
• Falta de un lenguaje común. En los proyectos, la guía del PMI evita

estos problemas de comunicación.
• Exceso de formalidades. Se refiere a controles burocráticos exas-

perantes que obligan a una documentación que no añade ningún
valor al proyecto y que suponen costos y pérdidas de tiempo. Se
da la circunstancia de que estas formalidades terminan por cer-
cenar la creatividad de las personas (las aburren).
• Procesos repetitivos sin fin. En los proyectos existe la creencia de

que cuanto más revisiones se hagan más controlado está el pro-
yecto y, si son varias las personas que hacen la misma revisión
todavía mejor. Estos ciclos retrasan las tareas y caldean los áni-
mos. Son, como el punto anterior, herencias de organizaciones
con cultura de empresa desfasada.
• Exceso o falta de información. El exceso de información provoca

un incremento de papeles con contenidos irrelevantes para dar la
impresión de que se ha trabajado mucho, o justificar lo que se
cobra por el proyecto. En ambos casos, se pierde el tiempo de
quien la redacta y de quien la lee. Termina enmascarando la infor-
mación relevante y es poco útil como herramienta de trabajo.
108
CAP 05 25/5/11 15:55 Página 109
En cuanto a la falta de información, lo de bueno y breve, dos veces

bueno no siempre es adecuado. No podemos perder información porque
perdemos valor.
5.5. COMBINAR LPM CON CCPM
Hay una tendencia, cada vez más aceptada, de incluir TOC y cadena
crítica dentro de la gestión de proyectos Lean (LPM en inglés) y estoy
de acuerdo con ello. Insistimos en que Lean no es en sí mismo una
109
CAP 05 25/5/11 15:55 Página 110
metodología mientras que la cadena crítica sí ofrece un método de tra-

bajo per fectamente delineado.
Lean proporciona una forma de pensar que ayuda a poner las cosas
en orden, aclarar conceptos fundamentales, cambiar la cultura de la
empresa para conseguir mayor productividad y competitividad y a levan-
tar la alfombra para limpiar los desperdicios que ocultaba.
CCPM tiene muchos puntos en común pero añade una sistemática

ordenada y fácil de seguir.
Es un matrimonio perfecto y con lazos cada vez más estrechos.
110
CAP 06 25/5/11 15:58 Página 111
CAPÍTULO 6
LOS RECURSOS HUMANOS Y LA

RESISTENCIA AL CAMBIO
CAP 06 25/5/11 15:58 Página 113
Los Recursos Humanos y la Resistencia al Cambio
Si en el mundo hay algo constante, ese es el cambio.
6.1. RESISTENCIA AL CAMBIO
Decimos constantemente que las personas se resisten a los cambios

por comodidad, por miedo, por desconocimiento, por apatía o por otros
diversos motivos. Lo cierto es que el ser humano convive con cambios
constantes en su persona y en el entorno que le rodea, entonces ¿por
qué nos resistimos al cambio?, desde niños deberíamos estar acostum-
brados a ello.
Las empresas necesitan cambiar ya sea su estrategia, sus estructu-

ras, o sus métodos para sobrevivir en un entorno de competitividad que,
a su vez, exige incrementos en la productividad, en la calidad y en la efi-
ciencia. En la fecha de publicación de este libro se está viviendo una cri-
sis financiera de gran impacto que aún exige más cambios en las empre-
sas y, por tanto, en las personas que trabajan en ellas.
El mundo de los proyectos necesita cambiar sus métodos de gestión

para lograr mejores resultados en plazos, costes, calidad y alcance, que
con los métodos tradicionales no se estaban consiguiendo.
NECESITAMOS CAMBIAR PARA MEJORAR
Pensemos en las motivaciones que llevan a las personas a resistirse

a los cambios. Trabajemos con dos hipótesis:
Hipótesis 1: La gente se resiste al cambio.

Cuanto mayor es el cambio, mayor es la resistencia.
113
CAP 06 25/5/11 15:58 Página 114
Esta hipótesis tiene un lado oscuro. Su planteamiento indica que las

personas, ante un cambio, activan un mecanismo automático de resis-
tencia a dicho cambio, lo cual indicaría que somos estúpidos.
Como pensamos que el ser humano, a pesar de sus indudables fallos,

no es estúpido vamos a plantear otra hipótesis.
Hipótesis 2: La gente estudia el cambio.

Si a la gente le gusta el cambio, lo acepta, si no lo rechaza.
Ésta última hipótesis es más razonable pero mantiene aún posibilida-

des de cierta resistencia al cambio.
Aunque en el siguiente apartado se tratará con mayor profundidad los

perfiles resistentes al cambio, veamos ahora cuatro perfiles generales.
114
CAP 06 25/5/11 15:58 Página 115
Víctima: El cambio le produce una gran desazón. Piensa que dicho

cambio le producirá grandes inconvenientes, al no verse capaz de afron-
tar nuevas formas de trabajo.
Otra forma de victimismo es la de la sensación de que el cambio gene-

rará despidos y que, el personaje de la víctima, estará irremediablemen-
te en la lista negra.
Espectador: No tiene una opinión formada, ni a favor ni en contra.

Observa cómo se produce el cambio, pero no participa en él. Su papel
es reactivo y espera a ver por dónde se decanta la mayoría de compañe-
ros.
Según el devenir de los acontecimientos se decantará a favor o en

contra del cambio.
Crítico: Se opone al cambio de forma inmediata. Dedica todos sus

esfuerzos a criticar todo lo que conlleva el cambio y trata de arrastrar a
los demás en una labor de apostolado maquiavélico.
Producido el cambio se transforma en un ser resentido y peligroso que

puede obligar a tomar con él la decisión de apartarle del resto.
Navegante: Es una persona que toma el mando de su nave. Por con-

vencimiento, profesionalidad o curiosidad, decide apuntarse al cambio.
Muchos navegantes lo son por considerar que el cambio es una opor-

tunidad para ellos.
Se ha comentado en este libro que la cultura de empresa anticuada y

anclada en el tiempo es un serio enemigo para los cambios en la gestión
a cualquier nivel. Al conseguir la empresa evolucionar a nuevos métodos
más eficientes, aquellos que criticaban esa cultura de empresa obsole-
ta, ahora se resisten al cambio.
115
CAP 06 25/5/11 15:58 Página 116
Todo se reduce a una muestra de desconfianza entre empresa y

empleados.
Si la empresa decide llevar a cabo el cambio, debe facilitar los medios

necesarios a los empleados para que dicho cambio se produzca sin trau-
mas y tensiones innecesarias. Algunos personajes como el crítico pueden
perderse en el intento, pero estas pérdidas son un mal menor compara-
das con el fracaso de una implantación del cambio.
Es la empresa la que debe tomar la iniciativa y hacer partícipe de la

implantación del cambio a todos sus empleados. Información, formación,
planificación y expectativas son un buen comienzo para conseguir el cam-
bio deseado.
Hay que tener en cuenta que la resistencia al cambio tiene que ver con
la mente humana, es decir, con la mente consciente y la subconsciente o lo
que es lo mismo, el pensamiento lógico y el funcionamiento automático. La
mente consciente es la que aprende, previo estímulo o intención. Cuando la
116
CAP 06 25/5/11 15:58 Página 117
mente consciente aprende, pasa la información a la mente inconsciente o

subconsciente que aplicará de forma automática lo aprendido.
Pensemos en cómo vamos a un nuevo lugar de trabajo. Nuestra

mente consciente aprende cómo ir y durante unos días dedica sus
esfuerzos a crear una ruta, una vez aprendida la ruta, la mente cons-
ciente se libera de dicha ruta pasando la información a la mente sub-
consciente que a par tir de ese momento ejecuta de forma automática
el trayecto.
De adultos, hemos aprendido muchas cosas, pero tenemos en el sub-

consciente almacenados muchos hábitos o formas de hacer las cosas.
El cambio nos plantea hacer las cosas de distinta manera, con lo cual
deberíamos iniciar un nuevo proceso (una nueva ruta) y ello nos crea
inquietud. Por esto es necesario que la empresa u organización ayude en
los procesos de adaptación y aprendizaje.
Ante el cambio los puntos clave para derivar hacia la oportunidad son:
• Involucrar al equipo o a la gente en general
• Establecer una comunicación constante
• Establecer un plan apropiado para incorporar el cambio
• No cejar en el empeño
Las razones por las que el cambio deriva hacia el fracaso son:
• Una pobre planificación
• No consultar a los afectados o usuarios finales
• Pobre seguimiento de la implantación del cambio
117
CAP 06 25/5/11 15:58 Página 118
En la gestión de proyectos hemos planteado cambios como la aplica-

ción de TOC, cadena crítica y Lean, métodos que deben ser enseñados a
los equipos de proyectos (incluidos sus responsables) pero informando
de las ventajas que supone la aplicación de dichos métodos para los pro-
yectos, la empresa y para ellos mismos.
6.2. TIPOLOGÍA DE LOS PROFESIONALES QUE SE

RESISTEN AL CAMBIO
Hemos señalado cuatro tipos o caras de la gente a la hora de afron-

tar los cambios, pero conviene realizar las siguientes puntualizaciones.
Dentro de los cuatro tipos existen subtipos significativos:
• Una persona puede tener comportamientos de distintos tipos o

subtipos.
118
CAP 06 25/5/11 15:58 Página 119
• Puede ser difícil catalogarlos al principio, por ello es preciso que

Recursos Humanos colabore en la implantación del cambio.
Veamos algunos subtipos relevantes:
• El desinformado: Es un subtipo del tipo víctima. Está en contra

del cambio porque lo desconoce, por falta de información o por
desinterés.
Hay que acercarle el cambio. Por lo tanto, es importante aportar-

le las vías para que se informe y forme. Es útil contarle por qué
se va a hacer el cambio.
• El gregario: Es un subtipo del tipo espectador. Generalmente son

novatos y siguen a la manada por no poder ser líderes.
Pueden ser fáciles de reconvertir a navegantes o, al menos, a ser

conducidos convenientemente por un líder a lo largo del proceso
del cambio.
Algunos gregarios pueden mostrar cierto desinterés al tener otras

prioridades, pero quedan al descubierto pronto y, a veces, por
sus propios compañeros.
En resumen, hay que liderarlos.
• El cínico: Es un subtipo del tipo crítico. Lo componen personas

polemistas o listillos. Siempre ven el lado negativo y les gusta exhi-
birse en público pero no por demostrar sus razonamientos, sino
por parecer más listo que otro en el foro en cuestión.
Hay que neutralizarle mediante la táctica de no permitirle argu-

mentar o estar preparado para contra-argumentar demostrando
que su punto de vista es menos inteligente.
119
CAP 06 25/5/11 15:58 Página 120
• El quemado: En este caso nos encontramos con una mezcla de

los tipos víctima y crítico. Normalmente son personas que han uti-
lizado otros métodos con pobres resultados y se oponen al cam-
bio que trata de implantar un nuevo método.
Es difícil de contrarrestar pues suele ser veterano y con credibili-

dad dentro del grupo. Es necesario analizar qué le ocurrió y con-
vencerle de que este nuevo cambio es el correcto y recabar su
ayuda para evitar pasos erróneos que el quemado sufrió.
En resumen, darle cierto protagonismo en el cambio.
• El que no tiene tiempo para nada: Es un subtipo del tipo víctima.

No tienen tiempo porque tienen problemas y tienen problemas
porque no tienen tiempo. Tienen la filosofía de que nunca hay
tiempo para hacer las cosas bien, pero sí lo tienen para hacerlas
dos veces.
Se lían de distintas maneras (pero todas muy barrocas) de forma

que los árboles no les dejan ver el bosque.
Algunos pueden no tener tiempo realmente como consecuencia de

asumir un exceso de responsabilidades. Esta situación hay que
solucionarla, descargándoles de alguna responsabilidad y/o incul-
cándoles asertividad.
En general, es fácil identificarlos por su parecido con el conejo de

Alicia en el país de las maravillas.
Hay que convencerles, mediante demostración, de que el nuevo

método les hará la vida más fácil y les permitirá ahorrar tiempo.
• El director: Nuevamente nos encontramos con una mezcla de crí-

tico y víctima. La principal razón por la que se opone al cambio
es porque no entiende el nuevo método y su necesidad. Evoca
120
CAP 06 25/5/11 15:58 Página 121
continuamente los viejos tiempos en los que nunca necesitaron

estas revolucionarias técnicas.
Si se trata de un mando intermedio es posible que se solape con

el subtipo del que no tiene tiempo para nada.
Para ser justos, hay que reconocer que le planteamos problemas

que escapan al ámbito de los clásicos problemas de directivos.
Hay que convencerle de que el cambio le resolverá problemas de
dirección. Si se le convence con planteamientos de ahorro de
costes y plazos en los proyectos es muy posible que acepte el
cambio. No hay que atacar con planteamientos técnicos, en cuyo
caso se plantearía una mayor resistencia al cambio.
Finalmente y por una regla no escrita, los jefes tienden a dar

mayor credibilidad a alguien de fuera que a los de dentro. Sería
muy positivo conseguir que un agente externo comentara los bene-
ficios del nuevo método y del cambio.
• El irracional: Es un subtipo del tipo crítico. En realidad es el críti-

co por excelencia. Tiene el peligro de ser mutante al fagocitar lo
negativo del resto de subtipos.
En realidad, a la larga, no importa cuáles son los motivos, el com-

portamiento es siempre el mismo, intentará rebatir un argumento
y el contrario y si es necesario actuará como si se tratará de otro
perfil; tienen sus motivos pero jamás aflorarán y si por cualquier
razón se hicieran evidentes, discutiría aún más con el objetivo de
negarlo.
Con este perfil no sirve ni la comunicación, ni intentar cambiar su

postura. Solamente valen los hechos, la demostración técnica,
pero no hay que confundirse, no se habrá convencido, simple-
mente se trata de neutralizarlo.
121
CAP 06 25/5/11 15:58 Página 122
Hagamos lo que hagamos, no se le podrá convencer. No vale la

pena gastar tiempo y esfuerzo con este personaje.
A corto o medio plazo es mejor deshacerse o prescindir del irra-

cional para evitar el efecto contagio.
6.3. FORMACIÓN DE LOS RESPONSABLES DE PROYECTOS
Si queremos que el cambio se produzca y se implanten métodos y téc-

nicas de gestión de proyectos con filosofía Lean, TOC y cadena crítica, es
crucial la formación de los responsables de proyectos.
Distinguimos dos niveles de formación:
• Formación en PMI. Las guías del PMI proporcionan un marco refe-

rencial completo, que se puede aumentar con niveles detallados
de sus áreas de conocimiento.
Esta formación es idónea para jefes de proyecto con poca expe-

riencia o para personas que se postulan para ocupar estos pues-
tos de responsabilidad.
122
CAP 06 25/5/11 15:58 Página 123
• Formación en los métodos y técnicas expuestos en este libro.
Esta formación es una inmediata continuación de la anterior y es,

también, idónea para jefes de proyecto con experiencia y que ven
que sus proyectos tienen problemas.
Preparemos bien a nuestros responsables de proyectos. Si este libro

lo está leyendo un jefe de proyectos, póngase manos a la obra y busque
la manera de adquirir los conocimientos necesarios para ejercer sus res-
ponsabilidades de forma eficiente, logrando para la empresa los resulta-
dos apetecidos.
123
CAP 07 25/5/11 15:59 Página 125
CAPÍTULO 7
UN HORIZONTE MÁS FIABLE

CAP 07 25/5/11 15:59 Página 127
Un Horizonte más Fiable
7.1. LIDERAR UN PROYECTO
A lo largo del libro hemos empleado términos como jefe de proyecto

o responsable del proyecto. Tengo una especial debilidad por el térmi-
no, líder del proyecto. Soy consciente de que suena un tanto pomposo,
pero define mejor la labor que debe realizar quién está al frente de un
proyecto.
Hemos introducido nuevas formas de gestión que son muy exigen-

tes y el líder tiene que implantarlos así como, convencer al equipo del
proyecto de nuevas formas de trabajo.
Liderazgo es el arte de conseguir que alguien

haga lo que tú quieres que haga porque él
quiere hacerlo
Esta frase pertenece al General Eisenhower y define muy bien el carác-

ter de un verdadero líder.
En el capítulo 6 vimos como combatir la resistencia al cambio y los

pasos a dar para conseguir el objetivo de vencer dicha resistencia. Al final
de este proceso los equipos de proyecto deben estar convencidos de que
ellos impulsaron el cambio o, al menos, que participaron en él.
El líder de proyecto debe promover la participación activa (aunque con-

trolada) del equipo en la gestión y hacerles participes del valor del pro-
yecto para la empresa.
127
CAP 07 25/5/11 15:59 Página 128
7.2. DISTRIBUIR RESPONSABILIDADES
En muchas ocasiones, en los proyectos suele imponerse estimacio-

nes y plazos a los miembros del equipo provocando reacciones de defen-
sa y actitudes reactivas. Deles la oportunidad de estimar la duración de
sus tareas, pero sea consecuente con lo expuesto en este libro, es decir,
pídales dos duraciones para una tarea, la primera que responda a una
estimación con la que se sientan cómodos y una segunda estimación
más exigente por necesidades del proyecto. A continuación, aplique el
método de cadena crítica y ajuste la duración estimada definitiva.
En cualquier caso, no ignore al miembro de su equipo y hágale, de

alguna forma, partícipe en la gestión.
7.3. INCREMENTAR LA PRODUCTIVIDAD
En la actualidad, políticos y empresarios no paran de pronunciar, a

pocas oportunidades que les den, las palabras productividad y competi-
tividad, pero pocas veces (más bien ninguna) dicen cómo conseguirlo.
Son malos tiempos que requieren menos hablar y más actuar.
Apliquen Lean, TOC y cadena crítica en sus proyectos y conseguirán

ser más productivos y competitivos, o como dice Larry Leach:
COMPLETAR PROYECTOS EN LA MITAD DE TIEMPO

TODO EL TIEMPO
128
CAP 08 25/5/11 16:02 Página 129
BIBLIOGRAFÍA
CAP 08 25/5/11 16:02 Página 131
Bibliografía
Guía de los Fundamentos para la Dirección de Proyectos (Guía del

PMBOK® Cuarta edición, PMI).
Goldratt, Eliyahu M., Cadena Crítica, Ediciones Díaz de Santos (2001).
Guerra Peña, L., Coronel Granado, A., Martínez de Irujo García, L., Llorente
Simón, A., Gestión Integral de Proyectos, FC Editorial (2009).
Jacob, D., Bergland S., Cox, J., Velocidad, Alienta (2011).
Leach, Lawrence P., Critical Chain Project Management, Artech House.
Leach, Lawrence P., Lean Project Management: Eight Principles for

Success, Advanced Projects Incorporated (2005).
Leach, Lawrence P., Leach, Shane P., Lean Project Leadership,
Advanced Projects Incorporated (2010).
Wormack, James P. y Jones, Daniel T., Lean Thinking, Ediciones Gestión

2000 (2005).
SITIOS WEB DE INTERÉS
Instituto Lean Management (España)

http://www.institutolean.org/
Lean Enterprise Institute

http://www.lean.org/
Goldratt Consulting
http://www.goldrattconsulting.com/
AP Advanced Projects (Lean Project Management)

http://www.advanced-projects.com/
Project Management Institute PMI

http://www.pmi.org/
131

Claves de Gestion de Proyectos-1

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Claves de Gestion de Proyectos-1

Caricato da

Copyright:

Formati disponibili

CREDITOS 1-14 26/5/11 10:27 Página 3

CLAVES DE LA GESTIÓN DE PROYECTOS

Autor: Carlos Grolimund

Impreso en España – Printed in Spain

1.1. El mundo de los proyectos .................................... 17

2.1. Cultura de empresa .............................................. 29

3.1. PMI (Project Management Institute) ....................... 41

Mi cariño y agradecimiento a María Claudia Londoño

A José Luis Esteban y José Andrés por sus ideas y discusiones.

A mis "pequeños" Alejandro, Javier y María.

4.1. Reflexión sobre la teoría de las restricciones ......... 47

4.2.1. Viejos vicios en los proyectos .................... 62

4.3. Gestión de la cadena crítica (CCPM) ...................... 74

4.3.1. Sistemática de la cadena crítica ................. 74

4.4. Gestión de los buffers .......................................... 82

5.1. Problemas con el alcance del proyecto ................... 89

6.1. Resistencia al cambio ........................................... 113

6.2. Tipología de los profesionales que se resisten

7.1. Liderar un proyecto ............................................... 127

BIBLIOGRAFÍA ...................................................................... 129

Este libro no pretende ser otro más de Gestión de Proyectos basado

Es muy común utilizar modelos matemáticos en la planificación de los

Otro punto importante es el desmesurado alcance de los proyectos

El objetivo del autor consiste en proporcionar, al amable lector, un

En el libro se introducen filosofías y métodos de gestión que nacieron

No se pretende tratar de forma extensa estos temas, pero sí exponer

Claves de la Gestión de Proyectos

El lector, para seguir el contenido del libro, debe tener conocimientos

Larry Leach lo resume con la frase completar proyectos en la mitad

Es hora de pasar a la acción de la forma más sencilla y amena posi-

VISIÓN GENERAL DE LOS

Visión General de los Proyectos y su Gestión

1.1. EL MUNDO DE LOS PROYECTOS

“Un proyecto es un problema con un plan de solución”

El propio concepto de proyecto siempre ha sido controvertido. El pri-

• Objetivo: crear el mundo de la nada (o del caos)

• Plazo: seis días (mal definidos, al principio aún no había día y

Después dejó la gestión a sus clientes, Adán y Eva, y…

Como podemos ver, no sólo la unidad de tiempo empleada es confu-

Claves de la Gestión de Proyectos

Posteriormente la historia nos proporciona ejemplos de proyectos de

En la actualidad, los proyectos sí presentan problemas de todo tipo,

• La meta y el alcance del proyecto.

• Los plazos de entrega de los resultados del proyecto.

• La gestión de los recursos. Hablamos de gestión de recursos,

Aunque los recursos, especialmente los humanos, no supongan un

Ed Yourdon2 estableció una tipología en base al gráfico siguiente:

en metodologías de ingeniería de software. Se le conoce como uno de los líderes en el desarrollo de

Visión General de los Proyectos y su Gestión

Sobre el eje de ordenadas llevamos el porcentaje de felicidad del equi-

Sobre el eje de abscisas llevamos el porcentaje de probabilidad de

La combinación de los dos porcentajes proporciona unos tipos de pro-

Claves de la Gestión de Proyectos

• Tipo Misión Imposible: El nombre no debe llevarnos a engaño, en

El equipo está formado por buenos especialistas en distintas

Estos equipos, incluido el líder, emplean métodos a todos los nive-

A diferencia de los héroes de Hollywood, estos profesionales no

Una característica importante en este tipo de proyectos es la del

• Tipo Cuerpo de Marines: A diferencia del caso anterior, aquí el

Es obvio que el porcentaje de felicidad baja dramáticamente e, inclu-

Visión General de los Proyectos y su Gestión

así como posiblemente, quizás, la calidad de los resultados del pro-

Otra consideración a tener en cuenta es que este tipo de proyec-

• Tipo Suicidas: Se explican por sí solos. Alcance del proyecto desa-